Langzeitarchivierung von Digitalisaten Projektdokumentation des Masterkurses Informationswissenschaften an der FH Potsdam WS 2015/16 Projektleitung: Prof. Dr. Rolf Däßler Ulf Preuß M. A. AP1: AP2: AP3: Christian Kuhne Christina Loose Jale Dayan Jan Telle Björn Steffenhagen Marcel Kluge Eric Bauermeister Falco Hübner Harald Arends Potsdam, im Februar 2016
159
Embed
Langzeitarchivierung von Digitalisaten - opus4.kobv.de · um diese auf Plattformen wie die Deutsche Digitale Bibliothek (DDB), die Europeana ... Historische Archiv der Stadt Köln,
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Langzeitarchivierung von Digitalisaten Projektdokumentation des Masterkurses Informationswissenschaften an der FH Potsdam WS 2015/16
Projektleitung:
Prof. Dr. Rolf Däßler
Ulf Preuß M. A.
AP1: AP2: AP3:
Christian Kuhne Christina Loose Jale Dayan
Jan Telle Björn Steffenhagen Marcel Kluge
Eric Bauermeister Falco Hübner
Harald Arends
Potsdam, im Februar 2016
1
Inhalt
1. Einleitung (AP 2).................................................................................................. 4
2. Langzeitarchivierungslösungen (AP 3) .............................................................. 10
technische Umsetzung und Begleitarbeiten zur Auswahl, (Re-)Kontextualisierung und Nutzbarmachung der Unterlagen. Ein Vortrag von Juliane Schütterle und Andreas Petter. In: Bibliotheksdienst 47 (2013) 7, S. 553-554 [Editorische Notiz].
3 Vgl. Jehn, Mathias; Schrimpf, Sabine: Kap. 2.2 LZA-Aktivitäten in Deutschland aus dem Blickwinkel
von nestor. In: Neuroth, Heike; Huth, Karsten; Oßwald, Achim et al. (Hrsg.): nestor Handbuch. Eine kleine Enzyklopädie der digitalen Langzeitarchivierung, Version 2.3, Boizenburg 2010, S. 1. URL: http://nestor.sub.uni-goettingen.de/handbuch/artikel/nestor_handbuch_artikel_391.pdf [14.02.2016].
Digitale Archiv NRW in der Praxis. Eine Softwarelösung zur digitalen Langzeitarchivierung, Hamburg 2013 (=Kölner Beiträge zu einer geisteswissenschaftlichen Fachinformatik, Bd. 5), S. 20-21.
Die Langzeiterhaltung des digitalen Erbes erfordert deshalb die Durchführung von
Maßnahmen im gesamten Lebenszyklus der digitalen Information, von der Erstellung
bis zum Zugang. Verlässliche Archivierungssysteme und –verfahren sichern
langfristig die Authentizität und Stabilität digitaler Objekte.5
Es gibt bereits einige Strategien, Konzepte und Standards zur digitalen
Langzeitarchivierung. Das Open Archival Information System (OAIS)-Referenzmodell
bietet als ISO 14721:2012 einen allgemeinen, konzeptuellen Rahmen für die
funktionale Organisation des digitalen Langzeitarchivs und den
Informationstransport.6 Die Anforderungen an eine vertrauenswürdige digitale
Langzeitarchivierung definiert die DIN-Norm 31644.7
Doch für viele kommunale Einrichtungen – ob für Archive, Bibliotheken oder Museen
– gibt es oft keine Lösung, ihre Digitalisate OAIS-konform zu archivieren. Die
Hochschularchive sind in einer ähnlichen Situation.8 Eigene Entwicklungen sind
aufgrund des hohen Ressourcenaufwandes an Personal und Finanzen nicht
machbar und wären auch kontraproduktiv. In der heterogenen Kulturlandschaft gilt es
daher, Probleme gemeinsam zu lösen und Synergieeffekte zu schaffen.
In einigen, finanziell gut aufgestellten Bundesländern ergriffen bereits die
Landesarchive die Initiative und entwickelten gemeinschaftlich nutzbare
Archivierungslösungen. So entwickelte das Landesarchiv Nordrhein-Westfalen das
Digitale Archiv NRW (DA NRW) für die Kultur- und Gedächtnisinstitutionen
Nordrhein-Westfalens9 oder das Landesarchiv Baden-Württemberg das Digitale
Magazin (DIMAG), das auch von den norddeutschen Bundesländern derzeit als
5 Vgl. Buchegger, Wolfgang: Digitale Archivierung. Methoden und Strategien der
Langzeitarchivierung in digitalen Bibliotheken, Saarbrücken 2012, S. 9. 6 Vgl. Thaller, Manfred: Probleme der digitalen Langzeitarchivierung und eine mögliche Antwort.
Zum Digitalen Archiv NRW. In: Landschaftsverband Rheinland – LVR-Archivberatungs- und Fortbildungszentrum (Hrsg.): Digital und analog. Die beiden Archivwelten. 46. Rheinischer Archivtag 21.-22. Juni 2012 in Ratingen. Beiträge, Bonn 2013 (=Archivhefte 43), S. 17-18.
Kriterienkatalog vertrauenswürdige digitale Langzeitarchive, Version 2, Frankfurt am Main 2008 (=nestor-materialien 8). URL: http://files.dnb.de/nestor/materialien/nestor_mat_08.pdf [14.02.2016].
8 Siehe Nippert, Klaus: Sachstand und Perspektiven der Digitalen Langzeitarchivierung an
deutschen Hochschularchiven. In: Blecher, Jens; Happ, Sabine (Hrsg.): Archive im Verbund. Netzwerke und Kooperationen, Frühjahrtagung der Fachgruppe 8 im Verband deutscher Archivarinnen und Archive e. V. vom 13.-15. März 2013 an der Karls-Universität Prag, Leipzig 2014 (=Wissenschaftsarchive 2013 Bd. 3), S. 80-88.
9 Siehe Thaller, Manfred (Hrsg.): Das Digitale Archiv NRW in der Praxis. Eine Softwarelösung zur
digitalen Langzeitarchivierung, Hamburg 2013 (=Kölner Beiträge zu einer geisteswissenschaftlichen Fachinformatik Bd. 5).
Verbundlösung Digitales Archiv Nord (DAN) nachgenutzt wird. Des Weiteren bilden
sich Nutzergruppen, die ein gleiches System zur digitalen Langzeitarchivierung
nutzen, wie z. B. das Bundesarchiv, das Landesarchiv Nordrhein-Westfalen, das
Historische Archiv der Stadt Köln, das Stadtarchiv Stuttgart, das LWL-Archivamt und
die Landesarchivverwaltung Rheinland-Pfalz, welche alle das System DiPS (Digital
Preservation Solution) der Firmen HP und SER einsetzen. Die Langzeitarchivlösung
DiPS soll interessierten Einrichtungen, die keine Lösung und Infrastruktur aufbauen
wollen oder können, über den Dachverband Kommunaler IT-Dienstleister (KDN)
angeboten werden.10
Im Land Berlin kümmert sich die Servicestelle Digitalisierung (digiS) am Konrad-
Zuse-Institut für Informationstechnik in Berlin als zentrale Beratungs-,
Unterstützungs- und Koordinierungsinstitution landesweit um vom Senat Berlin
geförderte Digitalisierungsprojekte und deren Langzeitverfügbarkeit mit dem Aufbau
einer technischen Infrastruktur unter Einsatz der Open-Source-Archivierungssoftware
Archivematica.11
In Brandenburg gibt es aktuell keine Lösung für kommunale Einrichtungen – ob für
Archive, Bibliotheken oder Museen – ihre Digitalisate langfristig zu archivieren. Der
Arbeitskreis Brandenburg-digital beschäftigt sich seit 2007 lediglich mit der
Digitalisierung von Kulturgut im Land Brandenburg.12 Aus ihm ging durch ein Projekt
zur digitalen Präsentation von Kulturgut im Land Brandenburg im Jahr 2012 als
Geschäftsstelle die Koordinierungsstelle Brandenburg-digital (KBD) hervor, welche
Digitalisierungsprojekte – vor allem kleinerer Kultureinrichtungen mit wenig zur
Verfügung stehenden Mitteln – fördert und sich zum Ziel setzt, die Digitalisate der
Öffentlichkeit über nationale und internationale Präsentationsplattformen zugänglich
10
Vgl. Nabrings, Arie: Sektion 4. Digitale Langzeitarchivierung. In: LVR-Archivberatungs- und Fortbildungszentrum des Landschaftsverbands Rheinland: Kooperation ohne Konkurrenz. Perspektiven archivischer Kooperationsmodelle, 48. Rheinischer Archivtag vom 26.-27. Juni 2014 in Kleve, Bonn 2015 (=Archivhefte 45), S.114-119, hier S. 117.
11 Siehe hierzu Müller, Anja: Kulturgut digital. Die Servicestelle Digitalisierung des Landes Berlin am
Zuse-Institut Berlin (ZIB). In: Verband deutscher Archivarinnen und Archivare e. V. (Hrsg.): Archive ohne Grenzen. Erschließung und Zugang im europäischen und internationalen Kontext, 83. Deutscher Archivtag in Saarbrücken, Fulda 2014 (=Tagungsdokumentation zum Deutschen Archivtag Bd. 18), S. 149-156.
12 Vgl. Koordinierungsstelle Brandenburg-digital: Die Digitale Präsentation von Kulturgut im Land
zu machen.13 Denn dem Strategiepapier des Ministeriums für Wissenschaft,
Forschung und Kultur des Landes Brandenburg von 2009 zur Digitalisierung von
Kulturgut im Land Brandenburg ist zu entnehmen, dass vor allem große Archive,
Bibliotheken oder Museen mit entsprechendem Budget Digitalisierungsprojekte
planen und durchführen.14 Kleinere Kultureinrichtungen stellen nur vereinzelt
Digitalisate zur Verfügung.
Des Weiteren strebt die Koordinierungsstelle Brandenburg-digital einen regen
Informationsaustausch mit nationalen Kooperationspartnern, wie z. B. mit der digiS,15
an.16 Dabei soll es jedoch nicht bleiben. Im Rahmen einer strategischen
Partnerschaft mit der digiS Berlin plant die Koordinierungsstelle Brandenburg-digital
den Aufbau einer Langzeitarchivierungslösung für die Digitalisierungsprojekte
Brandenburger Einrichtungen. Das digitale Kulturgut soll zur Langzeitspeicherung
und –verfügbarkeit an die Lösung der digiS überführt werden.
Ziel des Projektes „Langzeitarchivierung von Digitalisaten“ im Masterstudiengang
Informationswissenschaften im Wintersemester 2015/16 ist es daher, ein Konzept für
eine prototypische, OAIS-konforme Pre-Ingest-Lösung zur digitalen Archivierung von
Digitalisaten in Brandenburg – unter Anwendung der verfügbaren Archivematica-
Software sowie technischen und personellen Mitteln – mit folgender
Ausgangssituation zu entwickeln: Die verschiedenen Einrichtungen in Brandenburg
digitalisieren ihre Bestände und liefern diese zusammen als sogenanntes Transfer-
Informationspaket (TIP) an die Koordinierungsstelle Brandenburg-digital, welche –
gelegen an der Fachhochschule Potsdam – als Aggregator fungiert, die
Transferpakete für die Archivierung zur Abgabe an das Langzeitarchiv der digiS
Berlin aufbereitet und den Einrichtungen beratend zur Seite steht. Die Erarbeitung
des Konzeptes in Form von prototypischen Workflows erfolgt anhand des
Digitalisierungsprojektes „Populare Schriftzeugnisse des 16. bis 20. Jahrhunderts in
Brandenburg“, worunter nach Jan Peters „privates Schriftgut selbstzeugnisähnlichen
13
Vgl. Die Koordinierungsstelle Brandenburg-digital. URL: http://www.fh-potsdam.de/studieren/informationswissenschaften/fachbereich/brandenburg-digital/ [14.02.2016].
14 Vgl. Ministerium fur Wissenschaft, Forschung und Kultur des Landes Brandenburg. –
Strategiepapier zur Digitalisierung von Kulturgut im Land Brandenburg. – 2009, S. 16-31. URL: http://www.mwfk.brandenburg.de/media/lbm1.a.1491.de/strategiepapier.pdf [14.02.2016].
Beschreibendes Verzeichnis von Selbstzeugnissen und verwandten Quellen (17.-19. Jahrhundert), hrsg. von Klaus Neitmann, Potsdam 2004 (=Einzelveröffentlichung des Brandenburgischen Landeshauptarchivs).
Wiederauffindbarkeit der Digitalisate gewährleisten soll – als Grundlage für die
Entwicklung eines prototypischen Workflows zur Langzeitarchivierung ermittelt und
entwickelt wird. Eine weitere Basis zur Erstellung eines Konzeptes bildet das Kapitel
Archivematica, das die Archivierungslösung mit seinen Möglichkeiten und Grenzen
aufgezeigt und Testdurchläufe als Nachweis von Funktionalitäten und
Unzulänglichkeiten liefert. Im sechsten Kapitel werden auf die zusammengetragene
Infrastruktur, Systemarchitektur und Funktionalität von Archivematica hin
Empfehlungen zur technischen und personellen Umsetzung in der
Koordinierungsstelle Brandenburg-digital abgeleitet und entwickelt. Das schließt die
Hardwareanforderungen, den personellen und institutionellen Bedarf und eine
Aufwandseinschätzung zur Installation und Einrichtungen von Archivematica ein, das
Kapitel enthält aber auch ein Sicherheitskonzept, wie Daten sicher ausgetauscht
werden können sowie erarbeitete Anforderungen an eine Web-Anwendung und
Vorschläge für Übernahme-Tools, die die definierten Anforderungen für den Use
Case erfüllen.
Das Langzeitarchivierungskonzept entwickelt sich auf Grundlage der technischen,
systemischen, organisatorischen und infrastrukturellen Möglichkeiten. Die
Darstellung der Funktionsarchitektur, des Aufbaus der Informationspakete und des
Ablaufs des Pre-Ingest und Ingest in der digiS Berlin bilden die Basis für die
Konzeption einer kompatiblen Schnittstelle zur Archivlösung in Berlin.
Aufbauend auf dem Metadatenkonzept, den beispielhaften Digitalisaten mit dem
Objektmodell, den Testdurchläufen in Archivematica und auf ermittelter,
unterstützender Tools erfolgt die Erstellung von Workflows, wie die Übernahme,
Verarbeitung, Überführung nach Berlin, Langzeitarchivierung und Rückgabe der
Informationspakete beispielhaft gestaltet werden kann. In Korrelation mit dem
Konzept werden strategische Empfehlungen für die Langzeitarchivierung im Land
Brandenburg erarbeitet und letztendlich eine Übernahmevereinbarung entworfen,
welche als Policy die grundlegenden Vereinbarungen und Anforderungen an den
Prozessablauf für die Sicherstellung einer OAIS-konformen und vertrauenswürdigen
Langzeitarchivierung von digitalen Objekten zwischen den Einrichtungen, der
Koordinierungsstelle Brandenburg-digital und der digiS definiert und die entwickelte
Pre-Ingest-Lösung nachhaltig festigt.
10
2. Langzeitarchivierungslösungen (AP 3)
Mit der Entwicklung von Langzeitarchivierungslösungen zum Erhalt digitaler Daten
des kulturellen Erbes steht die Informationsgesellschaft vor eine der größten
Herausforderungen des angebrochenen Jahrhunderts, ist eine ordentliche und
dauerhafte Bereitstellung von in digitaler Form vorliegenden Informationen doch nur
dann gewährleistet, wenn eine Vielzahl umfangreicher und verbindlicher Regelungen
zur Archivierung erarbeitet und eingehalten wird.
So gilt es u.a. nicht nur unklare Rechtslagen bei der Speicherung von Daten zu
klären oder Geschäfts- und Betriebsmodelle zu finden, bei denen die Finanzierung
von Langzeitarchivierungsprojekten längerfristig sichergestellt wird, sondern auch
Kompetenznetzwerke zur Aus- und Weiterbildung von geschulten Personal, welches
mit der Langzeitarchivierung betraut ist, zu gründen oder bei veraltenden
Dateiformaten Lösungswege der Migration bzw. Emulation anzubieten.
Bei dieser Bandbreite an anzugehenden Themen ist es also nicht verwunderlich,
dass die Entwicklung digitaler Langzeitarchivierungslösungen und ihrer Werkzeuge
nicht von einer Institution vorangetrieben, sondern als eine kooperative Arbeit
wahrgenommen wird, zumal eine solche Arbeitsweise nicht allein den Nutzen der
Aufgabenteilung mit sich bringt: Mehrfachinvestitionen werden vermieden,
Schulungs- und Einarbeitungskosten durch Systemvereinheitlichungen reduziert und
Synergien generiert.20
Da die Bundesrepublik Deutschland ein föderaler Staat ist, verläuft die kooperative
Zusammenarbeit ihrer Kultureinrichtungen zumeist entlang der föderalen
Ländergrenzen, sodass sich in deren Rahmen auch unterschiedliche Projekte bzw.
Verbünde zur digitalen Langzeitarchivierung entwickelt haben.
Es liegt nahe, fortan auf die Erfahrung jener Verbünde zurückzugreifen, handelt es
sich doch beim vorliegenden Projekt zur Langzeitarchivierung von digitalen
Informationsobjekten des Landes Brandenburg ebenfalls um eine kooperative
Bestandserhaltungsarbeit der Kultureinrichtungen der Region Brandenburg. Im
20
Vgl. Fischer, Ulrich: Gemeinsame Lösungen für ein gemeinsames Problem. Verbundlösungen für die elektronische Langzeitarchivierung in Deutschland. In: Archivpflege in Westfalen-Lippe, 42 (2014) 80, S. 20-25, hier S. 20. URL: http://www.lwl.org/waa-download/archivpflege/heft80/Heft_80_2014.pdf [14.02.2016].
ansonsten auf zum Lösungsverbund zugehörigen Archivknoten (Servern). Auf
diesen befinden sich somit (nicht anders als bei der geplanten Brandenburger
Realisierung) Daten unterschiedlicher Einrichtungen und unterschiedlicher Sparten.23
2.2 Digitales Archiv Nord (DAN) und Digitales Magazin (DIMAG)
Sowohl beim Digitalen Archiv Nord, bestehend aus den Staatsarchiven Hamburg und
Bremen sowie den Landesarchiven Mecklenburg-Vorpommern, Niedersachsen und
Schleswig-Holstein, als auch beim ursprünglich in Baden-Württemberg entstandenen
Projekt des Digitalen Magazins handelt es sich um rein archivische, im Aufbau
befindliche Kooperationsverbünde, welche im Sinne des nestor-
Kompetenznetzwerkes ihre personellen und finanziellen Ressourcen bündeln, um die
Langzeitarchivierung und Langzeitverfügbarkeit ihrer digitalen Ressourcen
gemeinschaftlich sicherzustellen.
Aufgrund der engen Personallage verzichtete das DAN von Anfang an auf die
Neuentwicklung eines eigenen Archivierungssystems und konzentrierte sich
stattdessen auf die Findung einer bereits existierenden und für seine Zwecke
geeigneten Anwendung. So prüften die norddeutschen Archivverwaltungen diverse
Softwareangebote, glichen diese mit ihren eigenen Anforderungen zur digitalen
Langzeitarchivierung ihrer elektronischen Akten, Handelsregister, Geobasis- und
statistischen Daten ab und kamen schlussendlich überein, dass die DIMAG-Software
ihren Ansprüchen entspricht – eine Feststellung, die 2014 darin mündete, dass das
DAN dem DIMAG-Verbund beitrat.24
Dieser setzte sich bis dahin aus dem eigentlichen DIMAG-Softwareentwickler,
nämlich dem Landesarchiv Baden-Württemberg, und seinen Entwicklungspartnern,
dem Hessischen Landesarchiv und der Generaldirektion der Staatlichen Archive
Bayerns zusammen.
Der DAN verhalf dem DIMAG mithilfe zur Verfügung gestellter Finanzmittel zum
Aufbau einer zentralen Verfahrenspflegestelle und erhielt dafür die Nutzungsrechte
23
Vgl. Digitales Archiv Nordrhein-Westfalen: DA NRW Knotenstruktur, o. O. 2015. URL: https://www.danrw.de/fileadmin/_processed_/csm_DA_NRW_geplante_Knotenstruktur_cab017b7c2.png [14.02.2016].
24 Vgl. Schieber, Sigrid: Digitale Archivierung. Der DIMAG-Verbund wächst. In: Archivnachrichten aus
Hessen, 14 (2014) 2, S. 62. URL: https://landesarchiv.hessen.de/sites/landesarchiv.hessen.de/files/content-downloads/Archivnachrichten_14_2_Dezember_2014_Internet.pdf [14.02.2016].
4an der DIMAG-Software, einschließlich der noch in der Entwicklung befindlichen
Komponenten – eine Entwicklungspartnerschaft zum gegenseitigen Vorteil aller also,
zumal mit dem Landesarchiv Mecklenburg-Vorpommern eine Mitgliedsinstitution
hinzukam, die wie das Hessische Landesarchiv das Dokumenten-Management-
System Domea® benutzt und somit bei der Langzeitarchivierung von digitalen Akten
vor den gleichen Herausforderungen steht, wie ihr hessisches Pendant.
Grundsätzlich ist das DIMAG auch zukünftig weiteren Partnerschaften gegenüber
aufgeschlossen – es unterscheidet dabei zwischen Entwicklungs-, Support-,
Magazin- und Dienstleisterpartnerschaft –, Voraussetzung ist jedoch u.a. stets, dass
sämtliche Partner bei der Langzeitarchivierung auf dasselbe Repräsentationsmodell
und auf eine gemeinsame Terminologie zurückgreifen,25 ganz abgesehen davon,
dass Entwicklungspartner wie die Generaldirektion der Staatlichen Archive Bayerns
für den Support der ihnen unterstellten Archive zuständig sind, wenn sie die DIMAG-
Software an diese weiterreichen.
Diese Punkte sind denn auch ausschlaggebend dafür, dass das hier vorgestellte
Projekt nicht am Digitalen Magazin oder an ähnlich gearteten Konzepten wie dem
DAN teilnehmen könnte. Zum einen ist es schwer abzuschätzen, welche personellen
und finanziellen Ressourcen die Brandenburger Kultureinrichtungen für einen
solchen Kooperationsverbund zur Weiterentwicklung einer
Langzeitarchivierungssoftware zur Verfügung stellen könnten und zum anderen hat
das hier vorgestellte Projekt den Anspruch eines spartenübergreifenden Konzeptes,
da es sich hierbei um eine Langzeitarchivierungsmöglichkeit für Archive, Bibliotheken
und Museen handelt, während DAN und DIMAG in jeder Hinsicht „lediglich“
archivübergreifende Kooperationen darstellen.
Zwar ließen sich mit dem von ihnen verwendeten XML-Standard Encoded Archival
Description auch Bibliotheks- und Museumsdaten erschließen, in Anbetracht der
Vielzahl der Brandenburger Kultureinrichtungen ist jedoch auch von einer Mehrzahl
anderer Metadatenstandards auszugehen. Diese sollen bei der Archivierung
durchaus respektiert bzw. berücksichtigt werden.
25
Vgl. Keitel, Christian: DIMAG-Kooperationen. Konzept und aktueller Sachstand. Vortrag auf dem nestor-Praktikertag am 17.06.2013 in Hamburg, Hamburg 2013, S. 7f. URL: http://files.dnb.de/nestor/veranstaltungen/Praktikertag2013/2013-06-dimag-keitel.pdf [14.02.2016].
Ein weiteres Projekt zur Langzeitarchivierung digitaler Kulturdaten wird derzeit
gemeinsam durch die Servicestelle Digitalisierung Berlin und dem Kooperativen
Bibliotheksverbund Berlin-Brandenburg realisiert. Es handelt sich dabei um eine
Verbundlösung, bei der der KOBV seinen Mitgliedsbibliotheken zukünftig
Speicherplatz auf dem Bandarchiv des Konrad-Zuse-Zentrums zur Verfügung stellen
möchte.26
Dafür und zur Abschätzung unterschiedlicher Bedarfe seiner Mitgliedsinstitutionen
hatte der KOBV von Mai bis Juni 2015 eine Online-Umfrage ausgeführt, in welcher er
u.a. Angaben über vorhandene Medientypen, Lieferformate und Lieferwege,
Datenmengen, Ablieferungsfrequenzen und Präsentationssoftware ermitteln konnte.
Tatsächlich befindet sich das geplante Langzeitarchiv derzeit noch in den Anfängen
der Aufbauphase, seit Dezember 2015 werden, gemeinsam mit den
Partnerbibliotheken, verschiedene Workflows zur Datenübernahme entwickelt.
Grundsätzlich spräche zukünftig nichts dagegen, die in Projekten des KOBV und der
digiS entwickelten Technologien und Techniken strukturell für das hiesige Projekt zu
übernehmen bzw. anzupassen27 - selbstverständlich vorausgesetzt, dass dies die
Entwicklungsarbeit sinnvoll ergänzt bzw. vorantreibt.
26
Vgl. Kooperativer Bibliotheksverbund Berlin-Brandenburg: Service „Langzeitarchivierung“, Berlin 2015. URL: https://www.kobv.de/services/archivierung/lza/ [14.02.2016].
27 Vgl. Arbeitskreis Brandenburg.digital; Zuse Institut für Informationstechnik; Servicestelle
Digitalisierung Berlin: Zusammenfassung des Treffens von Vertretern des AK Brandenburg.digital mit Kolleginnen und Kollegen des Zuse-Instituts für Informationstechnik (ZIB) und der Servicestelle Digitalisierung, Berlin, 2016. S. 2 [Protokoll].
Bei Archivematica handelt es sich um ein Archivierungssystem, das auf Basis einer
Vielzahl von Mikroprozessen (Microservices) funktioniert. Das heißt, es handelt sich
um kein einheitliches Programm, sondern um einen Zusammenschluss einer Vielzahl
verschiedener Programme. Alle verwendeten Mikroprozesse sind kostenlos online
verfügbar und können problemlos ausgetauscht oder auch einzeln deaktiviert
werden, wodurch das System gut an verschiedene praktische Anwendungsfälle
angepasst werden kann. Die Tools werden von Archivematica mithilfe von Scripts auf
Basis von Python integriert.31
Abbildung 6: Mikroprozesse in Archivematica32
Eine Liste der von der Archivematica-Version 1.4.1 genutzten Software lässt sich in
Kapitel 4.3 nachvollziehen.
31
Vgl. Van Garderen, Peter: Archivematica. Using micro-services and open-source software to deliver a comprehensive digital curation solution. In: iPRES 2010. Proceedings of th 7th International Conference on Preservation of Digital Objects, Wien 2010, S. 145-150, hier S. 146. URL: https://fedora.phaidra.univie.ac.at/fedora/get/o:245912/bdef:Content/get [14.02.2016].
Arbeitsschritte zum Ingest werden durch die im System integrierten Mikroprozesse
ausgeführt. An bestimmten Stellen muss der Nutzer mithilfe eines Drop-Down-Menüs
selbst Entscheidungen (Decisions) zum Fortgang des Ingest treffen.
4.1 Umsetzung nach dem OAIS-Referenzmodell (AP 1)
Eine optimal konfigurierte Archivematica-Installation bildet das OAIS-Referenzmodell
weitestgehend ab. Sämtliche Funktionen eines Online-Archivs werden mithilfe einer
Vielzahl von Mikroprozessen durchgeführt. Mithilfe des Dashboards kann auf fast alle
Funktionsbereiche des Archivs analog zum OAIS-Modell zugegriffen werden.
Abbildung 8: OAIS-Funktionsmodell36
Es existieren in Archivematica Funktionsbereiche für Ingest, Archival Storage,
Preservation Planning, Access und Administration. Zusätzlich gibt es noch die
Funktionseinheit Transfer, die im OAIS-Modell nicht vorkommt und die den
vorarchivischen Bereich abdecken soll. Mithilfe dieser Einheit ist es möglich, die vom
Produzenten eingereichten Informationspakete in OAIS-konforme SIP‘s
36
Vgl. The Consultative Committee for Space Data Systems: Reference Model for an Open Archival Information System (OAIS), Washington 2012 [Magenta Book], S. 44. URL: http://public.ccsds.org/publications/archive/650x0m2.pdf [14.02.2016].
41 Vgl. VdW-Arbeitskreis “Elektronische Archivierung“: Reference Model for an Open Archival
Information System (OAIS), o. O. 2010, S. 14. URL: http://www.wirtschaftsarchive.de/arbeitskreise/fachliche-arbeitskreise/elektronische-archivierung/OAIS_Handreichung_2011_02_04.pdf [14.02.2016].
Approve SIP creation Start des Ingest aus dem backlog
Verify Transfer compliance Überprüfung der structmap der SIP-
METS-Datei
Verify SIP compliance Überprüfung auf vorgegebene
Ordnerstruktur
Rename SIP directory with SIP UUID Ändert den Namen des SIP’s auf
höchster Verzeichnisebene, indem eine
UUID hinzugefügt wird
Include default SIP processingMCP.xml Ändert die processingMCP.xml aus dem
Transfer für die Microservices des
Ingests um
Remove chache files Entfernt thumbs.db Dateien
Clean up names Entfernung von Umlauten und
Sonderzeichen, die nicht in Unicode
verfügbar sind. Die Originalnamen
werden als PREMIS-Event hinterlegt
Normalize Migration der Dateiformate
Process manually normalized files Manuelle Migration von Dateiformaten
Add final metadata Erinnerung zur Hinzufügung von
Metadaten
Transcribe SIP contents Durchlauf einer OCR-Software zur
Texterkennung
Process submission documentation Erkennung von Objekten unter
/submissiondocumentation,
Verschiebung der Objekte unter /objects,
dabei Vergabe von UUID’s,
Formaterkennung, Formatvalidierung,
Metadatenextraktion
Process metadata directory Vergabe von UUID’s,
Formatidentifikation,
Formatcharakterisierung, Virenprüfung,
Vergabe von Hashwerten
29
Verify checksums Überprüfung von Hashwerten
Generate AIP METS Erzeugt eine neue METS-Datei für das
AIP
Prepare DIP Erstellung eines DIP’s, mit
Nutzungskopien, Thumbnails, und einer
Kopie der METS-Datei
Prepare AIP Erstellung einer AIP in BagIt-Struktur
Upload DIP Upload des DIP in ein selbstgewähltes
Verzeichnis/Repository. Hier ist ebenfalls
die Speicherung und Abbruch der DIP-
Erzeugung möglich
Upload DIP to AtoM Upload nach AtoM
Upload DIP to CONTENTdm Upload nach CONTENTdm
Upload DIP to Archivists‘ Toolkit Upload nach Archivist’s Toolkit
Store DIP Speicherung des DIP in einem
vordefinierten Verzeichnis
Store AIP Speicherung des AIP im Standard- oder
anderem Verzeichnis
Tabelle 2: Microservices im Ingest von Archivematica
30
Die Microservices in Archivematica innerhalb des Transfer/Ingest bilden die
Funktionseinheit des OAIS-Referenzmodells weitestgehend ab. Die einzelnen
Funktionen:48
Übergabe entgegennehmen
Qualitätssicherung
AIP erzeugen
Erschließungsinformationen erzeugen
Aktualisierung koordinieren
sind in Archivematica prinzipiell enthalten, weshalb die Lösung OAIS-konform ist.
Einzig die Funktion Erschließungsinformationen erzeugen bedarf einer zusätzlichen
Archivdatenbank, in der die extrahierten Metadaten implementiert werden. Auch in
Hinblick auf die Trennung von Transfer und Ingest im vorliegenden Use Case
erscheint die Verbundlösung OAIS-konform, da durch den Workflow im Ingest an der
digiS jede Funktion bedient wird.
4.3 Interne Tools (AP 2)
Archivematica in der Version 1.4.1 enthält standardmäßig verschiedene Tools zur
Aufgabenbewältigung der Microservices. Zur Übersicht diese Tools zusammen mit
ihrer jeweiligen Aufgabe im System vorstellt werden.49 In dieser Übersicht enthalten
sind auch noch zu installierende Software, wie ElasticSearch oder AtoM, die jedoch
für den Einsatz in Archivematica vorbereitet sind.
Tool Version Beschreibung/Aufgabe
BagIt 4.9.0 Standard, um digitale Objekte und Metadaten zu
Paketen zusammenzufassen
bulk_extractor 1.4.4 Scan von Dateien, Ordnerstrukturen und
Datenträgern sowie Extraktion von Metadaten
Clam AV (anti-
virus)
0.98.6 Anti-Viren-Software für UNIX
ElasticSearch 1.3 Indexierung und Suche
48
Vgl. nestor-Arbeitsgruppe OAIS-Übersetzung/Terminologie: Referenzmodell für ein Offenes Archiv-Informations-System. Deutsche Übersetzung 2.0, hrsg. von nestor – Kompetenznetzwerk Langzeitarchivierung, Frankfurt am Main 2013 (=nestor-materialien 16), S. 37-39, URL: http://files.dnb.de/nestor/materialien/nestor_mat_16-2.pdf [14.02.2016].
52 Vgl. Hooten, T.; Jordan, P.; Van Garderen, Peter et al.: The Archivematica Project. Meeting Digital
Continuity’s Technical Challenges. In: Proceedings of The Memory of the World in the Digital Age. Digitization and Preservation. International conference on permanent access to digital documentary heritage, Vancouver 2012, S. 1354. URL: http://1seminariopreservacaopatrimoniodigital.dglab.gov.pt/wp-content/uploads/sites/19/2015/08/recurso_25.pdf [14.02.2016].
57 Vgl. Hooten, T.; Jordan, P.; Van Garderen, Peter et al.: The Archivematica Project. Meeting Digital
Continuity’s Technical Challenges. In: Proceedings of The Memory of the World in the Digital Age. Digitization and Preservation. International conference on permanent access to digital documentary heritage, Vancouver 2012, S. 1353. URL: http://1seminariopreservacaopatrimoniodigital.dglab.gov.pt/wp-content/uploads/sites/19/2015/08/recurso_25.pdf [14.02.2016].
(*) PNG and JPEG2000 are not normalized to a preservation format
(**) in development
(***) See Word processing formats, below
Daraus wird deutlich, dass die Umsetzung signifikanter Eigenschaften in
Archivematica technisch auf Dateiformate beschränkt ist. Eigenschaften, die die
Performance digitaler Objekte und die Nutzungsziele der designated community
betreffen, werden nicht berücksichtigt. Die Betrachtung der Performance spielt im
Use Case keine Rolle, da die Einrichtungen selbst für die Darstellbarkeit ihrer
Objekte auf ihre Nutzer hin verantwortlich sind, und nicht die Koordinierungsstelle
Brandenburg-digital und die digiS Berlin. Als Dienstleister stellen die beiden
Einrichtungen lediglich die authentische und integre Aufbewahrung langfristig bereit.
Grundsätzlich können zwei Erhaltungsstrategien mit Archivematica umgesetzt
werden – sowohl Emulationsstrategien, indem die originalen Bitstreams bewahrt
werden, als auch Migrationsstrategien, indem ein Monitoring über bedrohte
Dateiformate erfolgt und der Migrationsprozess zu einem zukünftigen Datum
gestartet wird.59
4.6 Importvorgaben: Ordnerstruktur und Objektmodell (AP 2)
Die Transferpakete (TIP’s) mussen in einer bestimmten Ordnerstruktur vorliegen,
damit Archivematica in der Lage ist, diese in den Transferbereich zu übernehmen.
Folgende Ordnerstruktur ist daher von den abgebenden Einrichtungen für die
Abgabe des TIP’s zu erstellen:
58
Vgl. Archivematica-Wiki: Format policies, o. O. 2015. URL: https://wiki.archivematica.org/Format_policies [14.02.2016].
59 Vgl. Hooten, T.; Jordan, P.; Van Garderen, Peter et al.: The Archivematica Project. Meeting Digital
Continuity’s Technical Challenges. In: Proceedings of The Memory of the World in the Digital Age. Digitization and Preservation. International conference on permanent access to digital documentary heritage, Vancouver 2012, S. 1353. URL: http://1seminariopreservacaopatrimoniodigital.dglab.gov.pt/wp-content/uploads/sites/19/2015/08/recurso_25.pdf [14.02.2016].
Objekts hängt also davon ab, auf welchen Ebenen die Abbildung des Objekts
erfolgen soll. Die Umsetzung der Bestandserhaltungsstrategie Migration spielt dabei
eine Rolle. Es stellt sich hierbei die Frage, ob künftig Einzeldateien migriert werden
sollen oder eine Gesamtdatei, welche unterschiedliche Inhalte (Text, Grafik)
enthalten kann, die sich zusammen verlustfrei nicht erhalten lassen. Daher empfiehlt
es sich, die zweite Ablagevariante zu wählen und tatsächlich alle Objektebenen
(Repräsentationsebene, Dateiebene, Bitstreamebene) – also so granular wie möglich
– abzubilden, damit auch ausreichende Langzeitarchivierungsmetadaten hinzugefügt
werden können, die das Objekt beschreiben und seine authentische
Langzeiterhaltung, auf logischer und physischer Ebene, sicherstellen.62 Die
Abbildung von Objektebenen ist für die Übertragbarkeit auf andere
Digitalisierungsprojekte für jeden Objekttyp speziell zu definieren.
Die vom Digitalisierungslabor der FH Potsdam erstellten Digitalisate der Popularen
Schriftzeugnisse liegen im TIFF-Format vor. Jede Seite eines Schriftzeugnisses
besteht aus einer einzelnen TIFF-Datei. Es wird festgelegt, diese in einem
Unterordner unter /objects abzulegen, damit die Dateien im Einzelnen auch auf
Bitstreamebene erhalten werden können. Nach der Übernahmevereinbarung der
digiS sind die digitalen Objekte generell in archivfähigen Formaten zu liefern. Die
Koordinierungsstelle Brandenburg-digital sollte daher im Vorfeld der Übernahme die
Einrichtungen über mögliche Archivformate beraten.
Ggf. können in einem weiteren Ordner /metadata Checksummen zu den Objekten in
Form einer MD5-, SHA1- oder SHA256-Dateien mitgeliefert werden. Archivematica
überprüft diese mit einem Microservice im Transfer-Workflow. Des Weiteren soll im
Ordner /metadata die von den Einrichtungen erstellte METS-Datei unter Benennung
„mets.xml“ mitgeliefert werden. Der Ordner /metadata enthält noch einen Unterordner
/submissionDocumentation, welcher bspw. Übergabeformulare oder
Schenkungsvereinbarungen enthalten kann.63
62
Vgl. hierzu VdW-Arbeitskreis „Elektronische Archivierung“: Premis Handreichung, o. O. 2011, S. 3-5. URL: http://www.wirtschaftsarchive.de/arbeitskreise/fachliche-arbeitskreise/elektronische-archivierung/PremisHandreichung.pdf [14.02.2016].
dmdsec bindet die beschreibenden Metadaten im Dublin-Core-Format per mdWrap
ein (vgl. Abb. 14).
Abbildung 15: TIP filesec
Die filesec identifiziert die einzelnen Dateien, indem MD5-Prüfsummen vergeben
werden und lokalisiert diese anhand des Dateinamens (vgl. Abb. 15).
Abbildung 16: TIP structmap
Hierauf folgt die structmap, welche die Struktur der intellektuellen Entität in einzelne
Abschnitte aufteilt. Hier erkennt der METS-Editor einzelne Seiten des Liederbuches
und ordnet diese einer Nummerierung zu.66
Nach der Erstellung der METS-Datei schloss sich die händische Ordnung des Pakets
in die von Archivematica geforderte Ordnerstruktur objects, metadata und logs an
sowie die Verpackung in ein zip-Format mittels der Software 7-zip, wodurch sich die
Größe des Pakets auf 655MB verringerte. Über die Software WinSCP erfolgte hierauf
der Upload auf den NAS-Speicher in der FHP mit SFTP, was extern außerhalb der
Fachhochschule durchgeführt, etwa 3 Stunden dauerte.
66
Zum Aufbau der METS-Datei vgl. Auch Anhang 1.
42
Abbildung 17: Aufbau TIP
Testdurchlauf 1: Erzeugung SIP ohne Formatidentifikation & -validierung
Der erste Testdurchlauf fand ohne die Microservices der Formatidentifikation und der
Formatvalidierung statt. Dieser Ablauf orientiert sich am Workflow des Pre-Ingest der
digiS, welcher diese Komponenten erst im Ingest mit Archivematica vorsieht. Nach
dem erfolgreichen Durchlaufen der Microservices wurde das SIP im backlog
gespeichert und die neu erzeugte METS-Datei untersucht. Der Aufbau des
Informationspaketes verändert sich dahingehend, dass unter dem Ordner /objects
sich das gesamte TIP befindet. Der Ordner /metadata erhält den Unterordner
/submissionDocumentation mit der neu erzeugten METS-Datei. Dem Ordner /logs
wurde ein Unterordner /fileMeta hinzugefügt, mit einer eigenen log-Datei zur
Formatidentifikation. Ebenso erscheint auf oberster Ebene eine processingMCP.xml,
die Entscheidungen protokolliert, in diesem Fall jedoch keinen Inhalt besitzt. Das
Gesamtpaket erhält als Namen die ursprüngliche Bezeichnung sowie eine vergebene
UUID (vgl. Abb. 17). Im Wesentlichen erzeugt Archivematica in der neuen METS-
Datei Premis-Events zum Beginn des Ingest, der Quarantäne sowie der Vergabe von
UUID’s (vgl. beispielhaft Abb. 18).
43
Abbildung 18: SIP amdSec
Beachtenswert an diesem Workflow ist die Protokollierung der Formatidentifikation,
obwohl diese explizit abgelehnt wurde. Zudem erscheint die Namensnennung des
Ordners /submissionDocumentation problematisch, da die Lösung der digiS diesen
Ordner nicht für die METS-Datei vorsieht, sondern für weitere Objekte oder
Metadaten, welche den Kontext weiter erläutern, wie zugehörige E-Mails. An dieser
Stelle muss innerhalb von Archivematica die Benennung umgeändert werden.
Weiterhin findet keine Metadatenextraktion von beschreibenden Metadaten aus der
mitgelieferten METS-Datei statt. Der Microservice Charaktersize and extract
metadata kann im Transfer von Archivematica nur mit einer CSV-Datei durchgeführt
werden. Die Extraktion der Metadaten aus dem TIP erfolgt hier erst im Bereich des
Ingest. Das durchgeführte Szenario führt daher zu Konflikten. Als Lösung bietet sich
eine externe Metadaten-Datei an, welche mit der METS-Datei über eine mdref-
Verknüpfung in der dmdSec verbunden ist.
Der Aufbau der SIP METS-Datei ist aufgrund der nicht durchgeführten
Formatidentifikationen recht übersichtlich. Der Header beinhaltet lediglich ein
Erstellungsdatum und Archivematica als METS-Agent in der Rolle Creator. Darauf
folgen in der amdSec vier digiprov_md Abschnitte, die folgende Ereignisse
protokollieren:
44
Ingestion: Durchführung des Transfers
Virus check: Virenprüfung
Quarantine: Überführung in Quarantäne
Unquarantine: Ausgabe aus der Quarantäne
Die darauffolgende fileSec zeigt auf, dass Archivematica das TIP als Ganzes
analysiert und als ein Objekt in zip-Format aufzeichnet. Eine Darstellung der
enthaltenen XML- und TIFF-Dateien erfolgten hier nicht. Abschließend folgt die
Auflistung der structMap, jeweils als “original“ und “processed“. Ein Unterschied
beider Werte konnte nicht festgestellt werden.67
Abbildung 19: Aufbau SIP
Testlauf 2: Erzeugung AIP mit Formatidentifikation und -validierung
Aufgrund der unzureichenden Testergebnisse des ersten Durchlaufs findet ein
weiterer Testdurchlauf statt. Dazu wird ein AIP aus dem Transferpaket erstellt und
alle vorhandenen Microservices zur Formatidentifikation, -validierung und der
Metadatenextraktion angewandt. Das entstehende AIP sowie die dazugehörige
67
Vgl. Auch Anhang 2: Struktur der SIP METS-Datei.
45
METS-Datei werden dann untersucht. Innerhalb des Transfers dient das Tool FIDO
der Formatidentifikation.
Nach Durchlauf aller vorhandenen Microservices zeigt sich, dass das AIP sich in
seiner Struktur wesentlich gegenüber dem TIP und dem SIP vergrößert. Auf oberster
Ordnerebene sind neben dem Verzeichnis /data vier txt-Dateien enthalten. Die
tagmanifest-md5 enthält eine Prüfsumme und ein Verzeichnis der anderen Dateien
auf dieser Ebene. Die manifest-sha512 stellt ebenfalls eine Prüfsumme dar. Die bag-
info-Datei enthält ein Datum, wann das AIP gepackt wurde und welche Größe es
besitzt, die weitere bagit.txt gibt lediglich die BagIt-Version wieder. Das Verzeichnis
/data gliedert sich wiederum weiter auf in /objects und /logs sowie der neu
generierten AIP-METS (vgl. Abb. 20).
Abbildung 20: AIP Oberverzeichnisse
Das Unterverzeichnis /objects befindet sich, ähnlich dem SIP, das TIP als zip-Datei
sowie unter /submissionDocumentation die im Transfer erzeugte METS.xml des
Ingest (vgl. Abb. 21).
46
Abbildung 21: AIP Unterverzeichnis /objects
Im Unterverzeichnis /logs liegen der Bezeichnung entsprechend die Protokolle über
ausgeführte Microservices vor. Die fileFormatIdentification.log gibt die
Formatidentifikation für sämtliche Dateien in plain-Text wieder und erscheint
redundant auf mehreren Ebenen. Da Archivematica im Testlauf des SIP‘s auch ohne
Kommando ein Formatidentifikationsprotokoll anlegte, scheint es sich bei der Datei
auf unterster Ebene um das Ergebnis für den im Transfer ausgelösten Microservice
zu handeln, welcher auch eine etwas höhere Bitgröße besitzt. Mittels
contractContents.log werden einige Metadaten zum entpacken des zip-Ordners
mitgeliefert. Der Microservice examine contents des Transferbereiches führt das Tool
bulk_extractor aus. Diese Software dient dazu, potentiell sensible Daten aus digitalen
Objekten zu erkennen und aufzuzeigen. Diese Daten sollen so vor versehentlicher
Veröffentlichung geschützt werden. Das Tool scannt dabei die Datei bspw. Auf
vorhandene http-logs oder E-Mail- bzw. Telefon-Informationen ab. Insgesamt
erscheint das Tool nützlich, jedoch aufgrund der großen Verzeichnisstruktur, was es
verursacht, und die schwere Handhabbarkeit kann dieser Microservice im
Projektverlauf ausgestellt werden (vgl. Abb. 22).68
68
Vgl. BitCurator Wiki: Using Bulk Extractor Viewer to Find potentially sensitive Information on a Disk Image. URL: http://wiki.bitcurator.net/index.php?title=Using_Bulk_Extractor_Viewer_to_Find_Potentially_Sensitive_Information_on_a_Disk_Image [14.02.2016]. Für eine detaillierte Auflistung aller durch Bulk
Den technischen Metadaten folgt der Abschnitt der digiprov_md zur Darstellung,
welche Abläufe die digitalen Objekte in Archivematica durchliefen, was der digitalen
‘Historie‘ bzw. ‘Herkunft‘ entspricht. Die Objekte durchlaufen dabei folgende
Prozesse:
Entpacken
Erstellung einer Prüfsumme
Virenprüfung
Format-Identifikation
Check der Prüfsumme
Darstellung der Premis-Agents: Software, Organisation und User
Die Primärobjekte durchlaufen in den folgenden amdSec’s dieselben Prozesse, sie
erhalten hingegen zusätzlich noch eine Validierung durch JHOVE. Weiter folgen die
fileSec und die structMap, welche sich jedoch inhaltlich zu den METS-Dateien
vorheriger Informationspakete nicht unterscheidet.69
69
Vgl. auch Anhang 3: Struktur der AIP METS-Datei.
49
5. Servicestelle Digitalisierung (digiS) am Konrad-Zuse-Institut
Berlin
Bei der Servicestelle Digitalisierung Berlin mit Sitz am Konrad-Zuse-Zentrum für
Informationstechnik Berlin (ZIB) handelt es sich um eine landesweit zentrale
Beratungs-, Unterstützungs- und Koordinierungsinstitution für Digitalisierungsprojekte
von Kulturerbe-Einrichtungen im Land Berlin.
Die von der Senatskanzlei – Kulturelle Angelegenheiten unterstützte Servicestelle
bietet seit ihrer Gründung im Jahr 2012 jährlich das Förderprogramm Digitalisierung
an. Bei den im Rahmen des Förderprogrammes durchgeführten
Digitalisierungsprojekten werden Archive, Bibliotheken, Museen und Gedenkstätten
nicht nur bei der Digitalisierung selbst unterstützt, sondern auch bei der zuvor
stattfindenden Inventarisierung (Erschließung) und dem Datenmanagement
(Workflow-Unterstützung und Datenaufbereitung) der zu digitalisierenden Objekte
sowie bei der anschließenden Präsentation der Objekte im Internet und der
Sicherung der digitalen Langzeitverfügbarkeit gefördert.70
Neben ihrer Rolle als Beratungs- und Koordinierungsinstitution, ermöglicht die digiS
durch die Vernetzung ihrer Projektpartner ebenfalls den Erfahrungsaustausch
zwischen den jeweiligen Institutionen. Außerdem werden regelmäßige Workshops
und Konferenzen mit Experten auf regionaler und bundesweiter Ebene angeboten,
um die Projektpartner weiterzubilden und sie zu „Gestaltern ihrer digitalen Praxis
werden zu lassen“.71 Zu den Aufgaben der Beratung, Koordinierung, Vernetzung und
Weiterbildung gehören auch die Datenpräsentation im Internet, die
Langzeitarchivierung und die Langzeitverfügbarkeit zu den Schwerpunkten der
Servicestelle. So berät die digiS ihre Projektpartner bei der Aufbereitung ihrer Daten
für Präsentationszwecke und leitet die Projektdaten des Förderprogrammes an die
Deutsche Digitale Bibliothek (DDB) weiter. Um diese Daten ebenfalls digital
langzeitarchivieren zu können, werden auf Standards basierende Services zur
langfristigen Speicherung der erzeugten Digitalisate und Metadaten erarbeitet. Diese
Services sollen nicht nur den Datenstrom der Objekte erhalten (bitstream
70
Vgl. Senatskanzlei – Kulturelle Angelegenheiten: Förderrichtlinie der Senatskanzlei – Kulturelle Angelegenheiten zur Digitalisierung von Objekten des kulturellen Erbes des Landes Berlin. Berlin 2015. S. 3 f.
Zwangsarbeit II, Berlin 2015. URL: http://www.servicestelle-digitalisierung.de/confluence/display/DIG/Stiftung+Topographie+des+Terrors+-+Dokumentationszentrum+NS-Zwangsarbeit+II [14.02.2016].
74 Vgl. Servicestelle Digitalisierung: Georg Kolbe Museum III. Berlin 2015. URL:
EAD (Encoded Archival Description), LIDO (Lightweight Information Describing
Objects)), Content Informationen (Binär- oder textuelle Daten) zur Content
Information zusammengefasst.
In der Ingest-Phase wird eine Kennung fur das AIP erzeugt und vergeben (fur jedes
Datenobjekt innerhalb des AIP). Der Ingest-Workflow sieht vor, gängige Dateiformate
Abbildung 24: Systemarchitektur im Zuse-Institut Berlin
52
zu identifizieren und notwendige technische Metadaten zu extrahieren. An dieser
Stelle kommt Archivematica zum Einsatz. Dateiformate die nicht den Archivformaten
entsprechen werden normalisiert, wenn der gelieferte Inhalt als eine Reihe von
bekannten Formaten identifiziert werden konnte. (Voraussetzung dafur sind
existierende Format-Policies). Aktiv erhalten bleiben können nur in einer Reihe von
Archivformaten, oder in normalisierten konformen Versionen. Können Inhalte nicht
ausreichend identifiziert werden, bleiben sie lediglich passiv erhalten (auf Bit-Ebene).
Nach Ablauf des Ingest-Prozesses wird der jeweilige Ansprechpartner uber den
Versand einer Email daruber in Kenntnis gesetzt und die hinterlegten Daten stehen in
der Verantwortung des Archivs. Während des Ingest-Vorgangs werden sowohl AIP
als auch DIP in Archivematica erzeugt (vgl. im Weiteren auch Kapitel 5.3).77
Datenverwaltung Das Daten-Management-System iRods wird am Zuse-Institut Berlin eingesetzt, um
die Aufgaben der Datenverwaltung abzudecken: Die Software erlaubt einen Zugriff
auf die erzeugten Datenobjeke (AIP‘s) durch Vorgänge die den Zugriff kontrollieren
und Rollenbasiert erlauben. Dabei können die Daten unabhängig von ihrer
physischen Lokation mit iRods durchsucht und gefunden werden (z.B. auf den Tapes
oder Online-Speichern). Das System iRods ist im Zuse-Institut Berlin auch fur die
Verwaltung der AIP-Prufsummen zuständig.78
Archivspeicher Die OAIS-Funktionskomponente „Archivspeicher“ wird im ZIB durch die Software
SAM, einem hierarchischen Storage-Archive-Manager verwaltet. Eine genaue
Trennung zwischen Datenverwaltung und Archivspeicher ist im Modell des Zuse-
Instituts schwer möglich, da beide Prozesse sehr eng miteinander verzahnt sind.79
Erhaltungsplanung Die Erhaltungsplanung wird im ZIB ebenfalls anders gehandhabt: Die Daten-
Management-Komponente regelt eine Migration von AIP‘s. Dabei können Metadaten
77
Amrhein, Kilian; Klindt, Marco: One Core Preservation System for All your Data. No Exceptions! In: iPRES 2015. Proceedings of the 12th International Conference on Preservation of Digital Objects, Chapel Hill 2015, S. 3f. URL: https://opus4.kobv.de/opus4-zib/frontdoor/index/index/docId/5663 [14.02.2016].
hinzugefugt werden, sowie eine neue Identifikation der Dateien und ggf. eine erneute
Normalisierung angestoßen werden.
Administration Die Komponente „Administration“ findet im ZIB keine direkte Entsprechung, sondern
wird durch die Zugriffs- und Management-Komponenten abgedeckt.
Zugriff Die Komponenten Management und Zugriff sind stark miteinander verbunden: im
Berliner Modell wird dabei in zwei Nutzerrollen unterschieden; Daten-Manager und
Daten-Konsumenten bilden die Nutzerschaft der Archivlösung. Je nach Nutzerrolle
werden unterschiedliche Views auf das gleiche Paket erstellt:
Der Daten-Manager erhält Zugriff auf DIP mit PDI (Preservation Description
Information) und der Daten-Konsument bekommt das DIP inklusive der DI
(Descriptive Information) präsentiert. Als Front-End fur die Konsumenten wird
Islandora eingesetzt; Fedora als Management-Software die Basis fur die Rolle der
Daten-Manager.80
5.2 Aufbau der Informationspakete im Vergleich zum OAIS-
Informationsmodell (AP 3)
Im Folgenden wird dargestellt, wie die Informationspakete bei der digitalen
Langzeitarchivierung der Servicestelle Digitalisierung Berlin geformt sind.
Nachdem in der Deposit-Phase die digitalen Informationen so aufbereitet wurden,
dass sie als ein SIP von dem Produzenten an das digitale Archiv der digiS
übergeben werden können, beginnt der eigentliche Ingest. Das SIP besteht aus vier
Bausteinen. Der erste Baustein, das Submission Manifest, enthält Metadaten zur
Lieferung und dient somit der Identifizierung der gelieferten Daten und der
Ansprechpartner beim Datenproduzenten im Zuge des Lieferprozesses. Zum zweiten
beinhaltet das SIP beschreibende Metadaten zum digitalen Objekt, bei denen
verschiedene Metadatenformate denkbar sind. Neben dem eigentlichen Inhalt bzw.
dem Datenobjekt an sich, das Binärdaten und Textdateien beinhaltet, besteht das
80
Vgl. Amrhein, Kilian; Klindt, Marco: One Core Preservation System for All your Data, S. 5. URL: https://opus4.kobv.de/opus4-zib/frontdoor/index/index/docId/5663 [14.02.2016].
SIP zuletzt auch aus einer Submission Documentation. In dieser sind
Kontextinformationen abgelegt, die nützlich sein könnten, um das abgelegte Material
in Zukunft verstehen zu können, die aber nicht Teil des Informationsobjektes sind
und deshalb für die Erhaltung keine Rolle spielen.81
Nun wird das AIP gebildet. Dieses gliedert sich wiederum in vier
Informationselemente. So werden die Informationen des Submission Manifests des
SIP‘s in die Administrative Description Information (ADI) des AIP in dem
Metadatenformat Dublin Core überführt. In das AIP hinzugefügt wird die Preservation
Description Information (PDI) in dem Metadatenstandard PREMIS. Das dritte
Element des AIP besteht aus der Description Information (DI), die die
beschreibenden Metadaten aus dem SIP beinhaltet, die allerdings zuvor ebenfalls in
das Metadatenformat Dublin Core gemappt wurden. Diese Metadaten befinden sich
noch einmal, diesmal jedoch in ihrer ursprünglichen Version in den Content
Information (CI) des AIP. Die Content Information (CI) besteht außerdem aus der
Submission Documentation, aus dem eigentlichen Content bzw. dem Datenobjekt
aus Binärdaten und Textdateien aus dem SIP in normalisierter Form sowie aus
Zugangskopien.
Zuletzt wird aus dem AIP ein DIP, welches dem Zugang dient. Das DIP lässt sich in
zwei verschieden Ausgaben der Linux-Distribution Fedora anzeigen. Für
Verwaltungs- und Managementzwecke dient das Admin Access Compound Object
(AACO). Das AACO gibt Zugriff auf die administrativen Dateien der ADI aus dem
Submission Manifest und auf die PREMIS-Daten der PDI. Zusätzlich verweist es auf
CI mit dem normalisierten Datenobjekt und die Zugriffskopien. Die zweite Ausgabe,
das Content Access Compound Object (CACO) dient dem Auffinden des Inhalts des
Informationspaketes. Die beschreibenden Metadaten der DI und die Zugriffskopien
werden über dieses Objekt zugänglich. Die Informationsobjekte können so auf Basis
der gemappten Dublin Core-Metadaten abgerufen werden.
81
Vgl. Amrhein, Kilian; Klindt, Marco: One Core Preservation System for All your Data, S. 3. URL: https://opus4.kobv.de/opus4-zib/frontdoor/index/index/docId/5663 [14.02.2016].
Abbildung 25: UML-Datenmodell der Informationspakete der digiS in Anlehnung an das OAIS-Modell
Vergleicht man diesen Ansatz des Designs der Informationspakete mit dem des
OAIS-Modells, so fällt folgendes auf: Im OAIS-Modell wird das AIP durch eine
Packaging Information identifiziert und durch eine Package Description beschrieben.
Statt dieser zwei Elemente nutzt die digiS bei dem Aufbau ihrer Informationspakete
die Administrative Description Information (ADI), die Metadaten zur Lieferung enthält
und der Identifizierung der gelieferten Daten und der Ansprechpartner beim
Datenproduzenten dient und aus dem Submission Manifest des SIPs stammt. Zudem
enthält diese ADI Metadaten, die Informationen zur Provenienz, zur Fixity und zu den
Zugriffsrechten des zu archivierenden Datenobjekts bereitstellen, die laut dem OAIS-
Modell lediglich in die Preservation Description Information (PDI) gehören. Das AIP
der digiS besteht allerdings zusätzlich ebenfalls aus den Preservation Description
Information (PDI), die weitere Metadaten zur Erhaltung, wie Referenz- und
Kontextinformationen enthält, und so die Content Information (CI) näher beschreibt.
Diese Content Information (CI) enthält bestimmte Metadaten zum Inhalt, die im
OAIS-Modell Representation Information genannt werden, gegeben falls die
Submission Documentation sowie den Content an sich, der im OAIS-Modell als Data
56
Object bezeichnet wird. Zusätzlich beinhaltet das AIP der digiS die Description
Information (DI), die nochmals die Metadaten zum Inhalt des Datenobjektes umfasst,
diese diesmal jedoch im in das Format Dublin Core gemappten Zustand aufweist.
Insgesamt wird deutlich, dass die Vorgehensweise bei der Langzeitarchivierung der
digiS an die des OAIS-Modells angelehnt ist, sich jedoch in einigen Bereichen in der
Elementbenennung oder sogar der Verteilung der Metadaten unterscheidet. Da das
OAIS-Modell lediglich ein Referenzmodell ist und nicht starr übernommen werden
muss, sondern an die Zwecke der Einrichtung beliebig angepasst werden kann, ist
dies durchaus legitim.
5.3 Pre-Ingest- und Ingest-Ablauf (AP 2)
Der Bereich des Pre-Ingest in der digiS gliedert sich in vier Phasen.82 In der Data
Deposit Registration wird das Informationspaket durch den Produzenten aufbereitet
und für den Upload vorbereitet. Durch ein Webportal ist es möglich, einen Identifier
zu beantragen, welcher das Paket und den Transfer identifiziert. An dieser Stelle
können zusätzliche PDI manuell hinzugefügt werden, die sich ansonsten in der
Submission Manifest befinden. Im Bereich Data Transfer findet der eigentlich Upload
über das Webportal statt. Alternativ kann nach Vereinbarung auch eine Übernahme
per Festplatte erfolgen. Der Submitting and Compliance Test bildet die dritte Phase
des Pre-Ingest. Innerhalb dieser wird das Vorhandensein von Dateien mit PDI
(Submission Manifest) und DI (externe Metadatendatei) überprüft. Des Weiteren
findet hier eine Integritätsprüfung mittels Hashwerten statt. Sollte einer der beiden
Tests negativ ausfallen, wird der Transfer an dieser Stelle abgebrochen. Die
Restructuring ist die letzte Phase des Pre-Ingest. Diejenigen Produzenten, die nicht
in der Lage sind, SIP’s bereits vorzustrukturieren, werden an dieser Stelle unterstutzt
und die Informationspakete neu strukturiert. Anschließend folgen die Extraktion und
das Mapping der beschreibenden Metadaten. Der Bereich des Pre-Ingest ist damit
durchlaufen und die SIP’s sind fur den Ingest in Archivematica vorbereitet. Die
nachfolgende Tabelle gibt die einzelnen Schritte nochmals in Kurzform wieder:
82
Vgl. im Folgenden: Amrhein, Kilian; Klindt, Marco: One Core Preservation System for All your Data, S. 2-4. URL: https://opus4.kobv.de/opus4-zib/frontdoor/index/index/docId/5663 [14.02.2016].
Die Berliner Lösung in der digiS nutzt für den Bereich des Ingest die Software
Archivematica, weshalb sich die Abläufe an den dortigen Microservices orientieren.83
Nach Anstoßen des Ingest vergibt die Software UUID’s zur Identifikation der digitalen
Objekte und des Informationspakets. Hiernach folgen die Formatidentifikation, -
charakterisierung und –validierung. Nicht archivfähige Dateiformate werden in ein
entsprechendes Format migriert. Mittels der internen Tools von Archivematica
werden die technischen Metadaten extrahiert und mit den PDI, den DI, der logischen
und physischen Struktur des Informationspakets in eine neuerstellte METS-Datei
geschrieben. Dem folgt die Überführung in eine BagIt-Struktur, womit die eigentliche
Erstellung des AIP’s abgeschlossen ist. Aus dem AIP wird ein DIP zur Nutzung
generiert, die Bereiche Management und Access erhalten die extrahierten PDI und
DI. Der Produzent erhält nach Abschluss des Ingest einen Submission Report über
die erfolgreiche Übernahme per E-Mail.
83
Vgl. Amrhein, Kilian; Klindt, Marco: One Core Preservation System for All your Data, S. 4 URL: https://opus4.kobv.de/opus4-zib/frontdoor/index/index/docId/5663 [14.02.2016].
Der Raumbedarf eines funktionierenden Archivematica-Systems, insbesondere des
geplanten Pre-Ingest Systems, ist im Vergleich zu größeren und vollumfänglichen
Archiven als niedrig einzuschätzen. Die technischen Komponenten, im
Minimalszenario ein Server und ein Netzwerkspeicher, sind von ihrer Größe mit
einem Desktop-PC zu vergleichen. Aus Sicherheitsgründen müssen Server und
Speichereinheit getrennt gelagert sein, im Idealfall mit einem größeren Abstand oder
in getrennten Gebäuden. Da dies in vielen Fällen aus finanziellen und
organisatorischen Gründen nicht umsetzbar sein wird, muss zumindest gewährleistet
werden, dass der Raum grundlegend geeignet ist, um wichtige Speichermedien zu
beherbergen. Näheres zur Sicherheitskonzeption findet sich in Kapitel 6.5.
61
Ebenfalls notwendig sind Arbeitsplätze für die Mitarbeiter. Archivematica nutzt
standardmäßig einen webbasierten Client zur Bedienung. Dieser kann von jedem
internetfähigen Arbeitsplatz angesprochen werden. Eine leistungsfähige Hardware ist
für diese Arbeitsplätze nicht notwendig, da die eigentliche Bearbeitung im Server
stattfindet. Eine reguläre Büroausstattung mit PC und Monitor ist zum Ansprechen
des Systems ausreichend.
Um Daten größeren Umfangs zu transportieren, wird eine entsprechend
leistungsfähige Netzwerk- und Internetverbindung benötigt. Um genaue
Anforderungen aufzustellen, muss das geplante Nutzungsszenario einbezogen
werden. Der Workflow bestimmt maßgeblich, in welchem Umfang Daten über das
Netzwerk oder gar über das Internet transportiert werden. In jedem Falle muss aber
die Verbindung zwischen dem Server und dem Speicherort gewährleistet werden,
was ein Gigabit-Ethernet erforderlich macht, wenn größere Datenmengen im
Nutzungsszenario angedacht sind.
In der Standard-Distribution von Archivematica ist eine Internetverbindung
vorgesehen. Neben der Zugriffskomponente (die im Nutzungsszenario nicht geplant
ist) benötigt auch das Preservation Planning den Zugang zum Internet. Die
Funktionen des Systems, die mit Formatumwandlung im Sinne von Migration in
Archiv- und Zugriffsformate betraut sind, greifen auf eine Datenbank des Herstellers
Artefactual zu.85 Es bestünde jedoch auch die Möglichkeit, lokale Policies zu
definieren. Sollte zudem angedacht sein, den abgebenden Einrichtungen eine
Abgabe über ein Webportal zu ermöglichen, daher muss ein Weg gefunden werden,
dieses sinnvoll in das Gesamtsystem einzubinden.
Aus diesen Gründen ist es nicht möglich, auf die Internetverbindung im System zu
verzichten. Um dennoch die Sicherheit zu gewährleisten, muss eine Absicherung der
Systemverbindungen nach außen erarbeitet werden.
85
Die sog. Format Registry Policy ist ein frei zugänglicher Server, der auf Grundlage der internationalen Nutzergemeinschaft standardmäßige Schritte zur Formatbehandlung vorschlägt, siehe auch: Archivematica: Format Policy Registry. URL: https://wiki.archivematica.org/Administrator_manual_1.0#Format_Policy_Registry_.28FPR.29 [14.02.2016].
Archivematica bietet in sich keine umfassende Datenverwaltung an, die aber
maßgeblich ist, um die erstellten Übernahme- und Archivpakete nach dem
Transfer/Ingest wiederzufinden. Es existiert ein Plugin, welches diese Funktion
abdecken soll: ElasticSearch. Durch technische Probleme mit dem Ubuntu-System
und den darauf befindlichen Bestandteilen konnte das Suchsystem leider nicht
getestet werden. Es muss demnach noch geprüft werden, in welchem Umfang
ElasticSearch die Funktion der Datenverwaltung abdecken kann oder ob noch
zusätzliche Lösungen und Programmbestandteile hinzugezogen werden müssen
(wie es etwa im Zuse-Institut mit der Auslagerung der Datenverwaltung auf die
Bestandteile iRods und einem Repositorium der Fall ist87).
Der komplette Bereich des Access ist ebenfalls nicht in der Standard-Distribution
einbegriffen. Es ist jedoch die Möglichkeit vorgesehen, eine externe Zugriffsplattform
einzubinden. Der Hersteller bietet eine eigene Zugriffsplattform namens AtoM an, bei
der die DIP‘s auf externe Server geladen und zugänglich gemacht werden. Im
vorliegenden Anwendungsfall ist jedoch keine öffentliche Zugänglichmachung
vorgesehen, weshalb auf die angebotenen Access-Plattformen verzichtet werden
kann.
Einer der zentralen Bestandteile jedes digitalen Archivierungssystems ist der
Umgang mit den Metadaten. Archivematica bietet neben der manuellen Eingabe (die
wegen des hohen Aufwandes abgelehnt wird) auch die Möglichkeit, Metadaten zu
importieren. Standardmäßig sieht das System eine Übernahme in Form von CSV-
Dateien vor, deren Inhalte ausgelesen und im Dublin Core Standard übernommen
werden. Des Weiteren existiert die Möglichkeit, Metadaten aus XML-basierten
Formaten wie METS auszulesen, allerdings in einer Form, die die ursprüngliche
Ordnung der Metadatenfelder auflöst. Als Resultat dieser Einschränkung ist auch die
Metadatenübernahme ein Bereich, der in der konzeptionellen Planung des Einsatzes
bedacht werden muss und der eine Anpassung des Systems notwendig macht. Je
nach Use Case muss überlegt werden, ob eine Übernahme per CSV-Datei, die
Auslesung von XML-Dateien oder eine andere Methode den Zielen am besten
87
Vgl. Amrhein, Kilian; Klindt, Marco: One Core Preservation System for All your Data, S. 5f. URL: https://opus4.kobv.de/opus4-zib/frontdoor/index/index/docId/5663 [14.02.2016].
Vorgängen abbilden, die Software bildet so den gleichnamigen Standard vollkommen
ab. Ergebnis ist eine XML-Datei, die alle erfassten Metadaten enthält. Zusätzlich
besitzt der EDIAKT-Creator Funktionen zur Signierung und Validierung.
Auch hier kann die Software nicht die entsprechenden Anforderungen erfüllen, da es
keine Möglichkeit gibt, diese für Digitalisate einzusetzen und der Standard sich zu
spezifisch auf das Records Management bezieht.
Abbildung 32: Oberfläche des EDIAKT-Creators
Package Handler
Eine weitere Lösung für ein Übernahmetool bildet der Package Handler des
Schweizerischen Bundesarchivs. Der Package Handler steht als Freeware nach
einer Registrierung zur Verfügung und besitzt mehrere Hauptfunktionen: Erstellen
eines SIP’s, Erzeugung und Bearbeitung von Metadaten sowie eine Suchmöglichkeit.
Das Tool ermöglicht die Erstellung eines SIP’s nach der Struktur Akte, Vorgang,
Dokument innerhalb der zweier Unterverzeichnisse /content und /header und bietet
dazu eine Validierungshilfe. Ebenso ist es auch möglich, eigene
Verzeichnisstrukturen zu bilden, die jedoch nur den logischen Aufbau zur Ansicht
betreffen. Die physische Struktur wird dadurch nicht verändert.
80
Aufgrund seines eigentlichen Zwecks ist der Package Handler für Archive
ausgerichtet und soll Schweizer Standards erfüllen. Problematisch erscheint die
Einteilung in die Hierarchie Akte, Vorgang, Dokument, was mit Digitalisaten aus
Kulturgütern nicht möglich ist. Insgesamt erscheint die Software zu spezifisch, um
sinnvoll für das Projekt genutzt zu werden.
Als Ergebnis des Tests hat der docuteam packer, in Verbindung mit der
Abgabemöglichkeit über den SIP Creator, die meiste Übereinstimmung mit den
Anforderungen zu verzeichnen. Die Möglichkeiten der Abspeicherung von
Verzeichnisstrukturen, das Validieren von Submission Agreements, die
Protokollierung von Aktionen sowie die Erstellung einer METS-Datei hieraus sind
wichtige Merkmale der gesetzten Anforderungen an ein Ingest-Tool für diesen
Anwendungsfall. Problematisch ist die alleinige Verwendung von EAD, was zu
Mehrarbeit beim Mapping von anderen Standards bedeutet, bzw. wird ein Mapping-
Tool in vorhinein benötigt.
Abbildung 33: Oberfläche Package Handler
81
7. Metadatenkonzept (AP 2)
7.1 Langzeitarchivierungsmetadaten
Metadaten bilden essentielle Komponenten der digitalen Langzeitarchivierung. In den
Guidelines der UNESCO sind vier fundamentale Prinzipien der Langzeitarchivierung
in Bezug auf die Rolle der Metadaten definiert:
„17. Digital heritage materials must be uniquely identified, and described using
appropriate metadata for resource discovery, management and preservation.
18. Taking the right action later depends on adequate documentation. It is easier to
document the characteristics of digital resources close to their source than it is to
build that documentation later.
19. Preservation programmes should use standardised metadata schemas as they
become available, for interoperability between programmes.
20. The links between digital objects and their metadata must be securely
maintained, and the metadata must be preserved.“99
Auch als „the backbone of digital curation“100 bezeichnet, erlauben Metadaten, dass
digitale Objekte im Langzeitarchiv identifiziert, lokalisiert, zugänglich gemacht,
verstanden und genutzt werden können.101 Ein Set an Metadaten ist notwendig, um
vor allem die Wiederauffindbarkeit und das Management von Content und digitalen
Objekten durch Personen oder automatisch durch Systeme (Agenten) zu
gewährleisten. Es werden Metadaten aus zwei Gesichtspunkten für die
Langzeitarchivierung benötigt:
Die minimal verbindlichen Metadaten, die jederzeit erforderlich sind, um das
Management von Langzeitarchiv-Inhalten zu ermöglichen
99
UNESCO: Guidelines for the preservation of digital heritage, Paris 2003, S. 22. URL: unesdoc.unesco.org/images/0013/001300/130071e.pdf [14.02.2016].
100 Higgins, Sarah: What are Metadata Standards, Aberystwyth 2007. URL: http://www.dcc.ac.uk/resources/briefing-papers/standards-watch-papers/what-are-metadata-standards [14.02.2016].
101 Vgl. Harvey, Ross: Preserving Digital Materials, 2. Aufl. [2005], Berlin, Boston 2012 (=Current Topics in Library and Information Practice), S. 83.
Die Bandbreite zulässiger Metadaten, die – sofern verfügbar – für die
Erschließung interessant ist102
Anforderungen an Metadaten für die Langzeitarchivierung sind:
Zu ermöglichen, dass digitale Objekte jederzeit lokalisiert werden können –
unabhängig davon, wo sie gespeichert sind
Digitale Objekte eindeutig zu beschreiben
Die Beziehung zwischen einem digitalen Objekt mit einem anderen
aufzuzeigen
Die technischen Charakteristiken eines digitalen Objekts eindeutig zu
identifizieren
Aufzuzeigen, wer die Verantwortung für das Management und die Erhaltung
digitaler Objekte trägt
Zu beschreiben, wie digitale Objekte rechtmäßig genutzt werden können
Die Erfordernisse der Wiederdarstellung digitaler Objekte zu beschreiben
Die Historie digitaler Objekte zu erfassen
Sowie die Authentizität digitaler Objekte zu dokumentieren.103
Die Arten von Metadaten lassen sich allgemein nach Funktionen kategorisieren:
Deskriptive Metadaten: beschreiben digitale Objekte zur Identifikation und
Lokalisierung
Strukturelle Metadaten: zeigen die Beziehung von einem digitalen Objekt zu
anderen auf
Technische Metadaten: erfassen Details technischer Aspekte der Erstellung,
Konvertierung und Formatierung digitaler Objekte, die erforderlich sind, um sie
nutzbar zu machen
Administrative Metadaten: beschreiben die im Zusammenhang mit Objekten
angewandten Prozesse über die Zeit hinweg, welche Metadaten zum
Rechtemanagement enthalten können oder andere spezifische Arten von
Metadaten
102
Vgl. Brown, Adrian: Practical digital preservation. A how-to guide for organizations of any size, London 2013, S. 155.
103 Vgl. Harvey, Ross: Preserving Digital Materials, S. 83.
83
Langzeitarchivierungsmetadaten:104 erfassen die Provenienz digitaler Objekte
und die angewandten Maßnahmen an ihnen, wie sie über die Zeit hinweg in
einem digitalen Langzeitarchiv verwaltet werden.105
Als Langzeitarchivierungsmetadaten werden Informationen bezeichnet, die ein
Langzeitarchiv einsetzt, um den Prozess der digitalen Langzeitarchivierung zu
fördern. So ermöglicht die Ablage von Checksummen die Überprüfung, ob eine Datei
innerhalb eines bestimmten Zeitraumes verändert worden ist. Metadaten zum
Dateiformat und deren Unterstützung durch Hardware- und Softwareumgebungen
fördern die Durchführung von Langzeiterhaltungsmaßnahmen, die notwendig sind,
um die digitalen Objekte vor obsolet werdenden Dateiformaten und Anwendungen zu
schützen. Der Einsatz von Langzeiterhaltungsstrategien wie Migration und Emulation
erfordert teilweise die Veränderung der digitalen Objekte oder ihrer Darstellung,
weshalb die Authentizität der digitalen Objekte nicht absolut gewährleistet, aber mit
Metadaten zur digitalen Provenienz der Objekte, der Verarbeitungskette und Historie
der autorisierten Veränderungen unterstützt werden kann.106 Eine Bestimmung der
signifikanten Eigenschaften, d. h. der Charakteristiken eines digitalen Objekts, die
mittels Langzeitarchivierungsmaßnahmen erhalten werden sollen, und deren Ablage
in Metadaten, tragen ebenfalls zur Sicherung der Authentizität bei. Ein
Vorgehensmodell zur Definition von signifikanten Eigenschaften findet sich im
Leitfaden zur digitalen Bestandserhaltung von nestor.107
Um die Digitalisate dauerhaft zu erhalten, müssen Langzeitarchivierungsmetadaten
mitgeliefert, generiert und verwaltet werden. Eine konzeptionelle Grundlage solcher
Metadaten liefert das OAIS-Informationsmodell, indem es eine Taxonomie der
Informationsobjekte und Pakete für archivierte Objekte und die Struktur ihrer
assoziierten Metadaten abbildet:108
104
Manchmal auch als Teilmenge administrativer Metadaten angesehen. 105
Vgl. Harvey, Ross: Preserving Digital Materials, S. 83-84. 106
Vgl. Caplan, Priscilla: PREMIS verstehen, aus dem Engl. von Tobias Beinert, Washington 2009 [2009], S. 3. URL: http://www.loc.gov/standards/premis/understanding_premis_german.pdf [14.02.2016].
107 Siehe nestor-Arbeitsgruppe Digitale Bestandserhaltung (Hrsg.): Leitfaden zur digitalen Bestandserhaltung. Vorgehensmodell und Umsetzung, Version 2.0, Frankfurt am Main 2012 (=nestor-materialien 15). URL: http://files.dnb.de/nestor/materialien/nestor_mat_15_2.pdf [14.02.2016].
108 Vgl. Qin, Jian; Zeng, Marcia Lei: Metadata, London 2008, S. 61.
Demnach finden sich beschreibende Metadaten im Archivinformationspaket (AIP)
selbst wieder – in der Paketbeschreibung und Verpackungsinformation –, aber auch
in den Erhaltungsmetadaten, welche die Inhaltsinformation näher beschreiben und
dessen digitale Provenienz, Verarbeitungskette und Historie der autorisierten
Veränderungen dokumentieren und überprüfbar machen. Die
Repräsentationsinformation wird benötigt, um das Datenobjekt lesen und
interpretieren zu können. Der Abgleich des entwickelten Metadatenkonzeptes mit
dem OAIS-Informationsmodell ist in Kapitel 7.5 dargelegt.
7.2 Technische Metadaten und Tools
Technische Metadaten beschreiben die archivierten Objekte unter technischen
Gesichtspunkten und sind langfristig zu erhalten, um nachzuvollziehen, mit welchen
Mitteln, durch wen und in welcher Umgebung die digitalen Objekte entstanden sind.
109
nestor-Arbeitsgruppe OAIS-Übersetzung/Terminologie: Referenzmodell für ein Offenes Archiv-Informations-System. Deutsche Übersetzung 2.0, hrsg. von nestor – Kompetenznetzwerk Langzeitarchivierung, Frankfurt am Main 2013 (=nestor-materialien 16), S. 69. URL: http://files.dnb.de/nestor/materialien/nestor_mat_16-2.pdf [14.02.2016].
Diese Metadaten sichern langfristig die Lesbarkeit der digitalen Objekte. Denn nur,
wenn die Umgebung und das Verhalten der digitalen Objekte bekannt ist, kann mit
entsprechenden Erhaltungsmaßnahmen die Lesbarkeit wiederhergestellt und die
Interpretierbarkeit für Nutzer ermöglicht werden bzw. auf Grundlage dieses Wissens
Entscheidungen für Langzeiterhaltungsmaßnahmen getroffen werden. Zudem
bewahren die technischen Metadaten die Integrität und Authentizität der digitalen
Objekte, wodurch das digitale Langzeitarchiv eine vertrauenswürdige digitale
Langzeitarchivierung nach DIN 31644 nachweist.110
Es gibt zahlreiche technische Werkzeuge, die die automatisierte Erstellung
technischer Metadaten unterstützen, z. B. DROID zur Identifizierung von
Dateiformaten oder JHOVE für die Validierung ausgewählter Dateitypen.111 JHOVE
wurde von der Harvard Universität entwickelt. Das Tool führt eine Reihe von
Überprüfungen am digitalen Objekt durch. Es identifiziert, validiert und produziert
detaillierte technische Metadaten aus digitalen Objekten. Die Validierung beinhaltet
die Überprüfung auf Konformität mit der Formatspezifikation (nach den syntaktischen
und semantischen Regeln für ein valides Objekt). Mittels der näheren
Formatcharakterisierung können aus einer TIFF-Datei vierzig
Informationskomponenten aus den Spezifikationen der „NISO image metadata“,
welche im MIX-Standard für technische Metadaten von digitalen Bildobjekten
verankert sind,112 extrahiert und in die Metadatendatei geschrieben werden.113 Das
ist ein großer Vorteil, jedoch nutzt Archivematica aus JHOVE lediglich die
Validierungsfunktion. Weitere Funktionen werden durch andere implementierte,
interne Tools erfüllt (vgl. hierzu Kapitel 4.2).
7.3 Metadatenstandards
7.3.1 METS
METS (Metadata Encoding und Transmission Standard) ist ein XML-basierter
Standard für die Verwaltung von digitalen Objekten innerhalb eines Repository und
110
Vgl. Keitel, Christian; Schoger, Astrid (Hrsg.): Vertrauenswürdige digitale Langzeitarchivierung nach DIN 31644, Berlin 2013 [Kommentar], S. 67.
111 Vgl. ebd., S. 67-68.
112 Siehe National Information Standard Organization: Data Dictionary. Technical Metadata for Digital Still Images, Bethesda 2006. URL: http://djvu.org/docs/Z39-87-2006.pdf [14.02.2016].
113 Vgl. Gartner, Richard; Lavoie, Brian: Preservation Metadata (2nd edition). DPC Technology Watch Report 13-03 May 2013, York 2013, S. 21. URL: http://www.dpconline.org/component/docman/doc_download/894-dpctw13-03 [14.02.2016].
Element eingebunden werden können. Eine zweite Möglichkeit besteht in der
Referenzierung auf eine externe Metadaten-Datei mit dem <mdRef>-Element.115
7.3.2 Dublin Core
Der Dublin Core-Metadatenstandard wird seit 1995 entwickelt, um jede Ressource im
Web mittels Beschreibung zu lokalisieren und identifizieren, etwa Webseiten oder
Text-Content. Die Weiterentwicklung des Standards mit Spezifikationen erfolgte
durch die eingerichtete Dublin Core Metadata Initiative (DCMI).116 Das „qualified
Dublin Core metadata schema“,117 das erweitert einige wenige Spezifikationen
gegenüber der Version 1.1 besitzt, erlaubt genauere und einheitliche semantische
Beschreibungen. So lässt sich beispielsweise die zeitliche Komponente des digitalen
Objekts (<dcterms:coverage>)118 unter dem Element <dcterms:temporal>119 und
114
Vgl. Digital Library Federation: <METS>. Metadata Encoding and Transmission Standard. Primer and Reference Manual, überarbeitete Version 1.6, o. O. 2010, S. 1 und 15, download METS-Primer-Datei unter URL: http://www.loc.gov/standards/mets/mets-schemadocs.html [14.02.2016].
115 Vgl. The Library of Congress: METS. An Overview & Tutorial, o. O. 2011. URL: http://www.loc.gov/standards/mets/METSOverview.v2.html [14.02.2016].
116 Vgl. Arakaki, Felipe Augusto; Ventura, Plácida Leopoldina; Vesu Alves, Rachel Cristina: Evolution of Dublin Core Metadata Standard. An Analysis of the Literature from 1995-2013. In: Proceedings of the International Conference on Dublin Core and Metadata Applications, Sao Paulo 2015, S. 220-222, hier S. 220-221. URL: http://dcevents.dublincore.org/IntConf/dc-2015/paper/view/355/389 [14.02.2016].
117 Das Vokabular ist zu finden unter DCMI: DCMI Metadata Terms, o. O. 2012. URL: http://dublincore.org/documents/dcmi-terms/ [14.02.2016].
118 Siehe Term coverage. URL: http://dublincore.org/documents/dcmi-terms/#terms-coverage [14.02.2016].
119 Siehe Term temporal. URL: http://dublincore.org/documents/2012/06/14/dcmi-terms/?v=terms#terms-temporal [14.02.2016].
<dcterms:PeriodOfTime>120 mit einem Start- und Enddatum in einer kontrollierten
Darstellungsform (z. B. mit „scheme“=W3CDTF)121 ausdrücken.
Nicht nur Museen nutzen Dublin Core als Metadatenstandard zur Erschließung
digitaler und digitalisierter Ressourcen, auch Bibliotheken für all ihre Repositorien,122
wie z. B. die Deutsche Nationalbibliothek (DNB).123 Ein weiterer Grund Dublin Core
als Standard zu verwenden, ist die Tatsache, dass das Metadatenschema
international das meist genutzte ist, gefolgt von MARC 21, METS und MODS,124 und
dass das Schema auf die CIDOC CRM-Ontologie möglicherweise übertragbar ist. Es
gibt internationale Bestrebungen, Dublin Core und CIDOC CRM zu harmonisieren.125
Das eröffnet die Möglichkeit in späteren Projekten semantische Technologien für die
Verlinkung mit dem Semantic Web einzusetzen.
Auch die digiS Berlin legt Qualified Dublin Core innerhalb einer Abgabe-CSV-Datei
für die beschreibenden Metadaten fest. Diese können innerhalb von Archivematica
erkannt und extrahiert werden. Ebenso möglich ist eine Abgabe beschreibender
Metadaten in EAD für Archive, LIDO für Museen und MODS für Bibliotheken. Die
notwendigen Metadatenfelder werden automatisch extrahiert und in Dublin Core
transformiert.126 Des Weiteren überführt die digiS Berlin die administrativen zu
erhaltenden Metadaten der Submission manifest in Qualified Dublin Core:
120
Siehe Term PeriodOfTime. URL: http://dublincore.org/documents/2012/06/14/dcmi-terms/?v=terms#PeriodOfTime [14.02.2016].
121 Siehe Term W3CDTF. URL: http://dublincore.org/documents/2012/06/14/dcmi-terms/?v=terms#terms-W3CDTF [14.02.2016]; W3C: Date and Time Formats. URL: http://www.w3.org/TR/NOTE-datetime [14.02.2016].
122 Vgl. Fagundes de Brito, Ronnie; Macêdo, Diego José; Shintaku, Milton: Dublin Core Usage for Describing Documents in Brazilian Government Digital Libraries. In: Proceedings of the International Conference on Dublin Core and Metadata Applications, Sao Paulo 2015, S. 129-135, hier S. 132. URL: http://dcevents.dublincore.org/IntConf/dc-2015/paper/view/334/371 [14.02.2016].
124 Vgl. Andrade, Morgana; Baptista, Ana Alice: The Use of Application Profiles and Metadata Schemas by Digital Repositories. Findings from a Survey. In: Proceedings of the International Conference on Dublin Core and Metadata Applications, Sao Paulo 2015, S. 146-157, hier S. 146. URL: http://dcevents.dublincore.org/IntConf/dc-2015/paper/view/362/373 [14.02.2016].
125 Siehe Carrasco, Lais; Vidotti, Silvana: Dublin Core and CIDOC CRM Harmonization. In: Proceedings of the International Conference on Dublin Core and Metadata Applications, Sao Paulo 2015, S. 198-200. URL: http://dcevents.dublincore.org/IntConf/dc-2015/paper/view/341/380 [14.02.2016].
126 Vgl. Amrhein, Kilian; Klindt, Marco: One Core Preservation System for All your Data, S. 4. URL: https://opus4.kobv.de/opus4-zib/frontdoor/index/index/docId/5663 [14.02.2016].
Abbildung 35: Submission manifest und Mapping in Berlin127
Der Einsatz von Dublin Core-Elementen für beschreibende Metadaten im Pre-Ingest-
Bereich könnte die Interoperabilität mit der Archivlösung der digiS unterstützen, wenn
die SIP’s zur Langzeitarchivierung an die digiS geliefert werden sollen.
7.3.3 EAD
1993 begann an der University of California in Berkeley die Entwicklung der Encoded
Archival Description (EAD). Das Ziel war es, einen offenen Standard für Findmittel zu
erstellen, der von Archiven, Bibliotheken und Museen gleichermaßen verwendet
werden kann und zudem maschinell lesbar ist. Über das Internet sollten die
Erschließungsinformationen dabei noch verbreitet werden können. Technisch basiert
EAD auf der Standard General Markup Language (SGML), da diese die
Anforderungen zur Darstellung und Verknüpfung von hierarchischen Elementen
erfüllt. Die erste öffentliche, stabile EAD-DTD wurde im August 1998 vorgestellt und
enthielt bereits Elemente des SGML-Nachfolgers XML sowie weiterer, sich parallel
zu EAD entwickelnde Projekte, wie der bibliothekarischen Auszeichnungssprache
MARC und der International Standard Archival Description (ISAG (G)), dem Standard
zur hierarchischen Verzeichnung von Archivalien. Neben der EAD-DTD entstanden
als grundlegende Erläuterungen dazu die EAD Tag-Library sowie die EAD-
Applikation Guidelines, die unabdingbar für die Einführung von EAD in einer
Institution sind. Die Library of Congress hat einen aktiven Part an der
Weiterentwicklung dieses Standards, so u. a. an der Veröffentlichung eines XML-
Schemas und setzte sich zusammen mit dem amerikanischen Berufsverband der
127
Ebd., S. 6.
89
Archivare sehr für die Umsetzung von EAD in der Praxis ein. Daher ist er
international sehr verbreitet und wird als Standard angesehen.128
Grundsätzlich orientiert sich EAD an realen Findbüchern und bildet deren Struktur
nach. Das Grundkonzept des Standards ist die Stufenerschließung, was bedeutet,
dass die Verzeichnung auf verschiedenen Ebenen vorgenommen wird, vom
Gesamtbestand bis hinunter zum einzelnen Dokument und orientiert sich somit an
ISAD (G). Um den Anforderungen möglichst vieler unterschiedlicher Einrichtungen
weltweit zu genügen, erlaubt der Standard eine flexible Nutzung. Nur wenige
Elemente sind Pflichtangaben. Es bietet zur Beschreibung über 100
Metadatenelemente, wie Autor, Laufzeit und Sprache. Dazu kommen sogenannte
Attribute, mit denen die Elemente näher spezifiziert werden können. Prinzipiell
können damit in einer EAD-Datei ganze Archive abgebildet werden, jeweils mit
Informationen über das Archiv, seine Bestände, Sammlungen, Akten und
Dokumenten. Es ist auch möglich, ein eigenes institutionelles Profil von EAD zu
erstellen. Deutsche Archive nutzten diesen Vorteil, um ihre spezifische
Verzeichnungstradition besser in EAD abbilden zu können, da sich der Standard
prinzipiell an der anglo-amerikanischen Erschließung orientiert.129
7.3.4 XMP
Der offen entwickelte Standard von Adobe – Extensible Metadata Plattform (XMP)130
– ist ein Container-Format, welcher u. a. zum Ausdruck deskriptiver Metadaten das
Dublin Core-Schema nutzt. XMP-Daten können sowohl in TIFF-, JPEG2000- und
PDF-Dateien importiert werden, als auch in das Bilddatenformat für RAW-Bilddaten
DNG.131 Weiterhin ist in XMP die Integration von Photoshop-, TIFF- und EXIF-
Elementen möglich.
7.3.5 PREMIS
Mithilfe des von Archivematica genutzten PREMIS-Konzepts können
Langzeitarchivierungsmetadaten und im Speziellen technische Metadaten
128
Vgl. Development of the Encoded Archival Description DTD. URL: http://www.loc.gov/ead/eaddev.html [14.02.2016].
129 Vgl. Ebd.
130 Siehe Adobe Systems Incorporated: XMP Specification, San Jose 2005. URL: https://partners.adobe.com/public/developer/en/xmp/sdk/XMPspecification.pdf [14.02.2016].
131 Vgl. Enders, Markus: Kap. 17.3 Bilddokumente. In: Huth, Karsten; Neuroth, Heike; Oßwald, Achim et al. (Hrsg.): nestor Handbuch. Eine kleine Enzyklopädie der digitalen Langzeitarchivierung, Version 2.3, o. O. 2010, S. 14-15. URL: http://nestor.sub.uni-goettingen.de/handbuch/artikel/nestor_handbuch_artikel_422.pdf [14.02.2016].
nachvollziehbar dargestellt und gespeichert werden. Kompatibel mit dem METS-
Standard,132 der genutzt wird, um das Interagieren der OAIS-Informationspakete SIP,
AIP und DIP innerhalb des Archivs oder den Austausch von Daten zwischen
Archiven zu ermöglichen,133 bietet das PREMIS-Datenmodell mit seinen
verknüpfbaren semantischen Einheiten (Objekt, Ereignisse, Agenten, Rechte) über
Identifier die Möglichkeit, Archivierungsprozesse standardisiert auszudrücken und so
Veränderungen am Objekt oder Maßnahmen nachvollziehbar zu machen. Darüber
hinaus kann das digitale Objekt auf verschiedenen Ebenen (Repräsentation, Datei
und Bitstream) abgebildet werden, sodass die Erhaltung des Objekts auf den
unterschiedlichen Ebenen realisiert und dargestellt werden kann.134
Abbildung 36: Überblick über das PREMIS-Datenmodell135
Das Datenmodell wurde in der Version 3.0 um die Repräsentationsinformation des
Objekts nach dem OAIS-Modell mit der Entität „Environment“136 ergänzt, wodurch
132
Siehe Digital Library Federation: <METS>. Metadata Encoding and Transmission Standard. Primer and Reference Manual, download METS-Primer-Datei unter: URL: http://www.loc.gov/standards/mets/mets-schemadocs.html [14.02.2016].
134 Vgl. Keitel, Christian: Der nestor-Leitfaden zur Digitalen Bestandserhaltung und seine Folgen für die Archive. In: Keitel, Christian; Naumann, Kai (Hrsg.): Digitale Archivierung in der Praxis. 16. Tagung des Arbeitskreises „Archivierung von Unterlagen aus digitalen Systemen“ und nestor-Workshop „Koordinierungsstellen“, Stuttgart 2013 (=Werkhefte der staatlichen Archivverwaltung Baden-Württemberg, Serie A, Heft 24), S. 267-268.
135 PREMIS Editorial Committee: PREMIS Data Dictionary for Preservation Metadata, Version 3.0, o. O. 2015, S. 6. URL: http://www.loc.gov/standards/premis/v3/premis-3-0-final.pdf [14.02.2016].
nun die Verknüpfung der Umgebung des Objekts mit Agenten, deren Rechten und
durchgeführten Ereignissen (z. B. Ingest oder Migration) unmittelbar gegeben ist und
ein Bezug zu allen Ebenen des Objekts hergestellt werden kann. Bereits auf der
iPRES 2012 stellte Angela Dappert (Digital Preservation Coalition) ein spezifisches
OAIS-konformes Modell zur Beschreibung von Objektumgebungen mit PREMIS
vor.137
Das 2005 erstmals veröffentlichte Data Dictionary138 von PREMIS definiert ein
Kernset an Metadaten, die sich auf die semantischen Einheiten beziehen und sich
aus einer Teilmenge der gesamten Langzeitarchivierungsmetadaten
zusammensetzen:
Abbildung 37: PREMIS-Metadaten als Teilmenge von Langzeitarchivierungsmetadaten139
Dazu gehören:
136
Unter „Environment“ ist die Hard- und Software zu verstehen, welche die Lesbar- und Verstehbarkeit des digitalen Objektes gewährleistet und dokumentiert, in welcher Umgebung das digitale Objekt entstanden ist. Vgl. PREMIS Editorial Committee: PREMIS Data Dictionary for Preservation Metadata, Version 3.0, o. O. 2015, S. 7. URL: http://www.loc.gov/standards/premis/v3/premis-3-0-final.pdf [14.02.2016].
137 Siehe Chou, Carol C. H.; Dappert, Angela; Delve, Janet et al.: Describing Digital Object Environments in PREMIS. In: iPRES 2012. Proceedings of the 9th International Conference on Preservation of Digital Objects, Toronto 2012, S. 69-76. URL: https://ipres.ischool.utoronto.ca/sites/ipres.ischool.utoronto.ca/files/iPres%202012%20Conference%20Proceedings%20Final.pdf [14.02.2016].
138 Mittlerweile ist Version 3.0 verfügbar. Siehe PREMIS Editorial Committee: PREMIS Data Dictionary for Preservation Metadata, Version 3.0, o. O. 2015. URL: http://www.loc.gov/standards/premis/v3/premis-3-0-final.pdf [14.02.2016].
139 Caplan, Priscilla: PREMIS verstehen, aus dem Engl. von Tobias Beinert, Washington 2009 [2009], S. 5. URL: http://www.loc.gov/standards/premis/understanding_premis_german.pdf [14.02.2016].
Formatspezifische Metadaten, d.h. Metadaten, die nur ein einziges
Dateiformat oder eine Klasse von Formaten, wie Audio, Video oder
Vektorgraphiken betreffen.
Metadaten, die anwendungs- oder geschäftsablaufspezifisch sind, d.h.
Metadaten, die die Policy oder Praxis eines individuellen Archivs beschreiben,
z. B. in Bezug auf die Zugänglichmachung von digitalen Materialien.
Deskriptive Metadaten. Obwohl die inhaltliche Beschreibung von Ressourcen
natürlich auch aus Sicht der Langzeitarchivierung durchaus relevant ist, gibt
es bereits eine Vielzahl an unabhängigen Standards wie MARC21, MODS und
Dublin Core, die zu diesem Zweck eingesetzt werden können.
Detaillierte Informationen über Speichermedien oder Hardware.
Informationen über Agenten (Personen, Organisationen oder Software), die
über das zur Identifizierung notwendige Minimum hinausgehen.
Informationen über Rechte und Genehmigungen, bis auf jene die sich
unmittelbar auf die Langzeitarchivierung auswirken.140
7.3.6 Erweiternde Schemata
Was PREMIS nicht abdeckt, sind Metadaten zur Wiederauffindbarkeit und zum
Zugang sowie detaillierte formatspezifische Metadaten,141 was es notwendig macht,
auf spezifische Beschreibungsstandards für technische Metadaten und Tools zur
Generierung von weiteren technischen Metadaten zurückzugreifen. Verwiesen sei
auf die von der Library of Congress initiierten standardisierten Schemata zur
Beschreibung detaillierter technischer Metadaten von Text- (TextMD),142 Bild-
(MIX),143 Audio- (AudioMD) und Videoobjekten (VideoMD).144 Die
Beschreibungselemente von TextMD, AudioMD und VideoMD lassen sich erweiternd
in METS oder PREMIS integrieren, in METS direkt unter der administrativen
Metadaten-Sektion und in PREMIS unter dem Element
<objectCharacteristicsExtension>. Sie können aber auch für sich stehen, als
eingebettete Metadaten in „Material eXchange Format (MXF) files“. Die Standards
140
Ebd., S. 4-5. 141
Vgl. Caplan, Priscilla: PREMIS verstehen S. 5. URL: http://www.loc.gov/standards/premis/understanding_premis_german.pdf [14.02.2016].
142 Vgl. The Library of Congress: textMD. Technical Metadata for Text. URL: https://www.loc.gov/standards/textMD/ [14.02.2016].
143 Vgl. The Library of Congress: MIX. NISO Metadata for Images in XML Schema. URL: http://www.loc.gov/standards/mix// [14.02.2016].
144 Vgl. The Library of Congress: AudioMD and VideoMD. Technical Metadata for Audio and Video. URL: https://www.loc.gov/standards/amdvmd/index.html [14.02.2016].
enthalten speziellere Metadaten, z. B. bei Audiodateien das Trackformat, die
Geschwindigkeit und Frequenz der Aufnahme.145
Metadaten aus dem MIX-Standard können mittels JHOVE erzeugt werden. Der Mix-
Standard enthält u. a. umfangreiche Metadaten zur Farbgebung, zu den
Formatcharakteristiken, zur Bildaufnahme und den Geräten, mit denen sie erstellt
wurde (Herkunftsmetadaten). Des Weiteren lassen sich im Standard Metadaten zur
Veränderungshistorie finden.146 Für den Anwendungsfall kann der MIX-Standard eine
Orientierung bieten, besonders in Bezug auf die mitzuliefernden
Digitalisierungsmetadaten, die den Entstehungskontext und die Veränderungshistorie
des digitalen Objekts dokumentieren.
Das in Archivematica genutzte Tool FITS (File Information Tool Set) zur
Formatidentifikation unterstützt die Ausgabe der XML-Metadaten in Community-
Standard-XML-Schemata für technische Metadaten:
Für Audioobjekte: AES Audio Object147
Für Dokumente: DocumentMD148
Für Bildobjekte: MIX149
Für Textobjekte: TextMD150
Die Einbindung technischer Metadaten von Videos mithilfe von FITS ist derzeit noch
in Planung.151
7.3.7 Anwendung
Bei der Anwendung von PREMIS und METS ergeben sich mögliche Redundanzen in
der Beschreibung, wenn bspw. ein formatspezifisches Schema technischer
Metadaten (wie MIX für Bildobjekte) Datenelemente enthält, die nicht nur in METS,
145
Vgl. ebd. 146
Vgl. National Information Standard Organization: Data Dictionary. Technical Metadata for Digital Still Images, Bethesda 2006. URL: http://djvu.org/docs/Z39-87-2006.pdf [14.02.2016].
147 Der vollständige Name lautet AES standard for audio metadata – Audio object structures for preservation and restoration. Vgl. Audio Engineering Society: AES Standard. URL: http://www.aes.org/publications/standards/search.cfm?docID=84 [14.02.2016].
148 Vgl. Data Dictionary und Schema: Florida Virtual Campus/Harvard Library: Format-specific Metadata. URL: http://fclaweb.fcla.edu/content/format-specific-metadata [14.02.2016].
149 Vgl. The Library of Congress: MIX. NISO Metadata for Images in XML Schema. URL: http://www.loc.gov/standards/mix// [14.02.2016].
150 Vgl. The Library of Congress: textMD. Technical Metadata for Text. URL: https://www.loc.gov/standards/textMD/ [14.02.2016].
151 Vgl. FITS Projekthomepage: Standard metadata schemas. URL: http://projects.iq.harvard.edu/fits/standard-metadata-schemas [14.02.2016].
sondern auch in PREMIS vorkommen. Daher muss zwischen den Standards eine
Abgrenzung in der Beschreibung von Erhaltungsmetadaten erfolgen. Das erfordert
die Entwicklung eines konsistenten Metadatenschemas. Die Library of Congress
erstellte aus ihrer praktischen Erfahrung heraus 2008 dazu Guidelines152 und
publizierte über die Flexibilität und Interoperabilität von METS und PREMIS.153 Die
PREMIS in METS Toolbox (PIMTOOLS)154 wurde von dem Florida Center for Library
Automation entwickelt, um die Konformität eines METS-Dokuments mit eingebetteten
PREMIS-Metadaten auf die PREMIS und METS Guidelines hin festzustellen.155
Der MIX-Standard eignet sich neben der Beschreibung von technischen
Umgebungen und der Herkunft digitaler Objekte auch zur Darstellung signifikanter
Eigenschaften. Eine Studie156 aus dem InSPECT-Projekt157 beschäftigte sich mit der
Bestimmung der signifikanten Eigenschaften von Rastergrafiken, die nicht den
„context“, sondern den auf das Objekt bezogenen „content“ betreffen, anhand der
Metadaten von MIX. Ermittelt wurden folgende, minimale signifikante Eigenschaften
für den Objekttyp:
Image width / image height: Breite und Höhe des Bildes
XResolution / YResolution: Auflösung des Bildes auf der X- und Y-Achse
Bits per sample: Bits pro Farbkomponente
Samples per pixel: Anzahl der Farbkomponenten pro Pixel158
Die Angaben zur Breite und Höhe des Bildes aus dem Bereich „Basic Image
Information“ werden benötigt, um das Bildobjekt als wiedergabefähiges und lesbares
152
Vgl. Library of Congress: Guidelines for using PREMIS with METS for exchange, Washington 2008. URL: http://www.loc.gov/standards/premis/guidelines-premismets.pdf [14.02.2016]; Vermaaten, Sally: A Checklist for Documenting PREMIS-METS Decisions in a METS Profile, o. O. 2010. URL: http://www.loc.gov/standards/premis/premis_mets_checklist.pdf [14.02.2016].
153 Vgl. Guenther, Rebecca: Battle of the Buzzwords. Flexibility vs. Interoperability When Implementing PREMIS in METS. In: D-Lib Magazine 14 (2008) 7/8. URL: http://www.dlib.org/dlib/july08/guenther/07guenther.html [14.02.2016].
154 Vgl. PIMTOOLS: PREMIS in METS Toolbox. URL: http://pim.fcla.edu/ [14.02.2016].
156 Vgl. Montague, Lynn: Significant Properties Testing Report. Raster Images, o. O. 2010. URL: http://www.significantproperties.org.uk/rasterimages-testingreport.pdf [14.02.2016].
157 InSPECT bedeutet Investigating the Significant Properties of Electronic Content Over Time und ist ein von der JISC gefördertes Projekt des Kings’s College London in Zusammenarbeit mit The National Archives. Vgl. InSPECT Projekthomepage. URL: http://www.significantproperties.org.uk/index.html [14.02.2016].
158 Vgl. Engels, Melanie: Vorbereitungen zur Langzeitarchivierung einer Fotokollektion. In: Meinhardt, Haike; Oßwald, Achim; Rösch, Hermann et al. (Hrsg.): MALIS-Praxisprojekte 2013. Projektberichte aus dem berufsbegleitenden Masterstudiengang Bibliotheks- und Informationswissenschaft der Fachhochschule Köln, Wiesbaden 2013 (=b.i.t.online – Innovativ Bd. 44), S. 25. URL: https://www.fbi.fh-koeln.de/institut/papers/malisbuch_2013/1_Engels.pdf [14.02.2016].
160 Vgl. Engels, Melanie: Vorbereitungen zur Langzeitarchivierung einer Fotokollektion, S. 17-34. URL: https://www.fbi.fh-koeln.de/institut/papers/malisbuch_2013/1_Engels.pdf [14.02.2016].
Metadaten der publizierten Schriftzeugnisse auf der Plattform www.museum-
digital.de und anhand der Metadaten aus dem herausgegebenen Verzeichnis des
Brandenburgischen Landeshauptarchivs.163 Eingeteilt nach Sammlungstypen (z. B.
Notizbücher, Tagebücher, Briefe, Hofbriefe, Rezepte und Magie, Sprüche und
Lieder) ließen sich folgende Metadaten zum Objekt finden:
Titel
Signatur
Beschreibung
Material/Technik
Maße
Wer, wann und wo das Schriftstück verfasst hat
Wer, wann und wo das Schriftstück abgeschickt hat
Wer, wann und wo das Schriftstück abgeschrieben hat Die Information bezieht sich auf das Transkript
Teil von-Angabe (z. B. ein Teil von einem Hauptwerk oder einer Sammlung)
Tags
Weitere zugrundeliegende Metadaten beschreiben die Herkunft und Rechte des zur
Verfügung gestellten Digitalisats:
Name und Ort der Einrichtung, die das Digitalisat zur Verfugung stellt
Angaben zu Nutzungsrechten, unter welcher Lizenz die Nutzung gewährt wird
Die heterogenen Inhalte und Erschließungsweisen unter den Metadaten-Elementen
in www.museum-digital.de164 lassen auch darauf schließen, dass die beschreibenden
Metadaten zu den Popularen Schriftzeugnissen in den verschiedenen Einrichtungen
(Archiven, Bibliotheken und Museen) in verschiedenen Standards vorliegen. Das liegt
natürlich ebenfalls daran, dass die Einrichtungen für die Erschließung ihrer Objekte
163
Edelberg, Ingrid; Siedt, Veronika (Bearb.): Populare Schriftzeugnisse in Brandenburg. Beschreibendes Verzeichnis von Selbstzeugnissen und verwandten Quellen (17.-19. Jahrhundert), hrsg. von Klaus Neitmann, Potsdam 2004 (=Einzelveröffentlichung des Brandenburgischen Landeshauptarchivs).
164 Das Domstiftsarchiv Brandenburg/Havel führt bspw. unter dem Metadatum „Beschreibung“ nur einen Titel und Enthält-Vermerk im Nominalstil auf, während das Prignitz-Museum am Dom Havelberg eine sehr ausführliche Beschreibung über das Schriftzeugnis liefert, die genau den Inhalt des Schriftzeugnisses, die Lebensumstände des Verfassers und die historischen Ereignisse dieser Zeit wiedergibt. Vgl. Tagebuch der Ingeborg Viereck. URL: http://www.museum-digital.de/brandenburg/index.php?t=objekt&oges=3155&them=1&m_tid=488&tid=491&ver=nat&mtt=Populare%20Schriftzeugnisse [14.02.2016] sowie Kriegstagebuch des Leutnants Wilhelm Stämmler 1813/1814. URL: http://www.museum-digital.de/san/index.php?t=objekt&oges=39983&them=1&m_tid=488&tid=491&ver=nat&mtt=Populare%20Schriftzeugnisse [14.02.2016].
unterschiedliche Software mit unterschiedlichen Erschließungsmasken verwenden
und die Metadaten entsprechend nur in bestimmten Formaten exportiert werden
können. Während Archive vornehmlich den Standard EAD zur Beschreibung ihrer
Archivalien nutzen, nehmen Bibliotheken MARC, Museen verwenden zumeist den
Standard LIDO oder DC um ihre Objekte zu verzeichnen und zu beschreiben.
7.4.2 Beschreibende und strukturelle Metadaten
Einige beschreibende Metadaten werden benötigt, um die Objekte im Archivsystem
zu identifizieren und wiederaufzufinden. Zusätzliche Metadaten bieten nur einen
Mehrwert, wenn sie für den Endnutzer eine Bedeutung besitzen. Da eine direkte
Nutzung durch Endnutzer nicht vorgesehen ist bzw. im Handlungsrahmen der
Koordinierungsstelle Brandenburg-digital und der digiS Berlin nur die Rückgabe von
Kopien der AIP‘s samt der Metadaten zur Langzeitarchivierung an die Einrichtungen
erfolgen soll, wird der Access-Bereich nach dem OAIS-Modell bei der Auswahl der zu
übernehmenden beschreibenden Metadaten außer Betracht gelassen.165 Die
vertrauenswürdige, digitale Langzeitarchivierung nach DIN 31644 ist damit gegeben,
wenn Umfang, Struktur und Inhalt der beschreibenden Metadaten in Abhängigkeit
von den Zielen des digitalen Langzeitarchivs bzw. Handlungsrahmens
(Koordinierungsstelle Brandenburg-digital und digiS Berlin), von den Zielgruppen des
digitalen Langzeitarchivs (abgebende Einrichtungen) und den Objekttypen (Populare
Schriftzeugnisse) definiert wurden.166
Zur Identifizierung von Informationsobjekten, ihren Repräsentationen und deren
Teilen verwendet Archivematica als Kennungen UUID’s. Ein vertrauenswurdiges
Archiv bildet das dauerhafte Verhältnis von Informationsobjekten, Repräsentationen
und Teilen mit eindeutigen Kennungen ab und hält es transparent, in dem die
inneren Strukturen der zu archivierenden Objekte nachvollziehbar konserviert
werden.167 Bei der UUID – Universal Unique Identifier – handelt es sich um einen
Namensraum des Uniform Resource Name (URN), welcher digitale Objekte eindeutig
identifiziert. URN ist eine Art des URI – Uniform Resource Identifier – und ein DOI –
Digital Object Identifier – kann ein registrierter URI mit UUID sein. DOI‘s werden
165
Wobei der Access in Berlin naturlich zur Ruckgabe des AIP’s, aber ausschließlich nur dazu, benötigt wird – ohne Anforderungen in Bezug auf etwaige Nutzergruppen zu erfüllen, da die Kultureinrichtungen dafür die Verantwortung übernehmen.
166 Vgl. Keitel, Christian; Schoger, Astrid (Hrsg.): Vertrauenswürdige digitale Langzeitarchivierung nach DIN 31644, S. 66.
167 Vgl. ebd., S. 65-66.
98
sowohl zur Identifikation von analogen, als auch von digitalen oder abstrakten
Objekten genutzt. DOI ist ein internationaler Standard (ISO 26324). Er spezifiziert die
Syntax, Beschreibung und Lösung funktioneller Komponenten eines digitalen Objekt-
Identifier-Systems. Die Vergabe von DOI’s erfolgt durch die International DOI
Foundation (IDF).168
Daher ist die eindeutige Kennzeichnung und Zuordnung von Informationsobjekten zu
den Repräsentationen und Inhalten uber die Vergabe von UUID’s in Archivematica
gegeben. Die Zuordnungen der Objekte und Repräsentationen im Pre-Ingest soll
durch entsprechende Benennungen der Einzeldateien bzw. Ordner gewährleistet
werden, welche in den nächsten Kapiteln erläutert werden. Diese beschreibenden
Metadaten geben gleichzeitig Aufschluss über die Struktur der Informationsobjekte
und sind somit auch gleichzeitig als strukturelle Metadaten anzusehen.
Als Standard für die Übernahme von beschreibenden Metadaten und den Austausch
soll das Containerformat METS genutzt werden, welches neben dem CSV-Format169
in die Archivematica-Lösung eingespeist werden kann. Ein erfolgreich durchgeführter
Import-Test stellt dies unter Beweis.170 Die digiS Berlin nutzt derzeit noch CSV als
Import-Dateiformat,171 arbeitet aber an einer Lösung, eine METS-Datei
einzuspeisen.172
Die Übernahme beschreibender Metadaten per <mdWrap> unter der <dmdSec>
einer METS-Datei gestaltet sich aufgrund der generischen, redundanten und
unstrukturierten Darstellung im Archivematica-System schwierig (vgl. Kapitel 4.7
Testdurchläufe). Daher wird die Einbindung beschreibender Metadaten per
<mdRef>-Verweis unter der <dmdSec> auf eine mitzuliefernde, externe
Metadatendatei der integrationsfähigen Formate in METS (MARC, MODS, EAD,
VRA, DC, NISOIMG, LC-AV, TEIHDR, DDI, FGDC) festgelegt. Die externe
Metadatendatei soll unter der Bezeichnung z. B. „ead.xml“ im TIP unter dem Ordner
168
Vgl. Thaller, Manfred (Hrsg.): Das Digitale Archiv NRW in der Praxis. Eine Softwarelösung zur digitalen Langzeitarchivierung, Hamburg 2013, S. 47-48; Gladney, Henry M.: Preserving Digital Information, Berlin 2007, S. 121; Harvey, Ross: Preserving Digital Materials, S. 87; DOI Handbook. URL: https://www.doi.org/doi_handbook/1_Introduction.html [14.02.2016].
170 Nach Aussage von Lennart Metken, technischer Unterstützer des Projekts.
171 Vgl. Amrhein, Kilian; Klindt, Marco: One Core Preservation System for All your Data, S. 4. URL: https://opus4.kobv.de/opus4-zib/frontdoor/index/index/docId/5663 [14.02.2016].
172 Nach Aussage von Marco Klindt beim Treffen am Konrad-Zuse-Institut am 11.12.2015.
/logs mitgeliefert werden, da die Datei nach einem Test in dieser Ablageform beim
Durchlauf durch Archivematica nicht in ablaufende Prozesse einbezogen und damit
nicht generisch in die Gesamt-METS-Datei implementiert wird, als wenn die Datei
sich unter /objects oder /metadata befindet. So können die
Erschließungsinformationen OAIS-konform in die Archivlösung übernommen,
langzeitarchiviert und zurückgegeben werden, ohne die Validität der METS-Datei zu
verletzen. Nach dem OAIS-Modell müssen Erschließungsinformationen sowohl in der
Datenverwaltung als auch im AIP im Archivspeicher vorhanden sein. Sie werden aus
dem SIP extrahiert und in die Datenverwaltung übernommen, verbleiben jedoch
gleichzeitig im AIP. Extrahieren bedeutet hier nicht aus dem SIP entfernen.173 Im Pre-
Ingest in Berlin werden sowohl die Ordnerstruktur als auch die Mitlieferung von PDI
und DI mit Compliance Tests kontrolliert, im Ingest extrahiert und konform in die
Berliner Datenverwaltung übernommen (vgl. Kapitel 5.3).
Einrichtungen, die keine Möglichkeit besitzen, beschreibende Metadaten konform in
METS einzubinden, weil sie bspw. ihre Metadaten nur in Tabellenform (Word- oder
Excel-Datei) vorliegen haben, sollen zur Objektidentifikation und Wiederauffindbarkeit
mindestens einen Kernmetadatensatz (Titel, Signatur, Laufzeit) als externe
Metadatendatei in EAD mitliefern. Zu empfehlen wäre zur Konvertierung von Excel-
Dateien nach EAD eine online verfügbare, englischsprachige Anleitung zu nutzen,
worauf die Koordinierungsstelle Brandenburg-digital den Hinweis geben könnte.174
Die Einrichtungen sollen sich per Übernahmevereinbarung verpflichten, eine externe
METS-Datei sowohl mit den inhaltlich, beschreibenden Metadaten unter /logs im TIP
mitzuliefern, als auch mit administrativen, die METS-Datei und den Prozess
beschreibenden Metadaten, sowie mit der Fixity information (vgl. Kapitel 6.6). Ein
entsprechendes Open-Source-Tool zur Erstellung einer METS-Datei stellt der METS-
Editor dar, aber besser noch der Docuteam Packer in Kombination mit dem SIP-
Creator (vgl. Kapitel 6.7).
173
Vgl. nestor-Arbeitsgruppe OAIS-Übersetzung/Terminologie: Referenzmodell für ein Offenes Archiv-Informations-System. Deutsche Übersetzung 2.0, hrsg. von nestor – Kompetenznetzwerk Langzeitarchivierung, Frankfurt am Main 2013 (=nestor-materialien 16), S. 33, 39, URL: http://files.dnb.de/nestor/materialien/nestor_mat_16-2.pdf [14.02.2016].
174 Siehe Mengel, Holly: Excel to EAD-XML to AT. The spreadsheet from heaven, o. O. 2012. URL: http://clir.pacscl.org/2012/03/19/excel-to-xml-the-spreadsheet-from-heaven/ [14.02.2016]; Mengel, Holly: Spreadsheet to XML. Using the PACSCL Finding Aids Spreadsheet, o. O. 2012, Guide. URL: http://clir.pacscl.org/wp-content/uploads/2009/07/PACSCL-Finding-Aids-Spreadsheet-Guide.pdf [14.02.2016].
Zur Identifizierung der gelieferten Daten und Ansprechpartner legt die digiS –
unabhängig von den notwendigen Beschreibungen in den Metadaten des
Transferpakets – per Übernahmevereinbarung das Mitführen von Metadaten, die
eine Lieferung beschreiben, fest. Die Metadaten werden in einer „submission-
manifest.txt“ bereitgestellt. Es handelt sich um folgende:
Abbildung 38: Textdatei Submission Manifest der digiS
Zur Übergabe von Digitalisaten an die Koordinierungsstelle Brandenburg-digital soll
daher in Anpassung an die digiS und der Überfuhrung dahin diese „submission-
manifest.txt“ im Unterordner /submissionDocumentation des Ordners /metadata im
TIP mitgeliefert werden.
7.4.3 Eingebettete Metadaten in Digitalisaten
Jede Datei besitzt aufgrund ihrer Existenz technische Metadaten, die den Zweck
erfüllen, die Authentizität einer Bilddatei zu bewerten. Checksummen und
Größeninformationen geben bspw. Auskunft über Modifikationen an einer Bilddatei
101
im digitalen Archiv. Gescannte Bilder enthalten neben den Basismetadaten wie
Breite und Höhe einige eingebettete technische Metadaten sowie reduzierte
administrative Metadaten, welche bspw. die Bearbeitungshistorie mit Programmen
dokumentieren. Darüber hinaus beschreiben deskriptive Metadaten in
Bilddokumenten etwa mit einer Titelinformation und Seitenzahl den
Archivierungsgegenstand, also den Kontext eines Bilddokuments, welcher den Inhalt
des Bilddokuments zu- und einordnet. Eine digitalisierte Buchseite ist bspw. ohne
den Kontext des Buches als Archivierungsgegenstand nicht einzuordnen. Die
deskriptiven Metadaten in der Bilddatei erhalten die Möglichkeit im Fall, dass auf
Erschließungsinformationen nicht zugegriffen werden kann, wenn bspw. das System
nicht mehr funktioniert, den Kontext im Groben wiederherzustellen. Für die Abbildung
deskriptiver Metadaten bietet jedes Datenformat eigene proprietäre Lösungen. So
lassen sich die TIFF-Tags PAGENAME, DOCUMENTNAME und
IMAGEDESCRIPTION verwenden. Eine Alternative bietet die von Adobe entwickelte
Extensible Metadata Plattform (XMP),175 welche für deskriptive Metadaten das Dublin
Core Schema nutzt.
Die eingebetteten Metadaten in den TIFF-Dateien der Popularen Schriftzeugnisse
liegen im XMP-Format vor, in welchem sich auch Dublin Core-, Photoshop-, TIFF-
und EXIF-Elemente befinden. Nach dem Öffnen des Beispieldigitalisats “Friesacker
Liederbuch“ in Photoshop CC Version 2015 1.1 können die hinterlegten Metadaten
unter „Dateiinformationen“ im Reiter Datei angezeigt und nachvollzogen werden.
Verzeichnet sind deskriptive Metadaten:
175
Siehe Adobe Systems Incorporated: XMP Specification, San Jose 2005. URL: https://partners.adobe.com/public/developer/en/xmp/sdk/XMPspecification.pdf [14.02.2016].
7.4.5 Weitere administrative und beschreibende Metadaten zur
Prozessdokumentation und TIP-Beschreibung
Vor der Abgabe des TIP’s sollen von den Einrichtungen METS-Dateien erstellt
werden, z. B. mit dem METS-Editor oder dem docuteam packer. Zur Protokollierung
des Prozesses und Nachvollziehbarkeit, mit welcher Anwendung die METS-Datei
generiert wurde, sind von den Einrichtungen einige administrative Metadaten
hinzuzufügen, aber gleichzeitig auch beschreibende zur Identifikation und Herkunft
des Paketes (Paketbeschreibung und Verpackungsinformation).
Diese administrativen und beschreibenden Metadaten lassen sich mit dem METS-
Editor in den METS-Header der generierten Datei schreiben:
Abbildung 44: Beispiel einer erstellten Ausgangs-METS-Datei mit dem METS-Editor
Um den Erstellungsprozess, den Kontext und die Herkunft nachzuvollziehen, wird
festgelegt, dass die Einrichtungen ihr Abgabepaket im Projekt Populare
Schriftzeugnisse mit Metadaten anreichern sollen, welche im METS-Header
abzulegen sind:
Recordstatus: Ob das Paket abgeschlossen ist, ob es nur teilweise
abgeschlossen ist oder ob nur Metadaten aktualisiert wurden; Zeigt den
Erstellungsstatus auf
LASTMODDATE: Wann die METS zuletzt aktualisiert wurde
CREATEDATE: Erstellungsdatum der METS
ID: für die METS; kann im METS-Editor selber vergeben werden; bestehend
aus ISIL-Nummer der Einrichtung_Signatur des analogen Schriftzeugnisses
(=Pakettitel)
108
CREATOR: Typisierend: Name des Mitarbeiters der Organisation, der die
METS-Datei erstellt hat
CREATOR: Typisierend: Bezeichnung der Software, mit der die METS-Datei
erstellt wurde
Der Identifier setzt sich aus der Identifikationsnummer der Einrichtung (ISIL-Nummer)
und der Signatur des analogen Schriftzeugnisses, welche gleichzeitig die
Beschreibung des Transferpaketes bildet, zusammen. Bei der ISIL-Nummer178
handelt es sich um ein internationales Standardkennzeichen für Bibliotheken und
verwandte Einrichtungen (ISO 15511). Es ist nicht nur für Bibliotheken gedacht,
sondern auch für Archive, Museen und Agenturen, die mit Bibliotheken in
Geschäftsbeziehung stehen. Die internationale Betreuung der ISIL erfolgt durch die
ISIL Registration Authority in Kopenhagen. In Deutschland wird die ISIL seit 2004
von der Deutschen ISIL-Agentur in der Staatsbibliothek zu Berlin vergeben und in
einer ISIL-Datei179 verzeichnet.180
Nach der ISIL-Datei besitzen von den beteiligten Einrichtungen am
Digitalisierungsprojekt Populare Schriftzeugnisse 11 von 19 Einrichtungen bereits
eine ISIL-Nummer:
178
International Standard Identifier for Libraries and Related Organizations. 179
Siehe Staatsbibliothek zu Berlin: Deutsche ISIL-Agentur und Sigelstelle: Datenbank Bibliotheken, Archive, Museen und verwandte Einrichtungen. URL: http://sigel.staatsbibliothek-berlin.de/nc/suche/ [14.02.2016].
180 Vgl. Staatsbibliothek zu Berlin: ISIL. URL: http://sigel.staatsbibliothek-berlin.de/de/vergabe/isil/ [14.02.2016].
Abbildung 45: Übersicht der am Projekt beteiligten Einrichtungen mit einer ISIL-Nummer
Daraus geht hervor, dass es hauptsächlich die Archive sind, die noch keine ISIL
haben. Die Beantragung bei der Sigelstelle ist aber problemlos über ein Webformular
möglich.181 Die Verwendung der ISIL-Nummer eignet sich in diesem Projekt, da sie
international anerkannt ist und speziell bei Museen und Bibliotheken schon eine
breitere Verwendung findet. Zudem erfordert die Registrierung bei der Deutschen
Digitalen Bibliothek (DDB) einen ISIL, um Digitalisate und Metadaten den
181
Siehe Staatsbibliothek zu Berlin: Deutsche ISIL-Agentur und Sigelstelle: Beantragung eines neuen ISIL. URL: http://sigel.staatsbibliothek-berlin.de/beantragung/ [14.02.2016].
Autor: Ersteller des Digitalisats Digitalisierung,
Scanerstellung
Erstellungs- und Bearbeitungshistorie mit Digitalisierung,
182
Vgl. SLUB Dresden: Der Weg in die DDB. URL: http://www.slub-dresden.de/sammlungen/deutsche-fotothek/ddb-fachstelle-mediathek/der-weg-in-die-ddb/ [14.02.2016].
Metadaten aus „submission-manifest.txt“ Metadateneingabe
Vor- und Nachname der abgebenden Person
Bezeichnung des Transferpakets: ISIL_Signatur
Prüfsummen für digitale Objekte
Abgabedatum
Auszuführender Prozess: Transfer
TIP-Abgabe
Tabelle 6: Übersicht mitzuliefernder Metadaten im TIP bei Abgabe an die Koordinierungsstelle Brandenburg-digital
7.5 Übersicht der TIP-Bestandteile
Folgende Übersicht zeigt noch einmal die Bestandteile auf, welche in einem TIP von
den Einrichtungen mitgeliefert und abgegeben werden sollen:
112
Abbildung 46: TIP-Konzept
Demnach besteht das TIP aus einem ZIP-Ordner mit der Benennung
„ISIL_Signatur.zip“ und bildet im Gesamten mit den Primärobjekten, den
dazugehörigen Metadaten und Protokolldateien die digitale Intellektuelle Entität.
Unter dem TIP-Ordner befindet sich die durch Archivematica zur Einspeisung
vorgegebene Ordnerstruktur mit den Unterordnern /objects, /metadata und /logs.
Unter /objects sind die einzelnen Primärdateien, also Repräsentationen, abzulegen.
Die Benennung folgt der des ZIP-Ordners, ergänzt um die laufende Nummer, die die
Reihenfolge der Repräsentationen, wie sie in der Intellektuellen Entität dargestellt
sind, wiederspiegelt. Eingebettet in den Primärdateien befinden sich die
Kameradaten, welche die Entstehungsumgebung dokumentieren, sowie die
signifikanten Eigenschaften für Rastergrafiken, welche dem Repräsentationsobjekt
Form verleihen und die Ausgangszustand beschreiben. Weiterhin enthalten die
Primärdateien Personen-, Software-, Hardware- und Prozessdaten in XMP, welche
die Erstellungs- und Bearbeitungshistorie (z. B. in Photoshop) darstellen.
113
Unter /metadata befindet sich die Metadatendatei „mets.xml“. Sie enthält das
Protokoll der Erstellung der METS-Datei, den Verweis per <mdRef> auf die externe
Metadatendatei (z. B. ead.xml) mit beschreibenden Metadaten sowie die
Dokumentation der durchgeführten Prozesse der Aufbereitung zum TIP mit dem
docuteam packer und SIP-Creator, darunter u. a. die Vergabe von Checksummen für
alle Repräsentationsobjekte. Diese Metadaten sind der Administrative Description
Information zuzuordnen, welche auch in Berlin der Beschreibung ablaufender
Prozesse dienen (vgl. Kapitel 5.2 Abb. 25). Es handelt sich um einen eigens
definierten Begriff in Berlin, der im OAIS-Informationsmodell nicht vorkommt, aber
der Preservation Description Information untergeordnet werden kann.
Unter /logs befindet sich die XML-Datei mit den beschreibenden Metadaten, auf die
in der Gesamt-METS-Datei „mets.xml“ verwiesen wird, sowie eine „submission-
manifest.txt“-Datei, welche die Vertragsdaten, Ansprechpartner, Paketbeschreibung
und Rechteinformationen enthält, und zwar zur Identifikation und Paketzuordnung
mitgeliefert, jedoch zum Management der Prozesse innerhalb der
Langzeitarchivlösung nicht weiter genutzt werden.
7.6 Abdeckung der Metadaten nach dem OAIS-Informationsmodell
Während im AIP die Content Information mit allen Arten von Preservation Description
Information sowie die Paketinformationen vorhanden sein müssen, ist das im SIP
bzw. TIP noch nicht zwangsläufig notwendig und Verhandlungssache zwischen
Archiv und Produzent.183 Jedoch sollte im Blick behalten werden, welche Metadaten
genau im Pre-Ingest den vergangenen und gegenwärtigen Zustand der Content
Information beschreiben, um deren eindeutige Identifizierung im Archiv zu
gewährleisten und sicherzustellen, dass sie nicht unwissentlich verändert wurde
sowie langfristig aussagekräftig und interpretierbar erhalten bleibt. Das unterstützt die
Vertrauenswürdigkeit nach der DIN 31644.184
183
Vgl. nestor-Arbeitsgruppe OAIS-Übersetzung/Terminologie: Referenzmodell für ein Offenes Archiv-Informations-System, S. 65-67. URL: http://files.dnb.de/nestor/materialien/nestor_mat_16-2.pdf [14.02.2016].
184 Siehe nestor-Arbeitsgruppe Vertrauenswürdige Archive – Zertifizierung (Hrsg.): nestor-Kriterien. Kriterienkatalog vertrauenswürdige digitale Langzeitarchive, Version 2, Frankfurt am Main 2008 (=nestor-materialien 8). URL: http://files.dnb.de/nestor/materialien/nestor_mat_08.pdf [14.02.2016].
Die enthaltenen Elemente im TIP lassen sich den Bestandteilen eines
Informationspakets, eines AIP’s, nach dem OAIS-Informationsmodell zuordnen.
Abbildung 47: Zuordnung der "ead.xml"-Datei
Demnach entspricht die „ead.xml“-Datei mit den beschreibenden Metadaten der
Descriptive Information, welche abgeleitet von der Content Information und der
Preservation Description Information im OAIS als Index angesehen werden, der über
Zugriffshilfen (Dokumente oder Programme) den effizienten Zugriff für Endnutzer auf
die gewünschte Information erlaubt.185 Für die Verwaltung der Informationsobjekte im
Langzeitarchiv sind diese Informationen unerheblich, da sie mehr der inhaltlichen
Suche dienen und weniger der Identifikation und Auffindbarkeit im Langzeitarchiv,
was durch eindeutige Identifikatoren für das TIP und die Repräsentationen
gewährleistet wird:
185
Vgl. nestor-Arbeitsgruppe OAIS-Übersetzung/Terminologie: Referenzmodell für ein Offenes Archiv-Informations-System, S. 63. URL: http://files.dnb.de/nestor/materialien/nestor_mat_16-2.pdf [14.02.2016].
Abbildung 48: ID's im Anwendungsfall und deren Zuordnung zu OAIS-Informationsbestandteilen
Die ID’s der TIP’s und Repräsentationsdateien finden sich in der Benennung der TIP-
Ordner und der Repräsentationsdateien wieder. Sie entsprechen der Reference
Information aus der Preservation Description Information. Die ID des TIP’s setzt sich
aus verschiedenen Kennungen zusammen (ISIL-Nummer der Einrichtung und
Signatur des analogen Schriftzeugnisses). Die ISIL-Nummer zeigt die Provenance
Information auf, die eindeutige Herkunft und Zugehörigkeit des Pakets zur
Einrichtung. Die Signatur ordnet das Digitalisat eindeutig dem verzeichneten
Schriftzeugnis in der Einrichtung zu und ist daher ebenfalls als Provenance
Information anzusehen.186 Die ID der Repräsentation besteht erweiternd aus einer
laufenden Nummerierung, welche die ursprüngliche Anordnung der
Repräsentationen im Schriftzeugnis aufzeigt und als strukturelles Metadatum der
Reference Information betrachtet werden kann, mithilfe dessen das Digitalisat in der
originalen Anordnung nachvollzogen und originalgetreu (authentisch) wiedergegeben
werden kann.
Weiterhin kann die Benennung des TIP auch als Packaging Information angesehen
werden, indem sie die Elemente des Transferpakets (Content Information und
Preservation Description Information) tatsächlich oder logisch in einer
identifizierbaren Einheit zusammenhält. Sie begrenzt auch das Informationsobjekt als
Struktur auf einem Datenträger oder virtuell im Archivspeicher. Jedoch entscheidend
186
Da die ID der Repräsentation Teil der ID des TIP’s ist, enthält die ID der Repräsentation auch per Vererbungsprinzip die Provenance Information. Daher wurde in der Abb. von der Repräsentationsbenennung nicht noch einmal eine Referenz zur Provenance Information gesetzt.
116
ist die Tatsache, dass es sich um eine ZIP-Datei handelt, was darauf schließen lässt,
dass speziellere Details und Informationselemente enthalten sind.187
Zusätzlich zur Paket- und Dateibenennung lässt sich das TIP mittels der
Sie entspricht im weitesten Sinne der Packaging Information, die das TIP begrenzt,
weil sie ergänzend mit Referenz-, Provenienz- und Rechteinformation das TIP als
logische Einheit beschreibt. Im Grunde lässt sich die Submission Manifest zur
Preservation Description Information insgesamt zuordnen, allerdings nicht auf Ebene
der Content Information – wie im OAIS-Modell –, sondern auf Ebene des Transfer
Information Package als vertraglich, festgelegte Übernahmeeinheit. Da die
Submission Manifest den Gegenstand der Übernahme beschreibt und in Berlin nicht
weiter zum Management im Langzeitarchiv genutzt wird, kann sie als mitzulieferndes
Beweis- und Zuordnungsdokument in der Paketverpackung als Packaging
Information gelten. Nicht zuzuordnen ist sie der Package Description, obwohl sie das
Paket inhaltlich umreißt. Denn die Submission Manifest dient als Begleitbeschreibung
nicht der Zugriffshilfe für den Endnutzer über Findmittel-, Bestell- und
Bereitstellungssysteme, wie im OAIS-Modell definiert, sondern lediglich der
vertraglichen Manifestation. Sie enthält ebenfalls die Access Rights Information
187
Vgl. nestor-Arbeitsgruppe OAIS-Übersetzung/Terminologie: Referenzmodell für ein Offenes Archiv-Informations-System, S. 63. URL: http://files.dnb.de/nestor/materialien/nestor_mat_16-2.pdf [14.02.2016].
übergreifend für alle enthaltenen Primärobjekte, sodass auf weitere, verpflichtende
Angaben in den beschreibenden Metadaten der externen XML-Datei hierzu
verzichtet werden kann, ebenso bei der Erstellung der METS-Datei mit dem METS-
Editor oder docuteam Packer. In der METS-Datei befinden sich Administrative
Description Information188, welche sich OAIS-Bestandteilen folgendermaßen
zuordnen lassen:
Abbildung 50: Bestandteile der "mets.xml"-Datei
Unter Administrative Description Information sind Metadaten zu verstehen, die die
Prozesse der Erstellung und weiteren Verarbeitung der Content Information und
Preservation Description Information protokollieren – die Erstellungs- und
Bearbeitungshistorie –, um die Authentizität des Informationsobjekts zu unterstützen.
Dazu gehört es, zu jedem Prozess die Personen-, Software-, Hardware- und
Prozessdaten erhaltend – entweder im Objekt selbst eingebettet in den Kameradaten
188
Der Begriff wird in Anpassung an den der digiS verwendet, vgl. Kapitel 5.2. Er ist nicht Bestandteil des OAIS-Informationsmodells.
118
oder in der erstellten METS-Datei zur Abgabe. Diese Metadaten bilden die Reference
Information,189 Provenance Information und Context Information des OAIS-Modells
ab. Auch der Erstellungsprozess der METS-Datei muss dokumentiert werden. Die
METS-Datei ist – genau wie alle anderen dokumentierten Prozesse – ebenfalls mit
einer ID (Reference Information) versehen, denn auch die Prozess- und
beschreibenden Metadaten besitzen eine Relevanz zur Erhaltung der Content
Information, weswegen die Metadatendateien auch erhaltenswert sind. Die National
Science Foundation schließt in ihrer Daten-Definition die Kuration der Dokumentation
als „the associated documentation needed to describe and interpret the data.“190 mit
ein. In Archivematica bildet die Reference Information der einzelnen Objekte und des
Pakets für die eindeutige Identifizierung im Archiv die vergebene UUID, welche die
Dateibenennungen ersetzt, jedoch hinterlegt Archivematica die Originalbenennung
zur Nachvollziehbarkeit und Unterstützung der Authentizität in PREMIS (vgl. hierzu
Kapitel 5.7 Testdurchläufe).
Hinzugefügte Checksummen durch den METS-Editor oder docuteam Packer
entsprechen der Fixity Information, welche einen Schlüssel zur Validierung sowohl
des Transferpakets, als auch der Primärobjekte zur Verfügung stellt.191 Die
Datenintegritätsprüfung findet im Archivematica-Transfer statt, wenn das
Transferpaket Checksummen als externe MD5-Dateien enthält. Daher sollte die
Web-Anwendung die Fixity Information für die Repräsentationsobjekte als externe
MD5-Dateien vor Abgabe generieren und im Transferpaket unter /metadata
speichern
Den Bereich der Content Information decken die Repräsentationsdateien als Data
Objects (genauer: Digital Objects) und die signifikanten Eigenschaften für
Rastergrafiken u. a. als Representation Information ab:
189
Eine Reference Information wäre bspw. die Angabe des Namens des Prozesses. 190
National Science Foundation: Cyberinfrastructure Vision for 21st Century Discovery, Arlington 2007, S. 22. URL: http://www.nsf.gov/pubs/2007/nsf0728/nsf0728.pdf [14.02.2016].
191 Vgl. nestor-Arbeitsgruppe OAIS-Übersetzung/Terminologie: Referenzmodell für ein Offenes Archiv-Informations-System, S. 61. URL: http://files.dnb.de/nestor/materialien/nestor_mat_16-2.pdf [14.02.2016].
Die Repräsentationsobjekte bilden physisch die Datei- und Bitstreamebene ab. Die
signifikanten Eigenschaften sind der Structure Information zugeordnet, da sie die
Content Information des Informationsobjektes in seiner interpretierbaren,
strukturellen Form und Qualität für die Designated Community beschreiben. Die
signifikanten Eigenschaften lassen sich aus den Scandaten (Kameradaten)
herauslesen. Insbesondere die Anzahl der Bits pro Farbkomponente dokumentieren
die Struktur und Qualität der Content Information auf Bitstreamebene in der
festgelegten Anordnung und Menge der Bits. Die Formatidentifikation und –
charakterisierung im Archivematica-Ingest in Berlin durch die Tools FITS und FIDO
erweitern die Repräsentationsinformation auf Dateiebene um die
Formatbeschreibung des Datenobjekts. Daher ist es nicht notwendig, technische
Metadaten zum Format im TIP mitzuliefern. Die Identifizierung des Formats erfolgt
automatisch anhand der eingelieferten Repräsentationsdateien.
Und schließlich sind weitere Scandaten zur Kamera oder sonstiger Hard- und
Software (Name, Modell, Version etc.), mit dem das Digitalisat erstellt oder bearbeitet
wurde, der Context Information zuzuordnen, welche die Beziehungen der Content
120
Information zu ihrer Umgebung darstellt – etwa warum die Content Information
erstellt wurde und wie sie sich zu anderen Objekten verhält:192
Abbildung 52: Zuordnung der Kameradaten zur Context Information
Die Kameradaten dokumentieren die Entstehungs- und Wiedergabeumgebung der
Content Information. Der Beziehung der Context Information zur Content Information
ist auf Dateiebene gegeben, indem jeder Repräsentationsdatei die Kameradaten
über den Dokumenttitel zugeordnet sind.
Es ist festzustellen, dass der Abdeckungsgrad der Langzeitarchivierungsmetadaten
bereits im Pre-Ingest sehr hoch ist. Nach dem vorgestellten Metadatenkonzept
konnten alle Elemente eines Informationsobjekts nach dem OAIS-Informationsmodell
mitzuliefernden Metadaten zugeordnet werden, hier noch einmal die englische
Version des OAIS-Informationsmodells vollständig abgebildet:
192
Vgl. nestor-Arbeitsgruppe OAIS-Übersetzung/Terminologie: Referenzmodell für ein Offenes Archiv-Informations-System, S. 61. URL: http://files.dnb.de/nestor/materialien/nestor_mat_16-2.pdf [14.02.2016].
Es müssen bereits im Pre-Ingest weitgehend alle Metadaten zur Erhaltung der
Digitalisate erfasst sein, um nachzuvollziehen, wie und in welcher Umgebung die
Objekte entstanden sind. Daher gilt für die Koordinierungsstelle Brandenburg-digital,
die abgebenden Stellen in die Verantwortung der Lieferung von erforderlichen
Metadaten zu nehmen, und diese per Übernahmevereinbarung verbindlich zu
machen.
193
Vgl. The Consultative Committee for Space Data Systems: Reference Model for an Open Archival Information System (OAIS), S. 4-40. URL: http://public.ccsds.org/publications/archive/650x0m2.pdf [14.02.2016]; Die Abbildung wurde im Vergleich zum OAIS-Informationsmodell um die Descriptive Information ergänzt, die ebenfalls Teil eines Informationsobjekts ist, jedoch keine Relevanz für die Erhaltung des AIP’s besitzt und deshalb im Paketmodell nicht vorkommt.
Zur besseren Nachvollziehbarkeit der einzelnen Prozessschritte dient die Workflowmodellierung als wichtiges Hilfsmittel. Im
Folgenden wird daher der Gesamtprozess von der beispielhaften Digitalisierung von Kulturgut bei der Einrichtung selbst, über die
Erstellung der jeweiligen Informationspakete TIP, SIP und AIP sowie der Rückgabe einer Kopie des AIP an die abgebende Einrichtung
dargestellt. Der Gesamtprozess wird hiernach weiter untergliedert und in Unterprozessen detaillierter betrachtet.
123
Abbildung 54: Gesamtprozess Archivierung von Digitalisaten
124
Workflow Digitalisierung
Der Workflow für die Digitalisierung beginnt hier beispielhaft in der Einrichtung selbst. Alternativen wären die Digitalisierung durch
Dritte wie das Digitalisierungslabor des FB 5 oder externe Dienstleister. Die analogen Objekte werden für den Scan vorbereitet. Zu
Scan vorbereiten gehören bspw. das Entmetallisieren des analogen Kulturgutes und das Vornehmen von Scaneinstellungen. Danach
erfolgt die eigentliche Digitalisierung. Grundsätzlich ist zu prüfen, ob der Scan erfolgreich war oder ob eine Nachbearbeitung mittels
Photoshop oder ähnlicher Software erforderlich ist. Anschließend werden die erforderlichen Metadaten im XMP-Standard hinterlegt
(vgl. Kapitel 7.4.4) und die Dateien im TIFF-Format entsprechend gespeichert. Zu beachten sind dabei die abgesprochenen
Konventionen (z. B. die Dateibenennungen). Die Digitalisierung ist damit abgeschlossen.
Abbildung 55: Workflow Digitalisierung
125
Erstellung TIP
Die Abgabe eines Transfer-Informationspakets beginnt bei der abgebenden Einrichtung, welche die Verzeichnisse auswählt, die zu
einem Transfer-Informationspaket geformt werden sollen. Die Submission Manifest sowie eine externe Metadatendatei kommen
hinzu, anschließend folgt die Zuordnung zur vorgegebenen Ordnerstruktur, ggfs. kann diese auch im Vorhinein automatisch erstellt
sein. Diese Struktur sollte bereits hier gegengeprüft werden, um spätere Nachbearbeitungen durch die Koordinierungsstelle
Brandenburg-digital zu vermeiden. Sollte diese nicht der vorgegebenen Struktur entsprechen, muss entsprechend durch die
abgebende Einrichtung nachgebessert werden. Nach erfolgreicher Prüfung generiert ein Abgabe-Tool nach Eingabe von Metadaten
eine Ablieferungsvereinbarung sowie Checksummen zur Prüfung innerhalb von Archivematica. Das TIP soll danach über dieses Tool
abgegeben werden, womit der Prozess beendet ist. Ein eventueller Fehler bei dieser Abgabe führt zu einer Meldung und dem
Abbruch des Vorgangs.
126
Abbildung 56: Erstellung TIP
Erstellung SIP
Der Prozess hin zur Erstellung eines SIP’s erfolgt durch die Koordinierungsstelle Brandenburg-digital, nachdem sie ein TIP durch eine
abgebende Einrichtung erhält und den Transfer in Archivematica einleitet. Die einzelnen Schritte richten sich nach den Microservices
des Transfers, welche in Kapitel 4.2 weiter beschrieben sind. Die Prozesse der Formaterkennung, -validierung sowie der
Formatcharakterisierung und Migration finden innerhalb der digiS statt, weshalb sie hier nicht Bestandteil des Workflows sind. Nach
127
Abschluss wird das SIP im Bereich des backlog gespeichert und kann von hier aus in den Ingest der Servicestelle Digitalisierung in
Berlin überführt werden.
Erstellung AIP
Nach Ablage des SIP’s kann die Übergabe zur digiS erfolgen. Mittels einer Webanwendung wird das SIP in den Ingest überführt und
dort weiter verarbeitet. Die einzelnen Schritte sind in Kapitel 5.3 näher beschrieben. Nach Durchlauf der Prozessschritte sowie der
Ablage des AIP im Archivspeicher sendet die digiS eine Kopie des AIP sowie einen Submission Report an die abgebende Einrichtung
über die erfolgreiche Übernahme der Digitalisate. Denkbar ist bei der Rücksendung des AIP‘s auch eine Verlinkung im Submission
Report auf eine Webanwendung, in der sich die abgebenden Einrichtungen das AIP jeweils ausgeben lassen können. Die Rückgabe
über die Koordinierungsstelle Brandenburg-digital wird an dieser Stelle noch nicht berücksichtigt.
Abbildung 57: Erstellung SIP
128
129
Abbildung 58: Erstellung AIP
130
9. Strategische Empfehlungen für die digitale Langzeitarchivierung
im Land Brandenburg (AP 3)
Das hier entworfene Projekt beruht auf den gemeinsamen Vorarbeiten, die die
Koordinierungsstelle Brandenburg-digital und der Arbeitskreis Brandenburg.digital
hinsichtlich der Digitalisierung von Brandenburger Kulturgütern geleistet haben.
Aktuell beläuft sich der Content demnach auf insgesamt ca. 17 Terrabyte in Form
von etwa 30.000 digitalen Objekten,194 die es für die Nachwelt zu bewahren gilt,
wobei es sich selbstverständlich nicht allein um Dateien des TIFF-Formates handelt,
wie sie hier bei den Popularen Schriftzeugnissen verwendet wurden. Bei einer
Realisierung des Vorhabens zur gänzlichen Langzeitarchivierung aller Kulturobjekte
Brandenburgs ist natürlich mit weit mehr Dateiformaten zu rechnen; auch in Archiven
ist bspw. die Verwendung von Audio- und Videodateien nichts Ungewöhnliches.
Bei einem Zusammentreffen von Vertretern des Arbeitskreises Brandenburg.digital
mit Kolleginnen und Kollegen des Zuse-Instituts für Informationstechnik und der
Servicestelle Digitalisierung wurde weiterhin festgestellt, dass eine Übernahme von
Daten seitens des KOBV‘s durch die digiS möglich ist; die Finanzierung einer
solchen Zusammenarbeit wird durch einen Vertrag des ZIB‘s mit dem Brandenburger
Ministerium für Wissenschaft, Forschung und Kultur (MWFK) gedeckt. Eine
zusätzliche Übernahme von Daten aus nicht-bibliothekarischen Einrichtungen
Brandenburgs entspricht nicht dem aktuellen Mandat und bedarf demnach einer
neuen vertraglichen Regelung seitens des ZIBs und des MWFKs.195
Ferner hielten die Vertreter fest, dass die Technologien und Techniken, die der
KOBV und die digiS im Rahmen ihrer Zusammenarbeit gemeinsam entwickeln,
strukturell vom Projekt zur Langzeitarchivierung Brandenburger Kulturdaten
übernommen bzw. angepasst werden dürfen, eine Entscheidung, die das hiesige
Projekt ausschließlich begrüßt und genauso gutheißt wie die Planung eines
kooperativen Projekts zwischen dem ZIB und (einer) brandenburgische(n)
194
Vgl. Arbeitskreis Brandenburg.digital; Zuse Institut für Informationstechnik; Servicestelle Digitalisierung Berlin: Zusammenfassung des Treffens von Vertretern des AK Brandenburg Digital mit Kolleginnen und Kollegen des Zuse Instituts für Informationstechnik (ZIB) und der Servicestelle Digitalisierung (digiS) (Protokoll). Berlin, 2016. S. 2.
195 Vgl. ebd.
131
Einrichtung(en), welche(s) die hier niedergelegten Erkenntnisse praktisch umsetzen
könnte(n).
Dass der Bereich der Informationswissenschaften der Fachhochschule Potsdam
sowie die im selben Haus befindliche Koordinierungsstelle ebenfalls in das
Forschungs- und Entwicklungsprojekt eingebunden werden sollen, findet ebenfalls
Anklang bei der derzeitigen Projektgruppe. Diese hält es nämlich für durchaus
vorstellbar, dass der Pre-Ingest-Bereich des Datentransfers zur digiS bei der
Koordinierungsstelle liegt, insofern die technische Infrastruktur hierfür gegeben ist –
die im hiesigen Projekt verwendeten Linux-Server und der NAS-Speicher mögen für
das hiesige Projekt, nicht aber für die Realisierung im größeren Maßstab geeignet
sein – und die Brandenburger Kultureinrichtungen von der Zusammenarbeit mit der
Servicestelle Digitalisierung überzeugt werden können.
Anders als bspw. beim Digitalen Archiv Nord oder dem Digitalen Magazin, bei denen
sämtliche Prozesse der Langzeitarchivierung im eigenen Haus stattfinden,
übernimmt die digiS nämlich keine Datendiagnostik, Datenaufbereitung oder
Datenkuration, sondern übernimmt eben nur die Verantwortung für die
Wiederauffindbarkeit von Inhalten. Insofern die verantwortlichen Einrichtungen ihre
Daten vorbildlich mit Metadaten ausstatten, stellt dies keinen Mangel dar, ein
Umstand, von dem Archive, Bibliotheken und Museen vermutlich jedoch erst
überzeugt werden müssten, sind diese es doch bisher gewohnt, für ihre eigenen
Daten auf eigenen Speichersystemen selbst Verantwortung zu übernehmen und
diese nicht mit einrichtungsfremden Daten auf einem Speicher zu lagern.
Möglicherweise liegt in dieser Überzeugungsarbeit die größte Herausforderung für
die Koordinierungsstelle Brandenburg-digital.
132
10. Entwurf einer Übernahmevereinbarung (AP 3)
Die in dieser Arbeit vorgeschlagene Lösung zur Langzeitarchivierung von digitalen
Kulturdaten ist eine gemeinsam wahrzunehmende Aufgabe der Servicestelle
Digitalisierung Berlin, der Koordinierungsstelle Brandenburg-digital und der
abgebenden Einrichtung, also des eigentlichen Datenproduzenten. Grundlage dieser
Zusammenarbeit sollte eine Übernahmevereinbarung sein, welche die im Rahmen
des Transfers/Ingest zu erfolgenden organisatorischen Prozesse und technischen
Details festhält.
Im Großen und Ganzen sollte sich diese zukünftige Übernahmevereinbarung an den
von der digiS ausformulierten Bestimmungen orientieren196 und lediglich um einige
nicht unwesentliche Punkte wie die zusätzliche Beifügung einer METS-Datei, deren
Metadaten das Primär-Datenobjekt näher beschreiben, ergänzt werden.
In diesem Zusammenhang sollte nochmals darauf hingewiesen werden, welche
Elemente bzw. Metadatensektionen in jener METS-Datei zu verwenden sind, so z.B.
das metadata reference element aus der administrativen Metadatensektion, um auf
externe Metadatensätze zu verweisen.
Ungeachtet dieser Ergänzungen soll auch die von der Servicestelle Digitalisierung
verlangte submission-manifest.txt mitabgeliefert werden.197 Sie bleibt von den oben
aufgelisteten Metadatenangaben genauso unberührt wie die von der digiS
gewünschten Verzeichnisstrukturen der Transferpakete.198
196
Vgl. Servicestelle Digitalisierung: Übernahmevereinbarung, Berlin 2014. URL: http://ewig.gfz-potsdam.de/wp-content/uploads/2011/12/ZIB_Muster_Uebernahmevereinbarung.pdf [14.02.2016].
Im Vergleich zum OAIS-Funktionsmodell wurde in der Koordinierungsstelle
Brandenburg-digital ein neuer Bereich gesetzt, der Pre-Ingest, welcher die
Vorubernahme eines TIP’s und Aufbereitung zu einem ubergabefähigen SIP an die
Langzeitarchivierungslösung der digiS Berlin darstellt. Denn die abgebenden
Brandenburger Kultureinrichtungen sind oftmals nicht in der Lage, alle benötigten
technischen Metadaten zu extrahieren oder Standards wie PREMIS und METS zu
bedienen, weswegen durch den Einsatz von Tools und der Aufbereitung in der
Koordinierungsstelle erst einmal übernahmefähige Informationspakete entstehen, die
in der Berliner Archivlösung als AIP langfristig aufbewahrt werden. Archivematica
bietet als Open-Source-Lösung für die digitale Archivierung den Bereich des
Transfers (also Pre-Ingest), welcher den Anwendungsfall unterstützt. Der Transfer
enthält zwanzig Microservices, die einzeln ein- oder ausgeschaltet werden können.
So ist ein definierter und auch automatischer Durchlauf möglich, was eine große
Abbildung 59: OAIS-Funktionsmodell für die Berlin-Brandenburger Archivlösung
134
Stärke des Systems ist. Archivematica findet im Bereich der digitalen Archivierung
durch den offenen Quellcode und damit verbundene Anpassungsmöglichkeiten auch
immer mehr Anwender. Die Abhängigkeit von privaten Firmen wird so verringert.
Eine weitere Anpassung des OAIS-Funktionsmodells stellt die Rückgabe des Pakets
in Form einer Kopie des AIP’s aus dem Access-Bereich der Berliner Lösung an die
abgebende Brandenburger Stelle dar. Es wird eine Kopie des AIP’s mit all seinen
gespeicherten Bestandteilen in der Archivematica-Ordnerstruktur nicht an den
Consumer, sondern an den Producer – die abgebenden Stellen – zurückgegeben.
Diese liefert das AIP nach Bedarf als DIP mit beschreibenden Metadaten an den
Consumer zur Nutzung aus. Dieser Bereich liegt jedoch außerhalb der Zuständigkeit
der Zuständigkeit des Aggregators und Langzeitarchivs, sodass der Access-Bereich
im Grunde für den Anwendungsfall keine Relevanz besitzt, in Berlin nur zur
Auslieferung von AIP’s und nicht zur Nutzung.
Bezüglich der Organisation von Metadaten, die den Prozess der
Langzeitarchivierung unterstützen und die digitalen Objekte lesbar und zugriffsfähig
halten, ist festzustellen, dass im Pre-Ingest-Bereich und schon davor in der
Aufbereitungsphase zum TIP erforderliche Metadaten mitgeliefert, generiert und in
einer bestimmten Form hinzugefügt werden müssen. Der Transferbereich von
Archivematica bietet einige Vorteile, wie die Validierung (Prüfung von mitgelieferten
Checksummen) zur Sicherstellung der Integrität, die Erstellung einer Paketstruktur,
die in den Ingest eingespeist werden kann, oder die Vergabe von UUID’s, die das
Paket und die Objekte eindeutig identifizieren. Zudem ist es möglich, eine METS-
Datei für das TIP zu erstellen und Metadaten zu charakterisieren und zu extrahieren.
Die generische, redundante und unstrukturierte Darstellung der mitgelieferten
Metadaten in der von Archivematica gespeicherten METS-Datei und der nicht
geringfügige Aufwand für die Einrichtungen in der Zusammenstellung bzw.
Auszeichnung der Metadaten sprechen allerdings gegen die Einlieferung von
Metadaten per Einbettung mit <mdWrap> und für den Verweis per <mdRef> in METS
auf eine externe Metadatendatei. Die Wahl des letzteren Verfahrens ergab sich durch
den Vorteil, dass die Einrichtungen ihre Datensätze zu den Objekten aus ihrer
Datenverwaltung in heterogenen Standards als externe Dateien, auf die im METS-
Standard verwiesen werden kann, ohne ein erforderliches Mapping mitliefern
können.
135
Die Aufbereitung und Erstellung eines TIP’s lässt sich automatisch mit Tools wie den
docuteam packer und SIP-Creator realisieren, z. B. die Erstellung der vorgegebenen
Ordnerstruktur zur Einlieferung in den Archivematica-Transfer sowie die Generierung
von Protokoll-Metadatendateien in METS, die den Prozess dokumentieren und die
Authentizität der digitalen Objekte unterstützen. Zwar werden die abgebenden
Einrichtungen durch den hohen Anteil an mitzuliefernden Metadaten für die
Erhaltung, Verifikation und Identifikation der Objekte im Langzeitarchiv nach dem
OAIS-Informationsmodell mehr in die Lieferungspflicht und Verantwortung für
vertrauenswürdige, digitale Objekte genommen, jedoch unterstützen Tools das
Aufbereiten des Pakets, der Objekte und Metadaten, sodass der Aufwand für die
Einrichtungen und/oder die Koordinierungsstelle Brandenburg-digital – je nach
festgelegter Zuständigkeit – dadurch verringert wird. Abzuwägen und in der
Übernahmevereinbarung zwischen den Einrichtungen, der Koordinierungsstelle
Brandenburg-digital und der digiS festzuhalten sind die Verantwortlichkeiten für
Prozesse und mitzuliefernde Metadaten zwischen den Einrichtungen und der
Koordinierungsstelle Brandenburg-digital, um einerseits einen geregelten und
fehlerfreien Geschäftsablauf zu gewährleisten und andererseits mit Metadaten die
Authentizität und Integrität der eingelieferten digitalen Objekte im Langzeitarchiv zu
erhalten und bei der Rücklieferung sicherzustellen. Das entwickelte
Metadatenkonzept ist jedoch noch nicht vollständig, sodass für die Übertragbarkeit
auf andere Digitalisierungsprojekte weitere Metadaten, insbesondere die
signifikanten Eigenschaften anderer Objekttypen auf Datei- und Bitstreamebene,
ermittelt werden müssen – genauso wie ein Objekt- oder Repräsentationenmodell in
Anlehnung an die erforderliche Abgabe-Verzeichnisstruktur und
Erschließungsebenen der Objekte in der Datenverwaltung der Einrichtungen
entwickelt werden muss, um die unterschiedlichen und unterschiedlich
erschlossenen, digitalen Objekte durch Archive, Bibliotheken und Museen strukturiert
und langzeitgesichert abzubilden.199
199
Für Anwendungsbeispiele siehe Keitel, Christian: Das Repräsentationenmodell des Landesarchivs Baden-Württemberg. In: Wolf, Susanne (Hrsg.): Neue Entwicklungen und Erfahrungen im Bereich der digitalen Archivierung. Von der Behördenberatung zum Digitalen Archiv, 14. Tagung des Arbeitskreises "Archivierung von Unterlagen aus digitalen Systemen" vom 1. und 2. März 2010 in München, München 2010 (=Sonderveröffentlichungen der Staatlichen Archive Bayerns), S. 69-82. URL: http://www.staatsarchiv.sg.ch/home/auds/14/_jcr_content/Par/downloadlist_3/DownloadListPar/download_9.ocFile/Publikation.pdf [14.02.2016], Präsentation verfügbar unter: http://www.gda.bayern.de/uploads/media/keitel_03.pdf [14.02.2016].; Rost, Christine:
Weiterhin ist festzustellen, dass die Bestandteile eines Informationsobjekts nach dem
OAIS-Informationsmodell lediglich einen konzeptionellen Rahmen bieten und in
Anpassung an den Anwendungsfall Interpretations- und Umsetzungsspielraum
bieten, sodass mitzuliefernde Metadaten manchmal mehreren Bestandteilen eines
Informationspakets oder -objekts zugeordnet werden können, je nach Auslegung und
Anwendung. Die digiS Berlin verwendet sogar eigene Begriffe für die
Zusammenfassung und Einordnung von Metadaten innerhalb eines Pakets
(Administrative Description Information) und nutzt anderweitig verwendete Begriffe
interpretatorisch für eigene Zwecke. So wird die Submission Documentation als
Kontextinformation zur Lieferung (z. B. ausgetauschte E-Mails) verstanden und in die
Representation Information der Content Information überführt, während in
Archivematica unter der Submission Documentation ein Übergabeformular oder eine
Schenkungsvereinbarung verstanden wird, was die Submission Manifest in Berlin mit
Vertrags- und Lieferungsinformationen darstellt.
Dieser Umstand erschwert die Konzeption der Brandenburger Archivlösung bzw. die
Kompatibilität des Konzeptes mit der Berliner Lösung – zumal ist zu prüfen, ob das
erstellte SIP im Archivematica-Transfer der Koordinierungsstelle Brandenburg-digital
den Anforderungen für die Überführung in den Berliner Ingest tatsächlich entspricht.
Wäre das nicht der Fall, ist strategisch zu überlegen, das von den Einrichtungen
gelieferte TIP durch die Koordinierungsstelle Brandenburg-digital so über eine Web-
Anwendung aufbereiten zu lassen, dass es den Pre-Ingest in Berlin, welches
kompatibel zum dortigen Ingest ist, durchlaufen kann. Hinsichtlich der Entwicklung,
dass eine Übernahme von digitalen Objekten KOBV-angehöriger Bibliotheken, also
auch Brandenburger Bibliotheken, in die digiS möglich und kooperativ geplant ist,
wäre es auch sinnvoll, eine direkte Schnittstelle von der Koordinierungsstelle
Konzeptionelle Überlegungen zur Strukturierung von Metadaten digitaler Objekte. In: Filthaut, Jörg (Hrsg.): Von der Übernahme zur Erschließung. Aktuelle Entwicklungen in der digitalen Archivierung, 18. Tagung des Arbeitskreises "Archivierung von Unterlagen aus digitalen Systemen" am 11. und 12. März in Weimar, Borna 2014 (=Schriften des Thüringischen Hauptstaatsarchivs Weimar), S. 67-72, Präsentation verfügbar unter: http://www.staatsarchiv.sg.ch/home/auds/18/_jcr_content/Par/downloadlist_1/DownloadListPar/download_1.ocFile/Praesentation%20Rost.pdf [14.02.2016]; Ullmann, Angela: Die Ordnung der Dinge. Ein Beitrag zur Systematisierung von Archivalien und Repräsentationen. In: VdA – Verband deutscher Archivarinnen und Archivare e. V. (Hrsg.): Archive ohne Grenzen. Erschließung und Zugang im europäischen und internationalen Kontext, 83. Deutscher Archivtag in Saarbrücken, Fulda 2014 (=Tagungsdokumentationen zum Deutschen Archivtag), S. 69-78.