Dp4lib Abschlussworkshop

Am 21. Mai fand in Frankfurt der vorläufige Abschlussworkshop des DP4lib Projektes statt. Warum ‘vorläufig’ erzähle ich später.

Zunächst gab es durch Herrn Schmitt von der DNB einen allgemeinen Rundgang durch die Genese von DP4lib als Nachfolgeprojekt von kopal, dem ‘kooperativen Aufbau eines Langzeitarchivs digitaler Informationen’. Ziel von DP4lib war die ‘Organisatorische und technische Weiterentwicklung der kopal-Lösung zu einem integrierten Dienst zur kommissarischen Langzeitarchivierung digitaler Daten’. Der Titel ist noch ein kleines bißchen sperriger als unserer finde ich.

Ich habe vergessen zu fragen, was mit kommisarisch in diesem Zusammenhang gemeint ist, verwende es aber nicht in der Bedeutung ‘vorläufig’ sondern eher ‘in Vertretung’. DP4lib ist nämlich ein one-to-one Archiv. Das heißt, ein Auftraggeber (im Folgenden Dienstnehmer) liefert seine Daten bei DP4lib ab und nur er bekommt sie auch wieder heraus. Soll das bei unseren Forschungsdaten ebenso sein? Ich bin bisher davon ausgegangen, dass wir eher den öffentlichen Zugang zu den archivierten Daten verfolgen, oder bringe ich da unzulässigerweise den Open Access Gedanken mit rein, der gar nicht unbedingt gefordert ist?

Weiterhin ist mir klar geworden, das DIAS zwar eine weit entwickelte und ausgebuffte Komponente eines Langzeitarchivs ist, aber eben nur eine Komponente. IBM hat aller Wahrscheinlichkeit nach nicht vor, DIAS zu vermarkten und so wird auch DIAS 2.0 eine Einzelentwicklung bleiben. DIAS selbst stellt ein OAIS konformes Speichersystem zur Verfügung, kann aber weitestgehend als Black-Box mit wohldefinierten Schnittstellen betrachtet werden. Ähnliche Funktionalität könnte man auch mit freier Software abbilden, siehe zum Beispiel Fedora.

Innerhalb des DP4lib Projekts ist ein ‘Qualitätsbezeichner’ für die abgelieferten Daten eingeführt worden, der sogenannte Ingest Level. Die Werte reichen, typisch technisch, von 0 bis 4, wobei Level 0 eine reine bitstream preservation (Dateiintegrität) darstellt und Level 4 alle 5 [sic!] Kriterien (Dateiintegrität, Identifikation, Beschränkungsfreiheit, Extraktion formatspezifischer technischer Metadaten und Format-Validität) erfüllt.  Das ist eine ziemlich praktische Sache, weil der Dienstnehmer sich zum Beispiel mit Ingest Level 1 zufrieden geben kann und dann erheblich weniger Aufwand bei der Vorbereitung seiner Daten zum SIP hat.

Und hier wären wir auch schon bei meinem Lieblingsthema, der SIP -erstellung. Dazu liefert die DP4lib nach fehlgeschlagenem Ingest ein Fehlerprotokoll an den Ersteller des SIP zurück.  Im Moment werden noch die Fehlermeldungen von FITS weitergereicht, was sich dann so liest, dass es in der Datei archivier_mich.pdf am Offset 346-82765-0:964 eine Java.lang.foundationClass.fontFace.outerCurveSpline exception gehagelt hat. Aha. Soso. Und was mach ich jetzt?

Schön wäre hier ein Fehlerbericht, der gleich eine Lösung anbietet, oder aber zumindest die Schwere des Fehlers einordnen hilft. So, dass der Nutzer entscheiden kann, ob er nachbessert oder sich mit einem niedrigeren Ingest Level zufrieden gibt. Nicht für jeden ist der Schriftschnitt gleich wichtig.

Eine mögliche Workflowkomponente für EWIG könnte also zum Beispiel ein Werkeug sein, das die Fehlermeldung interpretiert und zunächst dem Nutzer einen Schweregradsbalken einblendet analog zu diesen rot-grün Verläufen bei der Bewertung der Passwortstärke. Außerdem sollten konkrete Lösungen angeboten werden.

Ein weiterer wichtiger Punkt der Veranstaltung ist das vorgestellte Kostenmodell. DP4Lib hat sich zunächst auf die Schätzung der Kosten festgelegt. Das ist natürlich etwas ungenau, aber dafür leist- und bezahlbar. Eine genauere Ermittlung der Kosten über Monitoring Werkzeuge und extra Mitarbeiter erschien für die Testphase zu aufwendig und zu teuer. Auch die Ermittlung von Kosten erzeugt Kosten — und nicht zu knapp.

Und wenn sich wer wundert, warum der Autor denn nicht endlich mit der Summe rausrückt, der hat ja recht, aber das liegt das an der Summe selbst, die aber auch auf dem Workshop kontrovers diskutiert wurde. DP4lib nimmt für 100 TB Daten eine Summe von 622.053,- Euro pro Jahr an, die sich nahezu gedrittelt auf Ingest, Curation und Access verteilen. Unklar blieb, ob denn nicht die Menge der zu kuratierenden Daten im Laufe der Zeit zunimmt und daher auch dieser Posten anwachsen müsste. Auch machen die veranschlagten Personalkosten für 5 Mitarbeiter über ein Drittel der Gesammtsumme aus. Im weiteren Verlauf des Projekts und hier schließt sich der Kreis wird auch im Laufenden Betrieb eine exaktere Kostenermittlung stattfinden. Die Deutsche Nationalbibliothek wird das Projekt nämlich als operativen Dienst DP4lib-…, na? Nein, nicht reloaded, sonder engaged, also DP4lib-engaged als eigenes Projekt weiterführen.

Fast alle besprochenen Punkte finden sich auch in dem Handlungsleitfaden für Dienstnehmer und Dienstleister wieder, der darüber hinaus noch sehr interessante Fragebögen für die Anforderungsermittlung, sowie Hinweise zur Vertragsgestaltung zwischen Archiv und den Datenlieferanten enthält.

 

 

This entry was posted in Langzeitarchivierung, Produkte und Tools, Veranstaltungen. Bookmark the permalink.

Comments are closed.