Kosten des Ingest
Der Begriff Ingest meint die Übernahme des Archivinformationspakets in das Archiv. Für die Erstellung der SIPs (=Submission Information Package*) müssen vorher die signifikanten Eigenschaften definiert werden. Damit sind jene Eigenschaften des digitalen Objekts gemeint, die erhalten werden sollen. Dies muss nach Bedarf zumindest einmalig für Objektgruppen entschieden werden. So würden zum Beispiel in PDF-Dateien eingebundene 3D-Modelle in ihrem Funktionsumfang reduziert werden und ihre Funktionalität würde eingeschränkt. Je nach Definition der signifikanten Eigenschaften müsste man für den Erhalt dieser Eigenschaften auf eine Migration /Einbettung in eine PDF-Datei verzichten.
Für jede Datensammlung für zunächst ein geeignetes und archivfähiges Format ausgewählt und ggf. ein Arbeitsablauf erstellt, wie die zu archivierenden Objekte in das Format migriert werden. Dieser Schritt gehört in der Regel zum Pre-Ingest, kann aber - je nach Umfang der Ingestdefinition - auch während des Ingests erfolgen.
Während des Ingestprozesses kann ein Objekt auch mit (dekriptiven und/oder technischen) Metadaten angereichert werden, die dann mit dem Dokument an sich gespeichert werden.
Gegenwärtige Best Practice Workflows sehen oft vor, das SIP bereits im Pre-Ingest auf eine bestimmte Qualität zu bringen, um das gewünschte Ingestlevel zu erreichen. Daher fallen Kosten für bestimmte Arbeitsschritte je nach Workflows im Pre-Ingest oder im Ingest an.
Ein Beispiel hierfür sind nach dem Validierungstool Jhove als nicht wohlgeformt deklarierte PDF-Dateien. Diese würden laut nach den Ingestlevel Definitionen des DP4Lib Projekts nur das Ingestlevel 3 erreichen, gewünscht ist aber in vielen Digitalen Archiven das Ingestlevel 4. Das Ingestlevel 4 verlangt, dass eine Datei ihren Formatspezifikationen entsprechend wohlgeformt und valide ist. Das Risiko der Obsoleszenz wird für solche Dateien im Allgemeinen als niedriger angesehen, so dass Migrationen und Reparaturen hier oft nicht oder erst nach längerer Zeit notwendig werden und die Langzeitarchivierung solcher Objekte daher auch kostengünstiger ist.
Das Beheben dieses Makels kann sowohl im Pre-Ingest, im Ingest, als auch sogar später, in der Curation-Phase, erfolgen, wenn die Objekte bereits im Archiv gespeichert sind und aus den SIPs AIPs geworden sind.
Übliche Best Practice ist, dieses Problem zu lösen oder zumindest zu erkennen. Dies ist mit hohem personnellen Aufwand verbunden. Je nachdem an welcher Stelle die jeweilige Institution das Problem bearbeitet und löst, entstehen in jener Phase auch die Kosten. Da Kosten für Migrationsvorgänge und Normalisierungsaufgaben in der Regel recht hoch eingeschätzt werden, kann dies zu deutlichen Kostenunterschieden zwischen den Archiven führen.
Außerdem treiben Probleme wie dieses den Durchschnittpreis pro zu archivierendem Objekt in die Höhe, auch hier gilt die 80/20-Regel, 20% der Dokumente erzeugen 80% der Kosten.
Hat ein Digitales Archiv die Möglichkeit, den Ingest solcher Objekte abzulehnen und zwecks weiterer Bearbeitung an den Datenproduzenten zurückgehen zu lassen, entstehen die Kosten dort und nicht erst in der Digitalen Langzeitarchivierung. Dies kann zu enormen Kostenunterschieden für die LZA zwischen verschiedenen Institutionen führen und die Vergleichbarkeit erschweren.
Im Folgenden wird ein Fallbeispiel für einen Ingest-Vorgang erläutert, es handelt sich hierbei um einen größtenteils automatisierten Workflow.
Fallbeispiel ZBW
Die Objekte im DSpace Open Access Dokumentenserver EconStor der Zentralbibliothek für Wirtschaftswissenschaften werden in dessen digitalen Archiv gespeichert. Der Dokumentenserver beinhaltet zurzeit etwa 80.000 Objekte, größtenteils im PDF-Format. Pro Jahr kommen mehr als 15.000 digitale Objekte dazu. Der Ingest-Workflow sieht eine Automatisierung aller Arbeitsschritte vor, so dass das Personal lediglich die Ausnahmen manuell sichten und bearbeiten muss.
Zur Einrichtung und Wartung des Workflows waren zwei Mitarbeiter notwendig: Ein IT-Entwickler, um die dazugehörigen Schnittstellen zu entwickeln und der Projektmanager für die Langzeitarchivierung, um die Workflows zu konfigurieren und die Absprachen mit anderen Abteilungen (Dokumentenserver EconStor und Katalogisierungsabteilung) zu treffen.
Da es sich bei diesem Ingest-Workflow um den ersten handelte, der in dem Langzeitarchivierungssystem, basierend auf Rosetta, eingerichtet wurde, war die Arbeitszeit dementsprechend länger als für spätere Ingest-Workflows. Während spätere Konfigurationen lediglich noch wenige Arbeitstage inklusive Absprache mit den für die digitale Sammlung verantwortlichen Abteilung erforderten, wurden für die Einrichtung des ersten Workflows mehrere Wochen benötigt.
Außerdem als sehr resourcenintensiv stellte sich der Wunsch heraus, ein Metadatenmapping von dem in der ZBW verwendeten Pica-Format in das von Rosetta verwendete Dublin Core Format zu erstellen. Da der Anspruch formuliert wurde, jedes Metadatenfeld zu mappen und der Abstimmungsbedarf sehr groß ist, ist hier ebenfalls eher von Wochen und Monate als von wenigen Tagen zu sprechen. Für spätere Workflows wurde kein umfangreiches Mapping mehr geschrieben, sondern nur die wichtigsten Felder gemappt (Titel, Persistent Identifier, Autoren, Erscheinungsjahr, …) und die anderen deskriptiven Metadaten zwar mit in das Langzeitarchivierungssystem überführt, aber im Ursprungsformat belassen und nicht aktiv durchsuchbar im Langzeitarchiv gemacht.
Die Entwicklung der Submission Application, die die Objekte von DSpace nach Rosetta überführt, hat lediglich rund 80 Personenstunden in Anspruch genommen und die Wartung der Application nimmt auch nur wenige Stunden im Monat in Anspruch (rund 25 Personenstunden jährlich). Der Ingest läuft - sofern es nicht zu Problemen und Ausnahmen kommt - seit 2011 automatisiert ab und neue Objekte werden zeitnah über Nacht abgearbeitet und in das Archiv überführt.
Der Ingest-Workflow beinhaltet das automatisierte Anreichern mit deskriptiven Metadaten durch eine Anbindung via SRU-Schnittstelle an den GVK des GBV, das Generieren von Hashwerten, ein Virus-Check der Dateien, die Formatidentizierung und das Erstellen technischer Metadaten mittels DROID und JHOVE und die Formatvalidierung durch JHOVE.
Schon nach wenigen Wochen stellte sich heraus, dass eine Ausnahme so häufig auftrat, dass auch hier eine automatisierte Lösung entwickelt werden musste, da sonst der personnelle Bedarf zu hoch gewesen wäre. Das Validierungstool Jhove lehnte rund 20% der PDF-Dateien von EconStor als nicht wohlgeformt (4% sind zusätzlich auch invalid) ab und stoppt den Ingest für die Objekte. Die Anzahl dieser Dateien wuchs innerhalb kürzester Zeit auf eine vierstellige Zahl.
Es wurde entschieden, dieses Problem automatisiert nach der Überführung in das Langzeitarchiv zu lösen. Viele andere Gedächtnisinstitutionen lösen dies jedoch im Ingest oder gar in der Pre-Ingest-Phase, weshalb jene Workflows dann entsprechend aufwändiger und auch kostenaufwändiger sind.
Zwar war die Entwicklung dieses ersten Workflows ungewöhnlich ressourcenintensiv, jedoch konnten fast alle Teile für folgende Sammlungen nachgenutzt werden. Die Submission Application kann so bearbeitet werden, dass sie für neue Sammlungen an anderen Orten und aus anderen Systemen greift, die Programmierzeit war stets wesentlich kürzer. Der Output - das Langzeitarchiv Rosetta - ist jedesmal identisch.
Die Konfigurationseinstellungen müssen zwar für jeden neue Sammlung neu eingetragen werden, doch mit wachsender Erfahrungen der Abhängigkeiten und Auswirkungen der Parameter, sowie vorhandener Templates, kann dies inzwischen innerhalb weniger Arbeitstage verwirklicht werden.