Langzeitarchivierung

Übersicht

VLS unterstützt die Auslieferung der wesentlichen Stammdaten eines Katalogisats in ein Langzeitarchiv und die Wiedereinspielung im Fall eines Datenverlustes.

Zur Auslieferung werden die zu einem Katalogisat gehörenden Daten (Metadaten, Bilddateien, Volltexte, etc.) mit zusätzlichen Metadaten für den Archivbetreiber versehen und in eine langzeitarchivierbare Datei (SIP, Submission Information Package) überführt. Diese erste Auslieferung wird in der VLS auch als Master-Kapsel bezeichnet.

Nachfolgende Änderungen an den Stammdaten werden von der VLS erkannt und führen zur Auslieferung weiterer Kapseln, welche die inkrementellen Änderungen (und nur diese) enthalten. Diese Ergänzungskapseln werden in der VLS als Delta-Kapseln bezeichnet, und tragen eine fortlaufende Nummer (“Generation”).

Zur Wiederherstellung der Stammdaten eines Katalogisats sind die Master-Kapsel sowie alle folgenden Delta-Kapseln notwendig. Diese können aus dem Langzeitarchiv über die Identifikation (z. B. URN) zurückgewonnen werden. Eventuell unterstützt das Langzeitarchiv auch die Zusammenführung dieser Kapseln zu einer Datei (DIP, Dissemination Information Package), welche dann gleichwertig für eine Wiederherstellung verwendet werden kann.

Katalogisate

Die Auswahl der Katalogisate, die langzeitarchiviert werden sollen, kann über den QA-Status und den Veröffentlichungszustand stattfinden. Üblicherweise werden nur veröffentlichte Katalogisate archiviert. Die Auswahl beschränkt sich auf Katalogisate, deren Typ die Eigenschaft “capsuleExport” hat. Dies ist standardmäßig (und vorläufig) für alle Typen ausser Zeitschriften, Zeitungen, Hefte und Periodika der Fall.

VLS erlaubt, dass einem Katalogisat in der Baumstruktur beliebig viele andere Katalogisate untergeordnet sind. Dies betrifft insbesondere mehrbändige Werke und Periodika, aber auch teilweise Handschriften, Autographen, Nachlässe und Sonderbestände. Den Überordnungen können dabei durchaus eigenständige Digitalisate anhaften. Zudem kann sich die Strukturierung im Einzelfall selbst nach der initialen Kapsel-Auslieferung noch ändern.

Dieser Komplexität wird auf einfache Weise Rechnung getragen: Zu jedem exportierten Katalogisat gehört eine Folge von Kapsel (eine Master und mehrere Delta-Kapseln), welche alle Daten in der Baumstruktur abwärts bis zu den untergeordneten exportierten Katalogisaten erfassen. Die Daten der untergeordneten Katalogisate werden in eigenständigen Kapseln erfasst.

Eine Kapsel zu einem Katalogisat enthält ebenfalls die Metadaten aller ihrer Überordnungen, so dass ihr kontextueller Zusammenhang vollständig erfasst ist.

Bemerkung

Das Verfahren erfordert die Auszeichnung aller Jahrgänge eines Periodikums als Katalogisat. Insbesondere muss dazu die Zuweisung einer URN erfolgen. Ansonsten würden alle Jahrgänge der Kapsel der Überordnung zugeordnet, welche im Allgemeinen zu gross werden würde.

Bemerkung

Auch für Überordnungen ohne eigene Digitalisate werden Kapseln gebaut. Diese enthalten dann nur eine METS-Datei.

EAD

Die Kapseln eines Portals erfassen nicht alle wesentlichen Stammdaten. So fehlen die Sammlungen, Kollektionen, Wiki-Daten, und andere Metadaten, die nicht Teil eines Katalogisats sind.

Alle diese Daten werden in einer EAD-Datei (Encoded Archival Description) zusammengefasst. Diese referenziert auch die obersten Katalogisate in der Baumstruktur (welche wiederum ihre Unterordnungen referenzieren, u.s.w.).

Die EAD-Datei entspricht dem EAD-Schema der Library of Congress.

Voraussetzung

Um die Langzeitarchivierung für eine VLS-Instanz zu aktivieren, muss in der server.ini der Wert preservation.on=True gesetzt werden.

Ablauf für Katalogisate

Der folgende Abschnitt beschreibt den Ablauf für ein Katalogisat, welches zur Archivierung ausgewählt wurde.

Prozess

Der Ablauf der Kapselexportverarbeitung wird über eine Statusmaschiene gesteuert. Für jedes Katalogisat wird dafür der Auslieferungs-Status von der VLS verwaltet.

Die zugehörigen Jobs <jobs>, die auf die Katalogisat-Statuswerte reagieren, laufen in regelmäßigen Abständen gemäß der Scheduler-Konfiguration. Die Einstellungen für den automatisierten Export finden über die Domain-Konfiguration statt.

Kapselerstellung zu prüfen

Der Auslieferungsprozess beginnt im Allgemeinen mit der Freigabe eines Werks. Es wird der Status “Kapselerstellung zu prüfen” vergeben.

In diesem Zustand wird regelmässig geprüft, ob eine Master- oder Delta-Kapsel für das Katalogisat gebaut werden müssen.

Kapsel zu erstellen

Ist noch keine Kapsel vorhanden, so wird der Status auf “Kapsel zu erstellen” geändert, um die Erstellung der Master-Kapsel zu beauftragen.

