 |
| Quelle: Wikisource, public domain |
Die Frage kam auf, weil mit dem Dienstnehmer gerade die Übernahmevereinbarung verhandelt wird und wir für unsere eigenen Workflows strenge Validitätskriterien ansetzen.
Zuerst waren wir verunsichert. "Ja, man müsste die validen und invaliden Dateien ja im gleichen Speicher zusammenhalten", aber auch "wenn, dann müssten wir diese Dateien aber als valide oder invalide markieren".
Oder auch: "Die Submission Application könnte doch validieren und je nach Ergebnis die Daten in den einen oder anderen Workflow schieben".
Wir beide haben uns hingesetzt, nochmal unser LZA-System angeschaut und uns intensiver Gedanken dazu gemacht.
Unsere Software erlaubt es nicht, invalide Dateien in das LZA zu lassen. Man muss sich vorher für einen Workflow die Qualitätsparameter überlegen. Wenn wir eigene Validatoren benutzen, können die Qualitätsparameter (Policies) frei gewählt sein. Wir könnten jeden Mist durchlassen oder eben nur streng definierte Qualitätsperlen.
Für diesen Workflow wird all das Material ins Archiv gelassen, das diese erfüllt.
Sind die Anforderungen nicht erfüllt, landen die SIPs beim 'technical analyst', der nur die Wahl hat zwischen
- "Reject", also Zurückweisung mit Option des erneuten Ingests
- "Decline" als generelle Abweisung oder
- direkte Reparatur innerhalb der 'technical analyst'-Workbench
Eine Mischung von "validen" und "invaliden" Dateien bleibt aber auch nach längerer Überlegung nicht sinnvoll:
Die strikte Trennung der Workflows in unserem Archivsystem dient ja gerade dazu, die IEs à la Aschenputtel "die schlechten ins Kröpfchen, die guten ins Töpfchen" zu sortieren.
Damit steigt die Grundqualität in den jeweiligen Workflows und, dies ist entscheidend, man hat im Falle der Formatmigration weniger Fehlerfälle und geringeren Aufwand.
Durch eine, wie auch immer geartete, Markierung, die in unserem System aber nicht direkt möglich ist, würden wir die Einhaltung unserer eigenen Policies gefährden.
Dies führte dann auch dazu, dass man sich von der Maxime leiten ließe, "später (wenn wir mehr Personal/Zeit/bessere Technik haben) können wir das ja vielleicht mal reparieren". Dass dieser Ansatz funktionieren soll, konnte uns bisher kein Archiv zeigen.
Eine Validierung innerhalb der Submission Application ist genauso wenig sinnvoll. Sie soll weder jetzt noch zukünftig die Aufgaben des Archivsystems übernehmen. Dies würde sonst dazu führen, dass man Teile des bestehenden LZA-Systems selbst nachbauen würde.
Gegenüber dem Dienstnehmer würden wir so argumentieren, dass dieser ja bei uns die Dienstleistung "Langzeitarchivierung" einkauft. Wir werden bezahlt, ihre Qualität hochzuhalten, oder in Prosa: "Der regelmäßige Tritt in den Hintern des Dienstnehmers führt zu Glücksgefühlen und ist ihm viel Geld wert."
Wer das nicht für sinnvoll erachtet, dem dürfte ein einfacher Sicherungsdienst ausreichen. Dafür gibt es genügend Anbieter am Markt.
Fazit
Manchmal braucht es ein paar Minuten nochmal über die eigene Rolle als Langzeitarchivar nachzudenken. Und es ist gut, wenn wir uns auch unter Druck diese Zeit nehmen.Nachtrag
Eine weitere Möglichkeit wäre, in unserem Langzeitarchivsystem den Speicherbereich, in dem die Fälle des 'technical analyst' landen, stärker abzusichern (zB. durch 3-fache Kopien).Damit würden all die IEs, die valide sind weiter in den Langzeitspeicher wandern und wären bestens langzeitarchiviert.
Und all jene IEs, die nicht vollumfänglich valide sind, landen im Speicherbereich des 'technical analyst' und würden bei Reparatur oder nach spätestens 10 Jahren dort gelöscht. Dieser Speicherbereich sichert dann dem Dienstnehmer nur 'bitstream preservation' zu und für diesen bleibt das Risiko und der Reparaturaufwand transparent.
Der Druck die IEs sauber ins LZA-System einzuliefern kommt durch die deutlich höheren Speicherkosten für den Zwischenspeicherbereich zustande, da dieser auf auf Festplatten und nicht auf Band basiert.
The good must be put in the dish, the bad you may eat if you wish.
Just this week we were asked to develop a stretegy for treating invalid data that we provide a digital preservation service for. The question arose because we currently are in the negotiations of the transfer agreement with our customer and we set a very strict quality policy for our own workflows. At first, we were a little uneasy. "Yes, valid and invalid data would need to be kept in the same storage.", but also "if we do this, then we'd have to flag valid and invalid files to keep them apart." Or in other words: "The Submission Application could run the validation and move the data through different workflows, depending on the validation result." So we both sat down, took a deeper look into our preservation system and contemplated a little longer on this problem.Our software does not allow invalid data into the permanent repository. The quality parameters for each workflow have to be concepted in advance. If we use our own validators, the policy for the quality parameters can be chosen freely. We either could allow any crap or just maticulously chosen pearls of quality through to our permanent repository. For the workflow that will be configured, all material that complies with whatever policy we set up will be let through to the permanent storage. If the requirements aren't met, the SIPs end up with the 'technical analyst', who now has to choose between:
- "Reject"ing the ingest with optional re-ingest
- "Decline"ing the ingest and disallowing re-ingest
- immediate repair inside of the 'technical analyst' workbench
The 'technical analyst' cannot move the SIP between workflows.
In conclusion, mixing "valid" and "invalid" files doesn't seem sensible. The strict workflow separation in our preservation system is there for the sole purpose of sorting the SIPs like Cinderella dit with the lenses: "The good must be put in the dish, the bad you may eat if you wish." This increases the basic quality level for corresponding workflow and, this is very important, lowers the efforts and number of error cases in case of a format migration.
By using whatever kind of flagging (which isn't possible with our current system), we would endanger the enforcement of our own policies. This would make us follow the maxime that "we can fix this later, once we have more personnel/time/better technology". However, until now, no archive could show us proof that this concept actually worked.
Running the validation inside of the Submission Application isn't sensible, either. It's not the Submission Application's job to take over any tasks from the preservation system. Memory institutions generally will want to avoid re-implementing parts of the preservation system.
In a discussion with our customer we would argue that they are paying us for the service of preserving their content and keeping it useable over long time periods. We are paid to keep their quality high, or to paraphrase: "Kicking the customers' bottoms is part of the service that you are paying us a lot of money for and is useful for both sides alike." Any institutions that don't think this is necessary will be better off using one of plenty of normal backup services available on the market.
