Seitenhierarchie

Sie zeigen eine alte Version dieser Seite an. Zeigen Sie die aktuelle Version an.

Unterschiede anzeigen Seitenhistorie anzeigen

« Vorherige Version anzeigen Version 2 Nächste Version anzeigen »

Erhalt der Datenintegrität als Teil der Prozessroutinen

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.

1.    Vollständigkeitsprüfung im Erwerbungsprozess

Trifft ein digitales Objekt bei einem Mitarbeitenden eines Erwerbungsteams ein, führt dieser als Teil der Qualitätskontrolle eine Prüfung auf Vollständigkeit durch. Vor dem Aufruf des Objekts durch den Mitarbeitenden wird eine Virenprüfung durchgeführt.

2.    Pre-Ingest-Analyse

Die Prüfung auf Vollständigkeit ist Teil der Pre-Ingest-Analyse.

3.    Upload der Objekte in das Quellverzeichnis der Submission Application

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.

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.

4.    Erzeugen von Rosetta-konformen SIPs aus definierten Eingangspaketstrukturen

Die Transformation der Transferpakete zu Rosetta-konformen SIPs und AIP ist in der Grafik Transformation von Eingangspaketstrukturen zu SIP und AIP und dem Prozessdiagramm Automatischer Ingest beschrieben.

Die Submission Application wandelt die verschiedenen Datenstrukturen der Erwerbungsteams (Eingangspaketstrukturen) zu Rosetta-konformen SIPs um und wurde mit dem von Ex Libris zur Verfügung gestellten SDK entwickelt. Die Submission Application erzeugt die Rosetta-konformen SIPs aus unterschiedlichen Eingangspaketstrukturen und übergibt diese in einem zweiten Schritt an Rosetta.

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.

Beide Submission Applications erzeugen 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.

5.    Deposit: Abgabe der Objekte in Rosetta

Wird der Deposit angestoßen, durchläuft das Rosetta-konforme SIP den Validation Stack. Im Validation Stack erfolgen:

  • Formatidentifikation mit DROID
  • Formatvalidierung mit JHOVE
  • Bildung von drei Checksummen pro Datei; beim METS-Deposit Gegenprüfung von mitgelieferten Checksummen, wenn vorhanden.
  • Viruscheck
  • Extraktion technischer Metadaten mit JHOVE, mediainfo oder dem NLNZ Metadata Extraction Tool
  • Validierung der METS-Datei

Im Deposit-Prozess wird zur Prüfung der Vollständigkeit die StructMap-Sektion der von der Submission Application erzeugten METS-Datei überprüft.

6.    Transformation des SIP zu einem AIP

Während des Transformationsprozesses wird das SIP mit zusätzlichen Metadaten angereichert und in verschiedene Speicherbereiche verschoben. Bei jedem Transfer werden drei Prüfsummen neu gebildet und mit den gespeicherten abgeglichen, zusätzlich wird mit der StructMap die Vollständigkeit überprüft.

7.1   AIP-Update und Integritätsprüfung als Prozess

Bei jedem AIP-Update wird eine Kopie einer IE vom permanenten in den operativen Speicher verschoben. Bei jedem Transfer werden die Prüfsummen neu gebildet und mit den gespeicherten abgeglichen, zusätzlich wird mit der StructMap die Vollständigkeit überprüft. Die Integritätsprüfung kann darüber hinaus aus unabhängig von einem Transfer als rosettainterner Prozess angestoßen werden.

7.2   Integritätssicherungsmechanismen des Archivspeichers

Die Mechanismen zur Integritätssicherung des Archivspeichers sind unter Archivspeicher beschrieben.

8. Export

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.


Integritätsprüfung in der Ablauforganisation


  • Keine Stichwörter