Nach Erstellung der Master-Kapsel wird der Status auf “Kapselerstellung zu prüfen” zurückgesetzt. Ferner beginnt hiermit auch der Ablauf für die Master-Kapsel (s. nächster Abschnitt).

Delta-Kapsel zu erstellen

Werden im Status “Kapselerstellung zu prüfen” Änderungen an den wesentlichen Stammdaten des Katalogisats festgestellt, so wird der Status auf “Delta-Kapsel zu erstellen” geändert.

Nach Erstellung der Delta-Kapsel wird der Status auf “Kapselerstellung zu prüfen” zurückgesetzt. Ferner beginnt hiermit auch der Ablauf für die Delta-Kapsel (s. nächster Abschnitt).

Kapselerstellung fehlgeschlagen

Tritt ein Fehler während der Erstellung der Master- oder einer Delta-Kapsel auf, so wird der Status auf “Kapselerstellung fehlgeschlagen” gesetzt.

Ein Katalogisat in diesem Zustand nimmt nicht mehr am Kapselexport teil.

Nachdem das Problem behoben wurde kann der Status auf “Kapselerstellung zu prüfen” zurückgesetzt werden. Die Kapselerstellung wird dann ggf. erneut probiert.

Kapsel nicht erstellen

Dieser spezielle Zustand wird vergeben, falls das Katalogisat nicht mehr für einen Kapselexport in Frage kommt, z. B. weil die Freigabe entzogen oder der Typ geändert wurde.

Ein Katalogisat in diesem Zustand nimmt nicht mehr am Kapselexport teil.

Sind die Voraussetzungen für einen Kapselexport wieder gegeben, so wird das Katalogisat automatisch wieder in den Zustand “Kapselerstellung zu prüfen” versetzt.

Kapselerstellung angehalten

Dieser spezielle Zustand kann manuell vergeben werden, zum Beispiel über den VLM (“Reklamation”).

Ein Katalogisat in diesem Zustand nimmt nicht mehr am Kapselexport teil.

Soll der Kapselexport fortgesetzt werden, so ist der Status auf “Kapselerstellung zu prüfen” zurückzusetzen.

Ablauf für Kapseln

Der folgende Abschnitt beschreibt den Ablauf einer Kapsel, welche zur Archivierung erstellt wurde.

Prozess

Der Ablauf der Kapselverarbeitung wird über eine Statusmaschiene gesteuert. Für jede Kapsel wird dafür ein Kapsel-Status von der VLS verwaltet.

Die zugehörigen Jobs <jobs>, die auf die Kapsel-Statuswerte reagieren, laufen in regelmäßigen Abständen gemäß der Scheduler-Konfiguration. Die Einstellungen für den automatisierten Export finden über die Domain-Konfiguration statt.

Findet kein manueller Eingriff oder Fehler statt, so durchlaufen alle Kapseln die folgenden Statuswerte der Reihe nach.

Kapsel neu

Die Kapsel wurde neu erstellt und im Dateisystem abgelegt.

Kapsel gelöscht

Die Kapsel wurde vom Dateisystem entfernt. Dies ist üblicherweise der Fall, wenn sie in ein Langzeitarchiv überführt wurde.

Kapsel archiviert

Die Kapsel ist im Langzeitarchiv angekommen.

Dieser Status kann entweder über eine Online-Schnittstelle des Langzeitarchivs abgefragt werden, oder nach Ablauf einer Schonfrist (Voreinstellung: 2 Tage) ex silentio angenommen werden.

Für die Abfrage einer Online-Schnittstelle ist üblicherweise eine Domain-spezifische Implementierung notwendig.

Originalbilder zu entfernen

Die Originalbilder, die in der Kapsel exportiert wurden, sind zu entfernen.

In VLS-Instanzen, auf denen die Originalbilder nicht erhalten bleiben sollen, können dann die Originalbilder nach Erstellung aller Webcache-Stufen entfernt werden (um Speicherplatz einzusparen).

Dieser Status wird nach Ablauf einer Schonfrist (Voreinstellung: 14 Tage) ex silentio angenommen.

Dieser Status ist optional, und wird nur in VLS-Instanzen erreicht, in denen die Originalbilder gelöscht werden sollen.

Originalbilder entfernt

Sind die Originalbilder durch den DeleteArchiveJob entfernt worden, so wird dieser Status gesetzt.

Achtung

Sind die Originalbilder gelöscht, so darf die Kapselinformation in der VL-Datenbank nicht mehr gelöscht werden, da eine erneute Erstellung einer Master- oder Delta-Kapsel, welche diese Bilder enthalten müsste, nicht mehr möglich ist.

Dieser Status ist optional, und wird nur in VLS-Instanzen erreicht, in denen die Originalbilder gelöscht werden sollen.

Aufbau der Kapseln

Kapsel-Typen

Es gibt zwei Typen von ZIP-Kapseln, Master und Delta. Beiden Typen sind gleich aufgebaut und enthalten immer eine METS-Datei mit dem Dateinamen export_mets.xml.

Dateiname

Master-Kapsel

Beispielname:

| Identifier          | Datum         | Typ  | Version | Erweiterung |
urn+nbn+de+hbz+6+1-612_20120626T140756_master_ver1.zip
Identifier

Als Identifier wird die URN, DOI oder der source identifier verwendet. Sonderzeichen wie : und / werden durch + ersetzt, da diese Sonderzeichen auf POSIX-Plattformen bzw. unter Windows reserviert sind.

Datum

Das Datum bezieht sich auf den Zeitpunkt, an der die Informationen für die Kapsel gesammelt worden sind. Der Zeitpunkt ist eine Sekunde bis Stunden vor der Generierung der Kapsel. Das Datum ist in UTC und hat den Aufbau YYYYmmddThhmmss.

