Validierungsfehler sind unter dem Reiter Validation zu finden. Dort besteht die Möglichkeit, die Fehler entweder zu korrigieren oder zu ignorieren.

Treten Validierungsfehler auf, kann das gesamte betroffene Submission Information Package (SIP) nicht in den Permanentspeicher verschoben werden. Um das SIP permanent zu speichern, ist es nötig eine Fehleranalyse durchzuführen und über dessen Behandlung zu entscheiden.

Fehleranalyse

Grundsätzlich gilt, dass die Beschaffenheit von Daten möglichst früh in ihrem Entstehungsprozess optimiert werden sollte, um die Objekte sauber in weitere Zielsysteme überführen und langfristig erhalten zu können.

Treten nach der Einlieferung in Rosetta Fehler auf, liegt die Analyse und abschließende Entscheidung über den Umgang mit dem jeweiligen Fehler bei der einliefernden Institution, also dem Kooperationspartner. Die Datenhoheit verbleibt immer beim Kooperationspartner - dies umfasst die Entscheidungsgewalt über die einzuliefernden und eingelieferten Objekte und die Verantwortung für deren Datenqualität.

Zur Fehleranalyse ist es notwendig, die Auswirkung des gemeldeten Fehlers auf das jeweilige Objekt einzuschätzen und abzuwägen, ob diese die spezifischen signifikanten Eigenschaften des Objekts beeinträchtigt oder nicht. Je nachdem, wie diese Einschätzung ausfällt, kann ein fehlerhaftes Objekt entweder ausgetauscht und der Fehler auf diese Weise behoben werden oder das fehlerhafte Objekt kann, ergänzt um eine entsprechende Erläuterung, in unveränderter Form permanent in Rosetta gespeichert werden.

Fehlerbehebung

Im Technical Analyst (TA) ist es möglich, die fehlerhaften Dateien durch valide Dateien zu ersetzen. Dazu können die fehlerhaften Dateien entweder heruntergeladen und repariert oder durch valide Dateien ersetzt werden, die vom Datenproduzenten neu erzeugt worden sind.

Daraufhin werden die Dateien in Rosetta ersetzt.

Über den Button Work On können Dateien detailliert angesehen und zur Reparatur heruntergeladen werden.

Manuelles Behandeln von Fehlern

Wenn auftretende Validierungsfehler nicht das Rendering von Dateien beeinträchtigen, können Institutionen diesen Fehler behandeln, indem sie ihn ignorieren und die Dateien in unveränderter Form in den Permanentspeicher von Rosetta verschieben. Sobald eine Möglichkeit zur Fehlerbehebung bekannt ist, können die Fehler auch zu einem späteren Zeitpunkt korrigiert werden, auch wenn sich die Dateien bereits im Permanentspeicher befinden.

Wenn die Validierungsfehler ignoriert werden sollen, ist es wichtig, dies entsprechend zu dokumentieren, um die spätere Nachvollziehbarkeit zu gewährleisten. Dazu geht man im Technical Analyst auf den Reiter Validierung. Dort können die einzelnen Dateien und die JHOVE-Fehlermeldungen eingesehen werden, nachdem man ein SIP ausgewählt hat. Mit einem Klick auf den Button MD Error öffnet sich ein neues Menü.

Dort kann der Grund für das Ignorieren des Fehlers und eine optionale Notiz hinzugefügt werden. Bei Validierungsfehlern sollte als Grund "Problem can be solved later" ausgewählt werden, da sich alle Validierungsfehler auch nach dem Verschieben in den Permanentspeicher von Rosetta noch beheben lassen. Die optionale Notiz sollte die Fehlermeldung enthalten sowie einen Reparaturvorschlag, sofern ein solcher bekannt ist. Das hbz hat dafür zwei generische Textbausteine erarbeitet, die individuell an Ihre Institution und die jeweilige Fehlermeldung angepasst werden können (siehe unten).

Wird zusätzlich "Remember my decision..." angehakt, erzeugt Rosetta automatisch eine Ausnahmeregel, die daraufhin unter Submissions → Rules zu finden ist.

Nach dem Speichern der Notiz wird der entsprechenden Datei der Status Ignored zugewiesen und sie kann über Move to Next Step in den Bereich Assessor verschoben werden. Dort kann das SIP final überprüft und in den Permanentspeicher von Rosetta verschoben werden. Ein Klick auf Recheck ist nicht nötig. Bei einem Recheck wird erneut auf Validität geprüft und der Status Ignored wieder entfernt, sodass er erneut zugewiesen werden muss.  

Die hinzugefügte Notiz kann später in den Metadaten der entsprechenden Datei in den Events eingesehen werden.

Um dorthin zu gelangen, geht man in der Object Summary auf die File Ebene und öffnet das Metadaten-Tab. Darin klickt man auf DNX und dann auf die Unterkategorie events. Dort steht dann unter anderem ein Event mit der Beschreibung event Description=Manually ignore file md error mit Datum und Uhrzeit. Wenn man auf dieses Event klickt, wird neben der ursprünglichen Fehlermeldung auch die eingetragene Notiz unter event Outcome Detail1  angezeigt.

