Die unten stehende Grafik Integritätsprüfung in der Ablauforganisation zeigt, wann im Verlauf eines Objektlebenszyklus Prüfverfahren zur Wahrung der Datenintegrität und Vollständigkeit durchgeführt werden und, wie sie in die bestehenden Systemprozesse implementiert wurden. Die Nummerierung der Überschriften korrespondiert mit der Nummerierung der Ereignisse in der Grafik.
Trifft ein digitales Objekt bei Mitarbeitenden eines Erwerbungsteams ein, führen diese als Teil der Qualitätskontrolle eine Prüfung auf Vollständigkeit durch. Vor dem Aufruf des Objekts durch die Mitarbeitenden wird eine Virenprüfung durchgeführt.
Trifft eine Charge Digitalisate vom Dienstleister ein, wird die Charge auf Vollständigkeit anhand einer Liste der übergebenen Filme überprüft und die vom Dienstleister erstellten MD5-Prüfsummen werden überprüft. Stimmen die Prüfsummen nicht überein oder ist die Filmliste nicht vollständig, werden die jeweiligen Digitalisate reklamiert.
Trifft eine Datenlieferung von einem Datenproduzenten ein, werden die mitgelieferten MD5-Prüfsummen überprüft, sofern welche übergeben werden. Die Prüfung auf Vollständigkeit erfolgt in Abhängigkeit vom Datenproduzenten entweder auf Datei-, Artikel- oder Zeitschriftentitelebene, entweder über eine vom Datenproduzenten erstellte Referenzliste, oder über eine vom Team Langzeitarchivierung erstellte Liste abzuholender Artikel und deren Dateien.
Die Prüfung auf Vollständigkeit ist Teil der Pre-Ingest-Analyse.
In Rücksprache mit dem zuständigen Erwerbungsteam übernimmt das Team Langzeitarchivierung die Objekte aus den definierten Transferverzeichnissen und kopiert die Objekte mit einem WinSCP-Client über eine SSH-verschlüsselte SFTP-Verbindung auf einen Server in das Quellverzeichnis der Submission Application.
Für die Qualitätskontrolle werden die Digitalisate mit einem WinSCP-Client über eine SSH-verschlüsselte SFTP-Verbindung in ein designiertes Verzeichnis hochgeladen. Nach erfolgreich durchlaufener Qualitätskontrolle werden die Digitalisate in ein Quellverzeichnis für das CSV-Script kopiert.
Die Dateien werden für die Qualitätskontrolle über eine SSH-verschlüsselte SFTP-Verbindung in ein designiertes Verzeichnis hochgeladen. Dieser Schritt wird entweder vom Team Langzeitarchivierung mittels WinSCP-Client oder vom Datenproduzenten selbst ausgeführt.
Nach erfolgreich durchlaufener Qualitätskontrolle werden die Daten in ein Quellverzeichnis für das CSV-Script kopiert.
Der SFTP-Standard beinhaltet interne Mechanismen zur Überprüfung gegen Integritätsverletzung während der Übertragung.
Der WinSCP-Client behält die ursprünglichen Datums- und Zeitstempel der Dateien bei.
Die Transformation der Transferpakete zu Rosetta-konformen SIPs und AIP ist in der Grafik Transformation von Eingangspaketstrukturen zu SIPs und AIPs und den Ingest-Prozessdiagrammen „METS-Deposit“ und „CSV-Deposit“ beschrieben.
Die Submission Application wurde mit dem von Ex Libris zur Verfügung gestellten SDK entwickelt und wandelt die verschiedenen Datenstrukturen der Erwerbungsteams (Eingangspaketstrukturen) zu Rosetta-konformen SIPs um. Die Submission Application erzeugt die Rosetta-konformen SIPs aus Eingangspaketstrukturen und übergibt diese in einem zweiten Schritt an Rosetta.
Die Submission Application erzeugt bei der Erstellung der Transferpakete eine MD5-Prüfsumme pro Datei und speichert diese in einer METS-Datei. Die Namen aller zu dem SIP gehörenden Dateien werden in der structMap der METS-Datei erfasst. Die erzeugten Rosetta-konformen SIPs werden mit dem Anstoßen des Deposit-Prozesses an Rosetta übergeben.
Abgelieferte MD5-Prüfsummen werden bei der technischen Qualitätskontrolle überpüft.
Das CSV-Script schreibt, sofern vorhanden, mitgelieferte MD5-Prüfsummen zu jeder Datei in die CSV-Datei. Die Namen aller zu dem SIP gehörenden Dateien werden in der CSV-Datei erfasst. Die erzeugten Rosetta-konformen SIPs werden mit dem Anstoßen des Deposit-Prozesses an Rosetta übergeben.
Abgelieferte MD5-Prüfsummen werden, sofern vorhanden, bei der Eingangskontrolle überprüft.
Das CSV-Script schreibt, sofern vorhanden, mitgelieferte MD5-Prüfsummen zu jeder Datei in die CSV-Datei. Die Namen aller zu dem SIP gehörenden Dateien werden in der CSV-Datei erfasst. Die erzeugten Rosetta-konformen SIPs werden mit dem Anstoßen des Deposit-Prozesses an Rosetta übergeben.
Für die Anbindung des Institutionellen Repositoriums der Leibniz Universität Hannover an das digitale Langzeitarchiv über eine OAI-Schnittstelle nutzt die TIB die Submission Application der ZBW nach. Die Konfiguration der Submission Application übernimmt die TIB selbst.
Für jede bekannte OAI-Record-ID vergibt und aktualisiert die Submission Application den Bearbeitungsstatus während der Abholung vom Repository im Workflow (z.B. „New“, „Imported“, „Ingested“).
Der Deposit erfolgt über den Deposit Webservice. Die Submission Application trackt via SIP-Status Webservice den Status der an Rosetta übermittelten SIPs und aktualisiert so den Bearbeitungsstatus im Workflow. Die für den Record vergebene SIP-ID wird in eine interne Datenbank der Submission Application geschrieben.
Die Submission Application erzeugt bei der Erstellung der Transferpakete eine MD5-Prüfsumme pro Datei und speichern diese in einer METS-Datei. Die Namen aller zu dem SIP gehörenden Dateien werden in der structMap der METS-Datei erfasst.Die erzeugten rosetta-konformen SIPs werden mit dem Anstoßen des Deposit-Prozesses an Rosetta übergeben.
Wird der Deposit angestoßen, durchläuft das rosetta-konforme SIP den Validation Stack. Im Validation Stack erfolgen:
Im Deposit-Prozess wird zur Prüfung der Vollständigkeit überprüft:
Während des Transformationsprozesses wird das SIP mit zusätzlichen Metadaten angereichert und in verschiedene Speicherbereiche verschoben. Für jedes SIP erzeugt das Langzeitarchivierungssystem eine METS-Datei. Bei jedem Transfer werden drei Prüfsummen neu gebildet und mit den in der METS-Datei gespeicherten abgeglichen, zusätzlich wird mittels StructMap die Vollständigkeit überprüft.
Bei jedem AIP-Update wird eine IE vom permanenten in den operativen Speicher kopiert. Bei jedem Transfer werden die Prüfsummen neu gebildet und mit den gespeicherten abgeglichen, zusätzlich wird mittels StructMap die Vollständigkeit überprüft. Die Integritätsprüfung kann darüber hinaus unabhängig von einem Transfer als Rosetta-interner Prozess angestoßen werden.
Die Mechanismen zur Integritätssicherung des Archivspeichers sind unter Archivspeicher beschrieben.
Pro Datei sind in Rosetta drei Prüfsummen gespeichert, beim Export werden die Prüfsummen erneut gebildet und abgeglichen. Alle zur Repräsentation gehörenden Dateien sind in der ie.xml erfasst. So wird sichergestellt, dass die Datenintegrität beim Export gesichert ist und die Daten vollständig sind.
Kommt es beim Export zu einem Fehler, wird der Prozess abgebrochen und das System gibt eine entsprechende Fehlermeldung aus.
Zum Vergrößern bitte anklicken