Typ

Der Typ ist entweder master oder genX, wobei X eine streng monoton ansteigende Zahl startend mit 1 ist. Die erste Delta-Kapsel hat den Typ gen1, die nachfolgende gen2 etc.

Version

Die Version ist zur Zeit immer ver1.

Erweiterung

Die Erweiterung ist .zip.

Delta-Kapsel

Beispielname:

urn+nbn+de+hbz+6+1-612_20130115T173301_gen1_ver1.zip

Verzeichnisstruktur

urn+nbn+de+hbz+6+1-612/
  export_mets.xml
  image/
    117637.tif
    117638.tif
    ...
  fulltext/
    117637.xml
    ...
  pdf/
    117637.pdf
    117638-somename.pdf
    ...
  zip/
    117637.zip
    ...
  generic/
    117637.doc
    117637.odt
    117638-unknown.bin
    ...

Verzeichnisstruktur (BagIt)

Im BagIt-Format werden die Kapseldaten in einem Unterverzeichnis data abgelegt. Das übergeordnete Verzeichnis enthält die BagIt-Metadaten, insbesondere die Prüfsummen aller Dateien.

urn+nbn+de+hbz+6+1-612/
  bagit.txt
  bag-info.txt
  manifest-sha1.txt
  tagmanifest-sha1.txt
  data/
    export_mets.xml
    (...wie oben...)

Kriterien für die Erstellung von Delta-Kapseln

Dieser Abschnitt enthält technische Informationen darüber, wann eine Delta-Kapsel gebaut wird.

Vergleich der Zeitstempel

Es werden die Zeitstempel der letzten Änderung von Tabellenzeilen verglichen. Dieser Test ist sehr schnell, da er komplett innerhalb des Datenbankservers erfolgt. Als Referenzdatum wird der Erstellungszeitpunkt der neusten (Delta)Kapsel der Einheit oder der Zeitpunkt der letzten Überprüfung durch den ZipExportStatusJob verwendet.

Dieser Zeitpunkt wird mit den update timestamps der Tabellenzeilen für den zentralen Baum, Metadaten, Ressourcen (Volltext, ZIP Package, Generic File, Upload PDF) und Identifiern verglichen, außerdem wird das Änderungsdatum des Archivbilds in Betracht gezogen. Dabei werden alle Kinder der Einheit untersucht und die Einträge betrachtet, die einen neueren Zeitstempel haben. update timestamps werden von der Datenbank bei jeder Schreiboperation über Trigger gesetzt und sind somit verlässlich.

Wenn ein geändertes Bild, Ressource oder Identifier gefunden, wird das Katalogisat auf Delta-Kapsel zu erstellen gesetzt, weitere Überprüfungen sind nicht mehr notwendig.

Falls nur der Baumeintrag des Hauptknotens geändert wurde, weitere Einträge aber unverändert sind, wird die Überprüfung abgebrochen und keine Delta-Kapsel veranlasst. Dies ist eine Optimierung für den Fall, dass ein Katalogisat verschoben oder die Freigabe geändert wurde.

In allen anderen Fällen erfolgt der nächste Schritt.

Vergleich des METS

Im dritten Schritt wird ein aktuelles METS des Werk erzeugt und dieses METS blockweise mit dem METS verglichen, dass bei der letzten ZIP-Kapsel erstellt worden ist. Von diesem existiert eine Kopie im VFS.

Vor dem Vergleich werden eine Reihe von Informationen aus beiden METS entfernt, um die Anzahl der falschen Erkennungen gering zu halten bzw. um das Verfahren zu beschleunigen.

  • MIX-Informationen in Image AMD Section (bereits über Änderungsdatum des Bilds abgedeckt)
  • CREATED, CHECKSUM, CHECKSUMTYPE und vls:file-omitted Attribute der mets:fileGrp/mets:file Elemente, außerdem das SIZE aus der MIX-Section gesetzt, falls SIZE nicht vorhanden ist. Dies ist notwendig, weil die Informationen erst seit 2.11 vorhanden sind.
  • Alle mets:metsHdr, mets:amdSec und mets:dmdSec Sektionen und die ADMID bzw. DMDID Links zu den Sektionen. mets:dmdSec wird nur entfernt, wenn compareMODS ausgeschaltet ist.

Zum Schluss werden die Blöcke mit der C14N Form in UTF-8 serialisiert und die Strings verglichen. Bei einem Unterschied wird die Einheit auf Delta Kapsel zu erstellen gesetzt.

Überprüfungszeitpunkt speichern

Als letztes wird der Zeitpunkt der letzten Überprüfung gespeichert. Dies ist eine Optimierung, damit zeitaufwendige Vergleiche des METS nicht jede Nacht notwendig sind.

LZA Jobs

Die Erstellung der Kapseln wird durch mehrere Jobs gesteuert.

ZipExportStatusJob

Aktualisiert den Status aller zur Auslieferung ausgewählten Katalogisate. Dieser Job sollte nächtlich vor dem ZipExportJob laufen.

ZipExport

Erzeugt Kapsel zur Auslieferung von Katalogisaten mit passenden Status. Dieser Job sollte nächtlich vor dem ZipCapsuleStatusJob laufen.

ZipCapsuleStatusJob

Aktualisiert den Status aller erzeugten Kapseln. Dieser Job sollte nächtlich vor dem DeleteArchiveJob (bzw. dem ZipExportAnalyseJob) laufen.

DeleteArchiveJob (Optional)