Da es sich dabei um ein festgeschriebenes Provenienzmetadatum einer durchgeführten Maßnahme in Rosetta handelt, kann die Notiz nach dem Speichern nicht mehr geändert werden.

Textbausteinvorlagen für manuelle Fehlerbehandlung

Die folgenden Textbausteine können genutzt werden, um Validierungsfehler, die ignoriert werden sollen, zu dokumentieren. Die kursiven Stellen müssen jeweils durch die passenden Einträge für den individuellen Fehler und Ihre Institution ersetzt werden.

Textbausteinvorlage für Fehler ohne Lösungsansatz

Textbausteinvorlage für Fehler mit bekannter Lösung

Automatisiertes Behandeln von Fehlern mit Ausnahmeregeln

Eine automatisierte Fehlerbehandlung (Ignorieren des Fehlers) kann durch das Definieren von Ausnahmeregeln in Rosetta durchgeführt werden. Diese Regeln behandeln einen Fehler automatisch beim Ingest, wenn der Fehler den in einer Regel definierten Parametern entspricht und dadurch die Regel aktiviert. Es können vier verschiedene Typen von Regeln angelegt werden, die jeweils einer Fehlerkategorie im Technical Analyst entsprechen.

• Format Identification Correction weist einer Datei, deren Dateiformat von DROID nicht eindeutig identifiziert werden kann, automatisch ein vorher eingestelltes Dateiformat zu.
• Metadata Extraction Error ignoriert JHOVE-Fehlermeldungen bei Dateien, deren technische Metadaten nicht zu 100% extrahiert werden konnten. Das ist der Fehlertyp, der im Validation-Tab des Technical Analysts am häufigsten vorkommt.
• Format Validation Error ignoriert JHOVE-Fehlermeldungen bei nicht validen Dateien. Meldungen in dieser Kategorie treten nur auf, wenn Metadata Validation und Metadata Extraction mit unterschiedlichen Tasks durchgeführt werden. Fehlermeldungen zu nicht validen Dateien werden durch die Rosetta-Konfiguration des hbz standardmäßig als Metadata Extraction Error angezeigt.
  
• Virus Check Error ignoriert erkannte Risiken bei der Virenprüfung.

Regeln werden unter Submissions → Rules angelegt. Dort gibt es ein Untermenü für jede der vier Arten von Regeln. In jeder Kategorie können beliebig viele Regeln angelegt und mit verschiedenen Parametern ausgestattet werden.

Mit einem Klick auf das Häckchen vorne können Regeln aktiviert und deaktiviert werden. Ist das Häkchen grün, ist die Regel aktiv. Sie wird dann bei einem neuen Ingest oder Rerun automatisch auf alle Dateien angewendet, die den festgelegten Kriterien entsprechen.

Festlegen von Parametern

Nachdem eine Regelkategorie ausgewählt worden ist, kann im darauffolgenden Menü eine spezifische Regel mit verschiedenen Parametern erstellt werden. Dazu kann je Kategorie von Parametern, z.B. Producer oder Extension, eine Liste von Items aus allen vorhandenen Möglichkeiten erstellt werden, z.B. mehrere Dateiformate oder der Name eines Producers. Weitere mögliche Parameter sind Dateigröße und Erstellungsdatum. Wichtige Parameter sind die Auswahl des betroffenen Validator-Plugins, z.B. PDF-hul-1.26, und das Einschränken nach bestimmten Fehlermeldungen und Fehler-IDs. Dies ermöglicht es, eine Regel für einen ganz bestimmten Fehler oder eine Gruppe von ähnlichen Fehlern anzulegen.

Außerdem wird ein Operator gewählt, der bestimmt, wie diese Trefferliste behandelt wird und dementsprechend wann die Regel angewendet wird.

Folgende Operatoren sind dabei möglich:

• Any: Die Regel wird angewendet, egal was die Liste enthält (sollte nicht verwendet werden).
• List Equals: Nur wenn alle gewählten Items einen Fehler verursachen, wird die Regel angewendet.
• List Not Equals: Die Regel wird angewendet, wenn ein Fehler an einem Item erkannt wird, das nicht in der Liste steht.
• List Contains: Die Regel wird angewendet, wenn mindestens ein Item der Liste von einem Fehler betroffen ist.

Nachdem alle Input-Parameter festgelegt worden sind, werden im unteren Abschnitt die Output-Parameter definiert, welche sich je nach Regelkategorie unterscheiden. Diese bestimmen welches Ergebnis nach dem Anwenden der Regel entstehen soll, zum Beispiel, dass Fehler mit einer bestimmten Meldung ignoriert werden oder dass nicht klar identifizierten Dateiformaten ein bestimmtes Dateiformat zugewiesen wird. 

Mit einem Klick auf Save wird die Regel gespeichert. Daraufhin gelangt man in das vorherige Menü, die Übersichtsliste aller Regeln, zurück.

Output Parameters

Textbausteinvorlage für Regeln