Löscht die exportierten Originalbilder aus der VL, nachdem alle benötigten Webcache-Stufen erzeugt wurden. Dieser Job sollte nächtlich vor dem ZipExportAnalyseJob laufen.

ZipExportAnalyseJob

Erzeugt aggregierte Statistiken zur Anzeige in der Benutzeroberfläche.

Zur Erleichterung gibt es einen übergeordneten Job, der alle Kapsel-Jobs bündelt und in der richtigen Reihenfolge aufruft.

Gemeinsame Parameter

subdomains (Boolean)

Der Job kann entweder auf der Job-Domain laufen, oder auf der Job-Domain sowie allen untergeordneten Domains (rekursiv). Die Job-Einstellungen werden für jede Domain individuell über die Domain-Konfiguration geregelt.

Voreinstellung: false

target (String, zipcapsule)

Bestimmt das Export-Ziel für diesen Job. Nur Domains (bzw. Subdomains), die das gleiche Export-Ziel wie der Job haben, werden von dem Job bearbeitet.

Aktuell ist nur ein Export-Ziel vorgesehen: zipcapsule. Dieses unterstützt den fortlaufenden Export in ein Langzeitarchiv.

Der ZipExportJob (und nur dieser) unterstützt auch ein weiteres Export-Ziel: manual. Dieses ist für den manuellen Einzel-Export von Master-Kapseln (ausser der Reihe) vorgesehen.

Voreinstellung: zipcapsule

ZipExportCombined

Der Job ZipExportCombined ruft (optional) alle anderen Jobs auf, die für den Kapselexport relevant sind.

exportstatus (Boolean)

Falls wahr, wird der ZipExportStatus-Job aufgerufen.

Voreinstellung: true

export (Boolean)

Falls wahr, wird der ZipExport-Job aufgerufen.

Voreinstellung: true

capsulestatus (Boolean)

Falls wahr, wird der ZipCapsuleStatus-Job aufgerufen.

Voreinstellung: true

deletearchive (Boolean)

Falls wahr, wird der DeleteArchive-Job aufgerufen.

Voreinstellung: false

subdomains (Boolean)

Dieses Argument wird an alle untergeordneten Jobs weitergereicht.

Voreinstellung: false

target (String, zipcapsule)

Dieses Argument wird an alle untergeordneten Jobs weitergereicht.

Voreinstellung: zipcapsule

limitCount (Integer)

Dieses Argument wird an den ZipExportJob weitergereicht.

Voreinstellung: 0

limitSizeGB (Float)

Dieses Argument wird an den ZipExportJob weitergereicht.

Voreinstellung: 0.0

ZipExportStatusJob

Der ZipExportStatusJob implementiert den “Ablauf für Katalogisate”. Dabei werden für jede ausgewählte Domain mehrere Schritte durchlaufen:

  1. Neue (freigegebene) Katalogisate bekommen den Zustand “Kapselerstellung zu prüfen”.
  2. Katalogisate im Zustand “Kapsel nicht erstellen”, bei denen die Voraussetzung für diesen Zustand weggefallen ist (z.B. zurückgezogene Freigabe wird erneut erteilt), bekommen den Zustand “Kapselerstellung zu prüfen”.
  3. Falls die Domain-Konfiguration export.retryOnError gesetzt ist: Katalogisate im Zustand “Kapselerstellung fehlgeschlagen” bekommen den Zustand “Kapselerstellung zu prüfen”.
  4. Katalogisate in irgendeinem Zustand, bei denen die Voraussetzung für den Kapselexport weggefallen ist (z.B. Freigabe wird entzogen), bekommen den Zustand “Kapsel nicht erstellen”.
  5. Zu exportierende Katalogisate, für die noch keine Kapseln erstellt wurden, bekommen den Zustand “Kapsel zu erstellen”.
  6. Zu exportierende Katalogisate, für die bereits Kapseln erstellt wurden, bekommen den Zustand “Delta-Kapsel zu erstellen”. Der genaue Ablauf der Prüfung, ob eine Delta-Kapsel erstellt werden soll, wird im Abschnitt “Kriterien für die Erstellung von Delta-Kapseln” beschrieben.

Die folgenden Domain-Einstellungen sind verfügbar:

export.target (String)

Bestimmt das Export-Ziel für diese Domain. Nur Domains (bzw. Subdomains), die das gleiche Export-Ziel wie der Job haben, werden von dem Job bearbeitet.

Voreinstellung: zipcapsule

export.checkWorkflowState (Boolean)

Falls true, wird die Auswahl der zu exportierende Katalogisate auf QA-geprüfte Katalogisate beschränkt (“Strukturierung nicht notwendig” und “Strukturierung abgeschlossen”)

Voreinstellung: true

export.checkReleaseState (Boolean)

Falls true, wird die Auswahl der zu exportierende Katalogisate auf freigegebene Katalogisate beschränkt.

Voreinstellung: true

export.retryOnError (Boolean)

Falls true, werden Katalogisate im Zustand “Kapselerstellung fehlgeschlagen” automatisch zurückgesetzt.

Voreinstellung: false

export.compareMODS (Boolean)

Falls true, erstelle eine Delta-Kapsel, wenn Änderungen im MODS festgestellt werden.

Voreinstellung: true

export.compareDPSection (Boolean)

Falls true, erstelle eine Delta-Kapsel, wenn Änderungen an den VLS-DP-Erweiterungen im Export-METS festgestellt werden. Die VLS-DP-Erweiterungen enthalten zusätzliche VL-Daten, welche im Export-METS nicht nativ abgebildet werden können.

Voreinstellung: false

export.metstype (String)

Der Typ der Export-METS, die erzeugt und auf Änderungen untersucht werden soll. Aktuell wird ausschliesslich vdzip unterstützt.

Voreinstellung: vdzip

Die folgenden Job-Parameter sind verfügbar:

target (String, zipcapsule)

Das Export-Ziel für den Job (aktuell nur zipcapsule).

Voreinstellung: zipcapsule

subdomains (Boolean)

Ob der Job nur in der Job-Domain oder auch allen untergeordneten Domains laufen soll.

Voreinstellung: false

deltaDeepScan (Boolean)

Erzwingt eine Prüfung von Katalogisaten, bei denen die Zeitmarken in der Datenbank alleine keinen Hinweis auf die Notwendigkeit einer Delta-Kapsel geben. Dies kann der Fall sein, wenn Teile eines Katalogisats gelöscht wurden, ohne dass ein übergeordneter Datenbankeintrag eine Aktualisierung der Zeitmarke erhält.

Dieser Test ist langsam und sollte deshalb nur im Einzelfall durchgeführt werden.

showDiff (Boolean)

Zeigt den Unterschied zwischen zwei Export-METS-Dateien, der zum Zustand “Delta-Kapsel zu erstellen” geführt hat, in der Log-Datei.

dryrun (Boolean)

Falls true werden keine Änderungen an der Datenbank vorgenommen.

Voreinstellung: false

ZipExportJob

Der ZipExportJob implementiert den Kapsel-Export für Master- und Delta-Kapseln. Dabei werden grundsätzlich zwei Varianten unterschieden:

  1. target=zipcapsule: Hier ist das Export-Ziel ein Langzeitarchiv. Es werden Master- und Delta-Kapseln über einen langen Zeitraum exportiert. Die Einstellungen finden ausschliesslich über die Domain-Konfiguration statt, da eine unbedarfte, manuelle Änderung in den Job-Parametern zu Inkonsistenten im Langzeitarchiv führen könnte.
  2. target=manual: Hier ist das Export-Ziel eine einmalige, händische Auslieferung einzelner Master-Kapseln. Die Einstellungen finden über die Domain-Konfiguration statt und können durch die Job-Parameter überschrieben werden.

Die folgenden Domain-Einstellungen sind verfügbar:

export.target (String)

Nur für target=zipcapsule.

Bestimmt das Export-Ziel für diese Domain. Nur Domains (bzw. Subdomains), die das gleiche Export-Ziel wie der Job haben, werden von dem Job bearbeitet.

Voreinstellung: zipcapsule

export.destination (String)

Nur für target=zipcapsule (vgl. Job-Parameter destination).

Das Verzeichnis, unter dem die Kapseln abgelegt werden sollen.

Voreinstellung: config.path.zipBackup (aus der Server-Konfiguration)

export.copy_mode (String, keep/copy/move)

Nur für target=zipcapsule.

Bestimmt, ob die Kapseln nach der Erstellung in ein weiteres Verzeichnis kopiert (copy) oder verschoben (move) werden sollen.

Voreinstellung: keep

export.copy_destination (String)

Nur für target=zipcapsule.

Das Verzeichnis, in das die Kapseln kopiert oder verschoben werden sollen (nur bei export.copy_mode=copy oder move)

Voreinstellung: N/A

export.copy_queue_size (Integer)

Nur für target=zipcapsule.

Die Anzahl der parallelen Kopier- oder Verschiebeoperationen (nur bei export.copy_mode=copy oder move). 0 bedeutet, dass alle Operationen sequentiell erfolgen.

Voreinstellung: 3

export.create_report (Boolean)

Nur für target=zipcapsule.

Falls true, wird eine CVS-Datei erstellt, die eine Tabelle aller erstellten Kapseln enthält.

Voreinstellung: false

export.metstype (String)

Der Typ der Export-METS, die erzeugt und auf Änderungen untersucht werden soll. Aktuell wird ausschliesslich vdzip unterstützt.

Voreinstellung: vdzip

export.identname (String, urn/doi/sourceident/struct)

Bestimmt den persistenten Identifikator, der Teil des Kapsel-Namens werden soll. Dieser wird üblicherweise bei Langzeitarchiven zur Referenzierun verwendet.

Voreinstellung: urn

export.arctype (String, zip/tar)

Bestimmt das äussere Archiv-Format der Kapsel.

Voreinstellung: zip

export.compression (Boolean)

Falls true, werden die Kapseln verlustfrei komprimiert. Nicht empfohlen, da Kompression bei Übertragungsfehlern zu grösseren Datenverlusten führen kann. Kompression ist zudem sehr CPU-intensiv, und die zu erwartende Kompressionsrate ist bei Bilddaten nicht sehr hoch.

Voreinstellung: false

export.containertype (String, zipcapsule/bagit)

Bestimmt die Dateistruktur in der Kapsel. Bei zipcapsule werden die Export-Daten direkt in das Archiv gepackt, bei bagit wird das Archiv um weitere Metadaten nach dem BagIt-Standard angereichtert.

Voreinstellung: zipcapsule

export.premistype (String, no_premis/danrw_premis)

Falls danrw_premis, werden die Kapseln zusätzlich um Metadaten nach dem PREMIS-Standard (DA-NRW-Profil) angereichert.

Voreinstellung: no_premis

export.validateImage (Boolean)

Falls true, müssen alle Bilder Prüfsummen in der Datenbank hinterlegt haben. Zusammen mit export.compareChecksum werden diese auch überprüft.

Voreinstellung: false

export.compareChecksum (Boolean)

Falls true, werden alle vorhandenen Prüfsummen nach Erstellung der Kapsel überprüft.

Voreinstellung: true

export.with_public_mets (Boolean)

Falls true, wird in die Kapsel eine OAI-METS Datei unter public_mets.xml abgelegt.

Damit die OAI-METS erzeugt werden kann, muss die Domain-Konfiguration oai.baseUrl gesetzt sein.

Voreinstellung: false

export.export_mets (Boolean)

Falls true, wird neben der Kapseldatei noch eine .xml-METS-Datei erzeugt.

Voreinstellung: false

export.export_checksums (Boolean)

Falls true, wird neben der Kapseldatei noch eine .sha1-Prüfsummendatei erzeugt. Diese enthält die Prüfsumme der Kapsel und, falls export.export_mets gesetzt ist, auch die Prüfsumme der Export-METS-Datei.

Voreinstellung: false

export.email_notification (String)

Falls gesetzt, wird eine Email-Nachricht an die angegebene Adresse geschickt, wenn Fehler beim ZipExportJob auftreten.

Voreinstellung: N/A

Die folgenden Job-Parameter sind verfügbar:

target (String, zipcapsule/manual)

Das Export-Ziel für den Job.

Voreinstellung: zipcapsule

subdomains (Boolean)

Nur für target=zipcapsule.

Ob der Job nur in der Job-Domain oder auch allen untergeordneten Domains laufen soll.

Voreinstellung: false

otids (IntegerList)

Bestimmt die Katalogisate, welche exportiert werden sollen.

Nur für target=manual: Hier können auch Identifikatoren angegeben werden, welche sonst nicht zur Kapselerstellung ausgewählt werden.

Nur für target=zipcapsule: Die Identifikatoren schränken nur die Auswahl für den automatisierten Ablauf ein. Sie müssen sich im richtigen Zustand befinden und über die Job-Parameter (Domain und Subdomain-Einstellung) finden lassen.

Voreinstellung: N/A

destination (String)

Nur für target=manual.

Das Verzeichnis, unter dem die Kapseln abgelegt werden sollen. Die Kapseln werden in einem Unterverzeichnis export-{DATETIME} abgespeichert.

Voreinstellung: config.path.zipBackupManual (aus der Server-Konfiguration)

metstype (String)

Nur für target=manual.

Diese Einstellung entspricht der aus der Domain-Konfiguration und kann diese überschreiben.

Voreinstellung: N/A (aus der Domain-Konfiguration)

identname (String, urn/doi/sourceident/struct)

Nur für target=manual.

Diese Einstellung entspricht der aus der Domain-Konfiguration und kann diese überschreiben.

Voreinstellung: N/A (aus der Domain-Konfiguration)

arctype (String, zip/tar)

Nur für target=manual.

Diese Einstellung entspricht der aus der Domain-Konfiguration und kann diese überschreiben.

Voreinstellung: N/A (aus der Domain-Konfiguration)

compression (Boolean)

Nur für target=manual.

Diese Einstellung entspricht der aus der Domain-Konfiguration und kann diese überschreiben.

Voreinstellung: N/A (aus der Domain-Konfiguration)

containertype (String, zipcapsule/bagit)

Nur für target=manual.

Diese Einstellung entspricht der aus der Domain-Konfiguration und kann diese überschreiben.

Voreinstellung: N/A (aus der Domain-Konfiguration)

premistype (String, no_premis/danrw_premis)

Nur für target=manual.

Diese Einstellung entspricht der aus der Domain-Konfiguration und kann diese überschreiben.

Voreinstellung: N/A (aus der Domain-Konfiguration)

validateImage (Boolean)

Nur für target=manual.

Diese Einstellung entspricht der aus der Domain-Konfiguration und kann diese überschreiben.

Voreinstellung: N/A (aus der Domain-Konfiguration)

compareChecksum (Boolean)

Nur für target=manual.

Diese Einstellung entspricht der aus der Domain-Konfiguration und kann diese überschreiben.

Voreinstellung: N/A (aus der Domain-Konfiguration)

with_public_mets (Boolean)

Falls true, wird in die Kapsel eine OAI-METS Datei unter public_mets.xml abgelegt.

Voreinstellung: N/A (aus der Domain-Konfiguration)

export_mets (Boolean)

Falls true, wird neben der Kapseldatei noch eine .xml-METS-Datei erzeugt.

Voreinstellung: N/A (aus der Domain-Konfiguration)

export_checksums (Boolean)

Falls true, wird neben der Kapseldatei noch eine .sha1-Prüfsummendatei erzeugt. Diese enthält die Prüfsumme der Kapsel und, falls export.export_mets gesetzt ist, auch die Prüfsumme der Export-METS-Datei.

Voreinstellung: N/A (aus der Domain-Konfiguration)

emptyImages (Boolean)

Nur für target=manual.

Falls true, werden die Bilder in der Kapsel durch leere Platzhalter-Dateien ersetzt. Dies ist sinnvoll, falls nur die Metadaten und andere Resourcen (z.B. Volltexte) exportiert werden sollen.

Voreinstellung: false

runDate (String)

Falls gesetzt, bekommen alle erzeugten Kapseln die vorgegebene Zeitmarke. Dies ist nur für automatisierte Tests.

Voreinstellung: N/A

ZipCapsuleStatusJob

Der ZipCapsuleStatusJob implementiert den “Ablauf für Kapseln”. Dabei werden für jede ausgewählte Domain mehrere Schritte durchlaufen:

  1. Kapseln im Zustand “Kapsel neu”, die auf dem Dateisystem nicht mehr vorhanden sind, bekommen den Zustand “Kapsel gelöscht”.

    Diese Zustandsänderung erfolgt auch dann, wenn das Katalogisat nicht mehr an der Kapselverarbeitung teilnimmt, da sie eine externe Tatsache festhält.

  2. Nur für target=zipcapsule:

    Kapseln im Zustand “Kapsel gelöscht”, die im Langzeitarchiv aufgenommen wurden, bekommen den Zustand “Kapsel archiviert”. Gibt es für das gewählte Langzeitarchiv keine Integration, wird dieser Zustand nach 2 Tagen ex silentio angenommen.

    Diese Zustandsänderung erfolgt auch dann, wenn das Katalogisat nicht mehr an der Kapselverarbeitung teilnimmt, da sie eine externe Tatsache festhält.

  3. Nur für target=zipcapsule und export.allowDeleteArchive=true:

    Kapseln im Zustand “Kapsel archiviert” bekommen nach 14 Tagen ex silentio den Zustand “Originalbilder zu entfernen”.

    Kapseln im Zustand “Originalbilder zu entfernen” werden vom DeleteArchiveJob weiter bearbeitet.

Kapseln im Zustand “Kapsel angehalten” werden von der Verarbeitung durch den ZipCapsuleStatusJob ausgenommen.

Die folgenden Domain-Einstellungen sind verfügbar:

export.allowDeleteArchive (Boolean)

Falls true, wird die Kapselverarbeitung bis zum Zustand “Originalbilder zu entfernen” fortgesetzt. Ansonsten hört diese bei “Kapsel archiviert” auf.

Voreinstellung: false

export.archiveTimespan (Integer)

Bestimmt die Anzahl an Tagen, welche der Job wartet, bis der Zustand von “Kapsel gelöscht” zu “Kapsel archiviert” ex silentio geändert wird (nur bei Domains, für die keine Integration ans Langzeitarchiv implementiert ist).

Voreinstellung: 2 (Tage)

export.archiveStatusUrl (String)

Falls gesetzt, wird nach export.archiveTimespan Tagen noch eine Online-Abfrage zum Archivierungsstatus gemacht. Der String enthält die abzufragende URL, und kann folgende Parameter enthalten, die durch die konkreten Kapselangaben ersetzt werden: sb_id (Kapsel-ID), filename (Dateiname der Kapsel), ot_id (VL-ID des gekapselten Werks), mangled_urn (Dateisystem-kompatible Form der URN des Werkes), timestamp (Zeitmarke der Kapsel), generation (Generation der Kapsel), version (Version des Kapselformats), mets_filename (Name der Export-METS-Datei), checksums_filename (Name der Prüfsummendatei).

Benötigt auch export.archiveStatusPattern.

Voreinstellung: N/A

export.archiveStatusPattern (String)

Enthält den regulären Ausdruck, mit das Ergebnis der archiveStatusUrl-Abfrage verglichen wird. Wird ein positiver Treffer festgestellt, so wird angenommen, dass die Kapsel erfolgreich archiviert wurde.

Voreinstellung: N/A

export.removeTimespan (Integer)

Bestimmt die Anzahl an Tagen, welche der Job wartet, bis der Zustand von “Kapsel archiviert” zu “Originalbilder zu löschen” ex silentio geändert wird (nur bei Domains mit export.allowDeleteArchive=true).

Voreinstellung: 14 (Tage)

DeleteArchiveJob

Der ZipCapsuleStatusJob vervollständigt den “Ablauf für Kapseln” für Kapseln im Zustand “Originalbilder zu entfernen”. Er löscht alle Originalbilder für solche Kapseln und setzt den Zustand auf “Originalbilder entfernt”.

Die folgenden Domain-Einstellungen sind verfügbar:

export.allowDeleteArchive (Boolean)

Falls true, wird die Kapselverarbeitung bis zum Zustand “Originalbilder zu entfernen” fortgesetzt. Ansonsten hört diese bei “Kapsel archiviert” auf.

Voreinstellung: false

Die folgenden Job-Parameter sind verfügbar:

dryrun (Boolean)

Falls true werden keine Änderungen an der Datenbank vorgenommen.

Voreinstellung: false

EadExportJob

Der EadExportJob erlaubt die Archivierung der Metadaten einer Sammlung, die nicht in den Metadaten der Katalogisate enthalten sind. Ausserdem enthält die EAD eine Liste aller Katalogisate einer Sammlung.

Die EAD-Dateien werden unter dem Dateinamen ead_SAMMLUNG_ZEITMARKE.xml abgelegt, also zum Beispiel: ead_retro_20160401T122731.xml.

Falls ein ZIP-Archiv erstellt wird, ist der Name der ZIP-Datei ead_SAMMLUNG_ZEITMARKE.zip, wobei sich die Sammlung auf die Job-Domain bezieht.

Die folgenden Job-Parameter sind verfügbar:

arctype (String, zip/xml)

Falls zip wird eine ZIP-Datei erstellt, welche die EAD-Dateien enthält. Falls xml wird für jede EAD-Datei eine separate Datei erstellt.

Voreinstellung: zip

destination (Boolean)

Das Ausgabeverzeichnis.

Voreinstellung: config.path.eadBackup (aus der Server-Konfiguration)

Use Cases

Die Ausgangslage für alle Fälle ist:

Abnahmestatus

abgenommen

Freigabestatus

freigegeben

ZIP-Kapsel

Kapsel erstellt (Originalbilder gelöscht)

Neues Bild hinzufügen

  1. Freigabe des Werks entziehen
  2. Neues Bild mit dem VLM hochladen und positionieren
  3. Werk wieder freigeben

Der nächtliche ZipExportStatusJob erkennt, dass neue Strukturen angelegt wurden und ein Bild ein neues Änderungsdatum als die letzte Kapsel bzw die letzte Überprüfung besitzt. Der Job setzt daher den Status Delta Kapsel zu erstellen. Der nachgelagerte ZipExportJob reagiert auf den Status, erstellt eine Kapsel, die das neue Bild und ein aktuelles METS enthält und setzt den Status auf Kapsel vorhanden. Der weitere Verarbeitungsprozess erfolgt analog zum normalen Kapselverfahren.

Vorhandenes Bild ersetzen

  1. Freigabe des Werks entziehen
  2. Bild mit dem VLM auswählen und ersetzen
  3. Werk wieder freigeben

Der weitere Ablauf erfolgt genau wie unter Neues Bild hinzufügen_. Die Deltakapsel enthält das geänderte Bild und ein neues METS.

Verknüpfung zu einem Bild entfernen oder erstellen

  1. Freigabe des Werks entziehen
  2. Verknüpfung mit dem VLM anlegen oder entfernen
  3. Werk wieder freigeben

Der weitere Ablauf erfolgt genau wie unter Neues Bild hinzufügen_. Die Deltakapsel enthält nur das neue METS und kein Bild. Bei Verknüpfungen in einem Werk wird das Bild nur einmal gespeichert.

Vorhandenes Bild oder Strukturierung löschen

  1. Freigabe des Werks entziehen
  2. Bild oder Strukturknoten mit dem VLM entfernen
  3. Werk wieder freigeben

Dieser Fall wird zur Zeit noch nicht performant erkannt, da nach dem Löschen eines Eintrags die Informationen in der Datenbank fehlen. Hierzu ist ein zeitaufwändiger Vergleich der Daten mit den gespeicherten METS-Dateien aus dem Kapselprozess notwendig. Die Tiefensuche ist über neue Optionen im ZipExportStatusJob möglich und kan mehrere Stunden in Ansprucn nehmen.

Primärer Identifier wird geändert

Der primäre Identifier ist der Identifier, mit dem das Werk und die dazugehörigen Kapseln eindeutig zugeordnet werden, zum Beispiel URN, DOI oder die Systemnummer des Katalogs, falls beim Export keine URN oder DOI verwendet wird.

Die nachträgliche Veränderung des primären Identifiers wird nicht unterstützt. In diesem Fall muss eine neue und Hauptkapsel erzeugt und die Kapseln mit dem alten Identifiern aus dem Archiv gelöscht werden. Falls die Bilder in der Zwischenzeit gelöscht wurden, müssen sie erst re-importiert werden.

Verschieben von Bildern und Strukturen zwischen Werken

Nachdem ein Werk freigegeben und archiviert wurde, wird die Verschiebung von Bildern und Strukturen zwischen Werken nicht unterstützt.

Achtung

Zwar können Delta-Kapseln diese Änderungen wiedergeben, aber die SYS_Backup2Page-Tabelle wird in diesem Fall nicht korrekt nachgepflegt. Originalbilder könnten gelöscht werden, die für die neue Master- oder Delta-Kapsel gebraucht würden.

DA-NRW

Für Sammlungen, die in das Langzeitarchiv DA-NRW überführt werden sollen, gibt es gesonderte Einstellungen.

Contract

Der Contract regelt die Weiterverwendung der Digitalisate im Langzeitarchiv DA-NRW, und wird definiert durch die Metadaten in der PREMIS-Datei (Element “rightsExtension” nach Schema “danrw-contract-1.xsd”).

Für die VLS sind derzeit zwei Contracts definiert:

öffentliche Präsentation

Dieser Contract erlaubt die Weiternutzung des Werks im Präsentationsportal.

gesperrte Präsentation

Dieser Contract verbietet die Weiternutzung des Werks im Präsentationsportal.

Beide Contracte erlauben dieunbeschränkte Formatmigration im Archiv.

Die Auswahl des Contracts kann auf mehreren Ebenen erfolgen:

  1. Enthält das Katalogisat nicht-veröffentlichte Seiten, Farbtafeln, oder Auftragsblätter, so wird der Contract “gesperrte Präsentation” gewählt.
  2. Ansonsten: Wurde in der VLM ein Contract für das Katalogisat ausgewählt, so wird dieser Contract benutzt.
  3. Ansonsten, falls das Katalogisat Teil einer Kollektion (Klassifikation) ist (und nicht nur in dieser verlinkt wird): Wurde in der VLM ein Contract für die Kollektion (Klassifikation) ausgewählt, so wird dieser Contract benutzt.
  4. Ansonsten: Wurde in der VLM ein Contract für die Sammlung ausgewählt, so wird dieser Contract benutzt.
  5. Ansonsten: Ist für den Sammlungstyp ein Contract als Voreinstellung festgelegt, so wird dieser Contract benutzt.

Voreinstellungen gibt es für die Sammlungstypen “retro” (öffentliche Präsentation) und “epflicht” (gesperrte Präsentation).

DA-NRW

http://www.danrw.de/

BagIt

http://tools.ietf.org/html/draft-kunze-bagit

PREMIS

PREMIS Data Dictionary for Preservation Metadata

  1. http://www.loc.gov/standards/premis/
  2. http://www.loc.gov/standards/premis/understanding_premis_german.pdf