langzeitarchivierung von digitalisaten - opus4.kobv.de · um diese auf plattformen wie die deutsche...
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
2.1 Digitales Archiv Nordrhein-Westfalen .............................................................. 11
2.2 Digitales Archiv Nord (DAN) und Digitales Magazin (DIMAG) ......................... 12
2.3 Kooperativer Bibliotheksverbund Berlin-Brandenburg ..................................... 14
3. Ist- und Soll-Zustand der IT-Infrastruktur in der Koordinierungsstelle
Brandenburg-digital (AP 1) ....................................................................................... 15
3.1 Einbinden des NAS an ein zweites Testsystem .............................................. 15
3.2 Suchfunktion im Storage-Bereich .................................................................... 17
4. Archivematica .................................................................................................... 21
4.1 Umsetzung nach dem OAIS-Referenzmodell (AP 1) ....................................... 23
4.2 Transfer- und Ingest-Microservices (AP 2) ...................................................... 26
4.3 Interne Tools (AP 2) ........................................................................................ 30
4.4 Möglichkeiten der Metadatenverwaltung (AP 2) .............................................. 32
4.5 Erhaltung signifikanter Eigenschaften (AP 2) .................................................. 35
4.6 Importvorgaben: Ordnerstruktur und Objektmodell (AP 2) .............................. 37
4.7 Testdurchläufe (AP 2) ..................................................................................... 40
5. Servicestelle Digitalisierung (digiS) am Konrad-Zuse-Institut Berlin .................. 49
5.1 Vergleich der Funktionsarchitektur zum OAIS-Referenzmodell (AP 1) ........... 50
5.2 Aufbau der Informationspakete im Vergleich zum OAIS-Informationsmodell (AP
3) ........................................................................................................................... 53
5.3 Pre-Ingest- und Ingest-Ablauf (AP 2) .............................................................. 56
6. Empfehlungen zur technischen & personellen Umsetzung ............................... 58
6.1 Hardwareanforderungen an eine lauffähige Archivematica-Installation (AP 1) 58
6.2 Personeller Bedarf (AP 1)................................................................................ 59
6.3 Institutioneller Bedarf: Raum und Netzwerk (AP 1) ......................................... 60
2
6.4 Aufwandseinschätzung: Installation und Einrichtung von Archivematica (AP 1)
.............................................................................................................................. 62
6.5 Sicherheitskonzept (AP 1) ............................................................................... 65
6.6 Anforderungen an eine Web-Anwendung (AP 2) ............................................ 69
6.7 Übernahme-Tools (AP 2)................................................................................. 71
7. Metadatenkonzept (AP 2) .................................................................................. 81
7.1 Langzeitarchivierungsmetadaten ..................................................................... 81
7.2 Technische Metadaten und Tools ................................................................... 84
7.3 Metadatenstandards ........................................................................................ 85
7.3.1 METS ....................................................................................................... 85
7.3.2 Dublin Core............................................................................................... 86
7.3.3 EAD .......................................................................................................... 88
7.3.4 XMP .......................................................................................................... 89
7.3.5 PREMIS .................................................................................................... 89
7.3.6 Erweiternde Schemata ............................................................................. 92
7.3.7 Anwendung............................................................................................... 93
7.4 Metadaten-Bestandsaufnahme und -Umsetzung ............................................ 95
7.4.1 Erfassung beschreibender Metadaten ...................................................... 95
7.4.2 Beschreibende und strukturelle Metadaten .............................................. 97
7.4.3 Eingebettete Metadaten in Digitalisaten ................................................. 100
7.4.4 Mitzuliefernde Digitalisierungsmetadaten ............................................... 105
7.4.5 Weitere administrative und beschreibende Metadaten zur
Prozessdokumentation und TIP-Beschreibung ............................................... 107
7.4.6 Übersicht mitzuliefernder Metadaten im TIP ........................................... 110
7.5 Übersicht der TIP-Bestandteile ...................................................................... 111
7.6 Abdeckung der Metadaten nach dem OAIS-Informationsmodell ................... 113
8. Darstellung der Workflows (AP 2).................................................................... 122
3
9. Strategische Empfehlungen für die digitale Langzeitarchivierung im Land
Brandenburg (AP 3) ................................................................................................ 130
10. Entwurf einer Übernahmevereinbarung (AP 3) ............................................. 132
11. Zusammenfassung (AP 2) ............................................................................ 133
12. Verzeichnisse ............................................................................................... 139
12.1 Abbildungsverzeichnis ............................................................................ 139
12.2 Tabellenverzeichnis................................................................................ 141
12.3 Literaturverzeichnis & Webressourcen ................................................... 141
Anhang ................................................................................................................... 153
4
1. Einleitung (AP 2)
Es gibt mittlerweile viele Projekte zur Digitalisierung von Kulturgut in allen Sparten,
um diese auf Plattformen wie die Deutsche Digitale Bibliothek (DDB), die Europeana
oder andere Portale Nutzern im Informationszeitalter komfortabel zur Verfügung zu
stellen. Die Plattformen bieten jedoch keine Möglichkeit der Archivierung. Das bleibt
der jeweiligen Einrichtung überlassen und wird durch die bisherige Projektförderung
auch nicht berücksichtigt. Aus Gründen der Nachhaltigkeit und der
Bestandserhaltung erscheint es aber notwendig, nicht nur das analoge Kulturgut zu
erhalten, sondern auch die zugehörigen digitalen Objekte zu bewahren – zumal mit
der Nutzung und Erhaltung von Digitalisaten die analogen Originale vor Abnutzung
geschützt oder auch gänzlich Informationen in Notfallsituationen qualitativ gerettet
werden, wenn das Kulturgut durch Zerfall oder Auflösung bedroht ist. Beispiele
stellen hierfür die Sammlung Aschebücher1 und die Akten des Ministeriums für
Staatssicherheit2 dar. Aber die dauerhafte Bewahrung von Zugänglichkeit und
Nutzbarkeit digitaler Ressourcen ist für alle Gedächtnisinstitutionen eine
Herausforderung, denn die Lesbarkeit von elektronischen Medien ist durch den
schnellen technischen Wandel von Datenträgern, Formaten und die stetige
Veränderung und Weiterentwicklung der zur Nutzung notwendigen
Anwendungsprogramme bedroht,3 denn digitales muss im Gegensatz zu analogem
Material durch Software interpretiert werden, bevor sein Inhalt den Nutzer erreicht.
Die Obsoleszenz von Datenträgern, Dateiformaten durch den technologischen
Wandel und die nicht mehr gewährleistete Lesbarkeit von Dateien durch mögliche
Hard- oder Softwarebeschädigungen erschweren oder verhindern gänzlich die
dauerhafte Zugänglichkeit und Benutzbarkeit von digitalen Informationen.4
1 Siehe Krumeich, Kirsten: Die Sammlung Aschebücher. Qualitätssicherung in der Digitalisierung. In:
Bibliotheksdienst 47 (2013) 7, S. 507-522. 2 Siehe Krumeich, Kirsten: Virtuelle Rekonstruktion zerrissener Stasi-Unterlagen. Problemstellungen,
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].
4 Vgl. Puhl, Johanna; Rau, Lisa: Kap. 3 Langzeitarchivierung. In: 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), S. 20-21.
5
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.
7 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].
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).
6
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
Brandenburg - Zusammenfassung. - http://www.fh-potsdam.de/fileadmin/fb-informationswissenschaften/dokumente/fachbereich/Koordinierungsstelle_Brandenburg-digital/konzept-zusammenfassung.pdf [14.02.2016].
7
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].
15 Siehe digis - Servicestelle Digitalisierung Berlin. URL: http://www.servicestelle-
digitalisierung.de/confluence/pages/viewpage.action?pageId=917513 [14.02.2016]. 16
Vgl. Koordinierungsstelle Brandenburg-digital. - http://www.fh-potsdam.de/studieren/informationswissenschaften/fachbereich/brandenburg-digital/ [14.02.2016].
8
Charakters“ – verfasst vor allem von Mitgliedern der Mittel- und Unterschichten – zu
verstehen ist. Es handelt sich dabei um Einzelstücke mit Seltenheitswert, welche sich
nur zu einem sehr geringen Teil unter der in Archiven, Bibliotheken und Museen
aufbewahrten schriftlichen Überlieferung befinden, meist der Forschung
unzugänglich aus privater Hand stammen oder kleinere Nachlässen in Museen und
Archiven bilden. Dabei sind gerade solche Schriftstücke als Quellen für die
Forschung interessant, vermitteln sie doch einen unmittelbaren Eindruck vom Alltag
der Vorfahren.17
Das Digitalisierungsprojekt entstand auf Grundlage des Ergebnisses einer
systematischen Erfassung dieser Quellengruppe in den 1990er-Jahren, das vom
Brandenburgischen Landeshauptarchiv 2004 veröffentlicht wurde.18 Im Jahr 2014
erfolgte die Digitalisierung und Nutzbarmachung ausgewählter Schriftzeugnisse aus
den Bereichen Notizbücher, Tagebücher, Hofbriefe, Rezepte und Magie sowie
Sprüche und Lieder mit Förderung durch das Ministerium für Wissenschaft,
Forschung und Kultur. Es handelte sich um ein Gemeinschaftsprojekt der
Landesfachstelle für Archive und öffentliche Bibliotheken im Brandenburgischen
Landeshauptarchiv und des Museumsverbandes für das Land Brandenburg mit
Unterstützung der Koordinierungsstelle Brandenburg-digital.19
Innerhalb des Masterprojektes wurden drei Ebenen (Archivematica, Use Case
Populare Schriftzeugnisse, Kompatibilität mit Berlin) betrachtet, wodurch sich die
Aufteilung der Arbeit in drei Arbeitspakete (AP) ergab. Deshalb sind im Folgenden
die Ergebnisse der Arbeitsgruppen dargestellt. Zunächst sollen bestehende
Langzeitarchivierungslösungen vorgestellt werden, um den Stand im Land
Brandenburg im Bereich Langzeitarchivierung innerhalb Deutschlands zu verorten,
bevor der Ist- und Soll-Zustand der IT-Infrastruktur (Speicherlösung und –anbindung)
und Systemarchitektur in der Koordinierungsstelle Brandenburg-digital – mit Tests
der Leistungs- und Suchfunktion der Datenverwaltung, welche die
17
Vgl. Museum-digital: Populare Schriftzeugnisse. Projektbeschreibung. URL: http://www.museum-digital.de/themator/ausgabe/showthema.php?m_tid=488&tid=488&ver=nat [14.02.2016].
18 Siehe 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).
19 Vgl. Museum-digital: Populare Schriftzeugnisse. Projektbeschreibung. URL: http://www.museum-
digital.de/themator/ausgabe/showthema.php?m_tid=488&tid=488&ver=nat [14.02.2016].
9
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].
11
folgenden Abschnitt werden daher drei bzw. vier unterschiedliche Kooperationen
vorgestellt.21
Da die digiS die digitale Langzeitarchivierung Brandenburgischer Kulturdaten
voraussichtlich erheblich unterstützen wird (und damit bereits im Rahmen einer
Kooperationsaufgabe mit dem Kooperativen Bibliotheksverbund Berlin-Brandenburg
(KOBV) begonnen hat), wird sie in Anschluss an die Beschreibungen der jeweiligen
Verbünde ebenfalls in einem eigenen Abschnitt näher bekannt gemacht.
2.1 Digitales Archiv Nordrhein-Westfalen
Um den Herausforderungen der digitalen Langzeitarchivierung zu begegnen, haben
die Kultur- und Gedächtnisorganisationen Nordrhein-Westfalens spartenübergreifend
und gefördert durch das Ministerium für Familie, Kinder, Jugend, Kultur und Sport
(MFKJKS) das Digitale Archiv Nordrhein-Westfalen (DA NRW) gegründet, einen
Verbund, in dem Archiv-, Bibliotheks- und Museumsdaten gemeinschaftlich
langzeitarchiviert werden und zukünftig auch über ein gemeinsames Landesportal
präsentiert werden sollen.22
Abgesehen von der soft- und hardware-technischen Realisierung des DA NRWs –
das Institut für Historisch-kulturwissenschaftliche Informationsverarbeitung der
Universität Köln entwickelte hierfür u.a. eigens die Softwarelösung DA NRW
Software Suite (DNS), welche eine verteilte, kooperative und redundante
Speicherung der Daten in einer OAIS-konformen Gesamtarchitektur ermöglicht – ist
das Konzept dem Brandenburger Vorhaben nicht unähnlich: Zwar ist ein
gemeinsames Portal für die Brandenburger Einrichtungen derzeit nicht geplant, geht
es doch vor allem um die gesicherte Datenablage und nicht um eine öffentliche
Präsentation der Kulturgüter, handelt es sich jedoch in beiden Kooperationsprojekten
um ein spartenübergreifendes Projekt von Archiven, Bibliotheken und Museen.
Dessen ungeachtet ist das DA NRW jedoch zwecks Präsentation auf einer
gemeinsamen Internetplattform eben „nur“ an digitalen Daten aus Nordrhein-
Westfalen interessiert und stellt seinen Mitgliedsinstituten hierfür eigens ein
Presentation Repository zur Verfügung. Die Speicherung der Daten erfolgt
21
Da das Digitale Archiv Nord (DAN) dem Digitalen Magazin (DIMAG) 2014 beigetreten ist, werden beide Projekte in einem Abschnitt zusammengefasst.
22 Vgl. Digitales Archiv Nordrhein-Westfalen: Portal, o. O. 2015. URL: https://www.danrw.de/portal/
[14.02.2016].
12
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].
13
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].
14
2.3 Kooperativer Bibliotheksverbund Berlin-Brandenburg
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].
15
3. Ist- und Soll-Zustand der IT-Infrastruktur in der
Koordinierungsstelle Brandenburg-digital (AP 1)
Es lagen zu Beginn des Projektes zwei verschiedene Testinstallationen von
Archivematica vor. Auf beiden Systemen war es möglich, Pakete mit dem Transfer-
und Ingest-Workflow bis zur Erstellung und Speicherung des AIP‘s zu verarbeiten.
Beide Instanzen wurden auf jeweils einer Ubuntu-Server-Installation (12.04 LTS)
betrieben. Als Testumgebung konnte fur die Laufzeit des Projektes die Archivematica-
Installation auf einer NUC (Next Unit of Computing) genutzt werden. Der Server
entspricht den Minimalanforderungen an eine Archivematica-Testumgebung (vgl.
Kapitel 6.1).
Der Archivspeicher sollte durch einen Netzwerkspeicher (NAS – Network Attached
Storage) realisiert werden, diese war zu Beginn allerdings nur an eine Archivematica-
Installation angeschlossen. Im Laufe des Projektes konnte sie auch in der zweiten
Installation implementiert werden:
3.1 Einbinden des NAS an ein zweites Testsystem
Ein Problem zu Beginn des Kurses war, dass es nicht möglich ist, den NAS an ein
zweites Testsystem einzubinden, so dass die lokale Festplatte der Ubuntu-Installation
genutzt wurde. Im Rahmen des weiteren Projektes sollte eine Möglichkeit gefunden
werden, das zweite Testsystem an den in der FHP vorhandenen NAS-Speicher
anzubinden. Im bisherigen System wurden alle Pakete auf einer Festplatte
gespeichert, was nicht konform zum OAIS-Referenzmodell ist.
Die NAS-Lösung muss an das zugrundeliegende Ubuntu-System eingebunden
werden. Dies geschieht im besten Falle uber fstab, einer Konfigurationsdatei zum
automatischen Einhängen (mounten) von Partitionen und externen Speichern.
Nachdem die Adresse der NAS in die Konfigurationsdatei eingetragen wurde,
erscheint die neue NAS unter Ubuntu unter dem dafur eingerichtetem Alias
(„nas_share1“) im Ordner „media“ und kann somit direkt von der Archivematica-
Installation zur Speicherung der Pakete genutzt werden:
16
Im Anschluss mussen die Speicherorte im Archivematica-System manuell
umgetragen werden, da im Storage-Service händisch die Speicherorte der zuvor
benutzten HDD eingestellt wurden:
Abbildung 2: Speicherlokationen auf der lokalen Festplatte (vorher)
Abbildung 1: Die neu eingebundene NAS mit dazugehörigen Ordnern für AIP, DIP, TIP etc.
17
Die Archivematica-Installation kann nun die Pakete auf dem Netzwerkspeicher
ablegen. Ein manuelles Umtragen der NAS-URLs ist nötig, wenn Ingest und Storage
angesprochen werden sollen. Dieses Problem trat bei beiden Testsystemen auf:
Der Workflow in Archivematica funktioniert lediglich, wenn fur Ingest und Archival
Storage in den Systemeinstellungen die Speicherlokationen manuell auf
„localhost“ geändert werden. Dies ist insofern ungewöhnlich, da beide Einstellungen
auf den gleichen Ort verweisen und somit uberflussig sein mussten.
Da bei der Installation des Storage-Service von Archivematica die Speicherorte
festgesetzt werden, kann lediglich durch eine Neuinstallation des Speichermoduls
dieses Problem behoben werden: Über den Unix-Befehl „apt-get purge“ lassen sich
Einstellungen sowie Programmdateien des Storage-Service entfernen. Eine
Neuinstallation uber „apt-get install“ fuhrt eine erneute Installation des
Speichermoduls durch, ohne vorherige Programmeinstellungen zu ubernehmen. Es
ist nun nicht mehr nötig, beim Durchlaufen des Workflows die Orte des Speichers
manuell umzuändern.
3.2 Suchfunktion im Storage-Bereich
Zu Beginn des Projekts bestand keine Möglichkeit nach Informationspaketen uber
den Archival-Storage zu suchen. Archivematica sieht fur die Indexierung der Pakete
Abbildung 3: Storage-Service von Archivematica mit den neuen Speicherorten der NAS (nachher)
18
das Plugin „Elasticsearch“ vor. Dieses ist fur die Indexierung und einer Suchfunktion
fur AIP‘s relevant. Zu Beginn des Projektes konnte in Erfahrung gebracht werden,
dass Elasticsearch auf einem der Testsysteme getestet und nach
Sicherheitsbedenken wieder deaktiviert wurde, da es an einer Absicherung des
Zugriffs auf das Plugin mangelte. Im Verlauf der Projektarbeit wurde nach einer
Möglichkeit recherchiert, das Elasticsearch-Plugin abzusichern – dabei zog die
Arbeitsgruppe die Elasticsearch-Erweiterung „Shield“ in Betracht.28
Durch „Shield“ soll es möglich sein, den Zugriff auf die indexierten Daten via Login
abzusichern, IP-Filterungen sowie alle Zugriffe auf Elasicsearch zu protokollieren.
Die Installation der Erweiterung erfolgt uber die Kommandoebene des Ubuntu-
Systems. Jedoch benötigt die Erweiterung eine aktuellere Java-Version des Systems
– die Programmdokumentation setzt mindestens Java in der Version 7 oder höher
voraus.29
Ein Upgrade der Java-Installation ist mit der derzeit eingesetzten Ubuntu-Version
nicht möglich, da eine aktuellere Java-Version ein Ubuntu in der Version 14.04
benötigt. Da ein Upgrade von Ubuntu 12.04 auf 14.04 technisch möglich, aber oft mit
Komplikationen verbunden ist, ist es ratsam, ein vollständiges Backup des Systems
inklusive Archivematica zu besitzen.
28
Vgl. ElasticSearch BV: Shield. URL: https://www.elastic.co/products/shield [14.02.2016]. 29
Vgl. ElasticSearch BV: Installing Shield. URL: https://www.elastic.co/guide/en/shield/current/installing-shield.html [14.02.2016].
19
Derzeit ist es jedoch ebenfalls nicht möglich, Software auf dem Ubuntu-System zu
installieren, da ein fehlerhaftes Update den aktuellen Kernel zerstört hat. Das
Ubuntu-System lässt sich problemlos mit einem älteren Kernel starten, verhindert
wird durch Abhängigkeiten einiger Programbibliotheken jedoch das Updaten und
Installieren von Software. Es ist zu uberlegen, ob eine Neuinstallation des Ubuntu-
Systems (Version 14.04 LTS) besser umzusetzen ist, als das bestehende zu
reparieren und im Anschluss ein Upgrade auf eine neuere Version durchzufuhren.
Beim Generieren der Informationspakete vergibt Archivematica jedem Paket eine
eindeutige UUID, die zum Wiederauffinden im Storage-Bereich als auch auf
Dateiebene genutzt werden kann. Die Pakete werden auf Datei-Ebene jedoch nicht
nach der vollständigen ID gespeichert, sondern in 4er-Ketten aufgeteilt. So ergibt
sich fur jede UUID eine Ordnerhierarchie nach folgender Struktur:
Am Ende der Hierarchie sind die eingelagerten Dateien erreichbar, jedoch ist eine
Suche auf Ebene des Dateisystems nach UUID somit nicht praktikabel zu
handhaben. Innerhalb des Projekts sollte daher der Frage nachgegangen werden, zu
welchem Zweck Archivematica die Pakte in einer hierarchischen Ordnerstruktur
speichert. Im Gespräch mit Mitarbeitern vom Zuse-Institut Berlin konnte in Erfahrung
Abbildung 4: Storage-Bereich von Archivematica mit vollständigen UUID's
Abbildung 5: Hierarchie der UUID's
20
gebracht werden, dass es sich hierbei keineswegs um eine Fehlkonfiguration von
Archivematica handelt, sondern das Aufteilen der UUID‘s einen Zweck erfullt: Das
Feature wird „PairTree“ genannt und verhindert dass zu viele Dateien in einer
Hierarchie auf einem Laufwerk gespeichert werden.
Diese Funktionalität wird ebenfalls in der offiziellen Dokumentation der aktuellen
Archivematica-installation beschrieben und bestätigt damit, dass es keineswegs eine
Fehlkonfiguration des Systems ist:
„UUID quad directories: Some file systems limit the number of items allowed in a
directory, Archivematica uses a directory tree structure to store AIPs. The tree is
based on the AIP UUIDs. The UUID is broken down into manageable 4 character
pieces, or “UUID quads”, each quad representing a directory. The first four characters
(UUID quad) of the AIP UUID will compose a sub directory of the AIP storage. The
second UUID quad will be the name of a sub directory of the first, and so on and so
forth, until the last four characters (last UUID Quad) create the leaf of the AIP store
directory tree, and the AIP with that UUID resides in that directory.)“30
Da einige Dateisysteme nur eine limitierte Anzahl an Files zulassen, wurde diese
Funktion fur Archivematica ubernommen, da in einem Archivsystem davon
ausgegangen werden kann, eine große Anzahl an Paketen zu speichern.
30
Vgl. Archivematica: Archival Storage. URL: https://www.archivematica.org/en/docs/archivematica-1.4/user-manual/archival-storage/archival-storage/#storing-aip [14.02.2016].
21
4. Archivematica
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].
32 Vgl. Archivematica: Microservices. URL: https://www.archivematica.org/en/docs/archivematica-
1.4/_images/Micro-service.png [14.02.2016].
22
Auf die einzelnen Funktionen von Archivematica kann über ein webbasiertes
Interface problemlos zugegriffen werden.33 Das System enthält Funktionen zum Pre-
Ingest (oder Transfer) und zum Ingest der Informationspakete, zum Preservation
Planning, der Administration und zum Archival Storage. Funktionen zum Access, also
zum Zugriff auf die DIP‘s, müssen zusätzlich implementiert werden. Standardmäßig
voreingestellt ist dazu das ebenfalls unter Federführung von Artefactual entwickelte
Zugriffssystem AtoM.34
Abbildung 7: Archivematica - Dashboard35
Die obige Abbildung bietet einen Einblick in das von Archivematica zur Verfügung
gestellte webbasierte Dashboard. Im Screenshot geöffnet ist das Menü zum Ingest.
Gut erkennbar ist die Liste der Jobs und Mikroprozesse, die während des Ingest von
den einzelnen Datenpaketen durchlaufen werden. Die in den Jobs enthaltenen
33
Vgl. Archivematica: web-based dashboard. URL: https://www.archivematica.org/en/docs/archivematica-1.4/user-manual/overview/dashboard/#web-dashboard [14.02.2016].
34 Vgl. Archivematica: Default access system. URL:
https://www.archivematica.org/en/docs/archivematica-1.4/user-manual/access/access/#upload-atom [14.02.2016].
35 Vgl. Archivematica: Archivematica 1.4 Dashboard. URL:
https://www.archivematica.org/en/docs/archivematica-1.4/_images/Dashboard.png [14.02.2016].
23
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].
24
umzuwandeln. Erst nachdem die Pakete den Transfer durchlaufen haben und als
SIP vorliegen, kann der Ingest angestoßen werden.37
Der Access-Bereich wird zwar im Dashboard verzeichnet, ist allerdings nicht Teil der
Funktionalität von Archivematica selbst. Für den Zugriff auf DIP‘s ist die Installation
eines Zusatzprogramms notwendig. Standardmäßig voreingestellt ist die
Verwendung der ebenfalls von Artefactual entwickelten Software AtoM,38 andere
Möglichkeiten sind ContentDM39 und Archivist’s Toolkit.40
Trotz der weitgehenden Abbildung des Referenzmodels existieren einige kleine
Unterschiede zwischen Archivematica und dem OAIS-Modell. In Archivematica wird
das AIP gleichzeitig mit dem DIP gebildet; während das AIP dann im Archivspeicher
archiviert wird, wird das DIP im uploadDIP directory gespeichert, woraufhin der
Nutzer entscheiden kann, ob er das DIP speichert oder für die weitere Nutzung auf
die jeweils installierte Nutzerschnittstelle hochlädt. Alternativ können die DIP‘s auch
auf dem lokalen Rechner abgelegt werden. Im OAIS-Modell hingegen wird zunächst
nur das AIP gebildet. Das DIP wird erst dann aus dem AIP und den
Erschließungsinformationen zusammengesetzt, wenn es tatsächlich vom Nutzer
angefragt wird.41 Da in Archivematica diese vor der Nutzung zunächst hochgeladen
werden müssen, ist das System in diesem Punkt benachteiligt.
Die Datenverwaltung wird in Archivematica nicht als einzelne Funktionseinheit
dargestellt. Stattdessen werden die Funktionen, die im OAIS-Modell zur
Datenverwaltung gehören, in Archivematica auf verschiedene andere
Funktionseinheiten aufgeteilt.
37
Vgl. Archivematica: Transfer. URL: https://www.archivematica.org/en/docs/archivematica-1.4/user-manual/transfer/transfer/#transfer [14.02.2016].
38 Vgl. Archivematica: Default access system. upload-AtoM. URL:
https://www.archivematica.org/en/docs/archivematica-1.4/user-manual/access/access/#upload-atom [14.02.2016].
39 Vgl. Archivematica: ContentDM. https://www.archivematica.org/en/docs/archivematica-1.4/user-
manual/access/contentdm/#contentdm [14.02.2016]. 40
Vgl. Archivematica: Upload DIP Metadata to Achivist’s Toolkit. URL: https://www.archivematica.org/en/docs/archivematica-1.4/user-manual/access/archivists-toolkit/#archivists-toolkit [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].
25
Umsetzung der Datenverwaltung in Archivematica
Aufgrund der Funktionsweise von Archivematica ist der im OAIS-Modell enthaltene
Funktionsbereich der Datenverwaltung nicht als isolierte Funktionseinheit vorhanden.
Die in OAIS von der Datenverwaltung übernommenen Funktionen sind in
Archivematica stattdessen im Bereich Archival Storage größtenteils direkt enthalten.
So sind in Archivematica die Funktionen zur Verwaltung der AIPs im Dashboard
direkt in die Funktionseinheit Archival Storage integriert. Der Speicher kann hier
durchsucht, die AIP‘s können geöffnet und heruntergeladen werden. Es ist ebenfalls
möglich die gespeicherten AIP‘s zu löschen.42 Da das für die Durchführung der
Suche notwendige Programm ElasticSearch in der an der FH Potsdam verfügbaren
Archivematica-Installation deaktiviert werden musste, konnte dies allerdings nicht
ausführlich getestet werden.
Abbildung 9: Archivematica - Suche im Archivspeicher43
Da in Archivematica die DIP‘s direkt beim Ingest der Datenpakete gebildet werden,44
muss das Wiederauffinden der AIP‘s zum Zwecke der externen Nutzung nicht vom
Archivspeicher übernommen werden. Bereits nach dem Ingest kann der Nutzer
42
Vgl. Archivematica: Archival Storage. URL: https://www.archivematica.org/en/docs/archivematica-1.4/user-manual/archival-storage/archival-storage/#archival-storage [14.02.2016].
43 Vgl. Archivematica: Suche im Archivspeicher. URL:
https://www.archivematica.org/en/docs/archivematica-1.4/_images/SearchArchStor.png [14.02.2016].
44 Vgl. Archivematica: Ingest. Store the AIP. URL:
https://www.archivematica.org/en/docs/archivematica-1.4/user-manual/ingest/ingest/#store-aip [14.02.2016].
26
entscheiden, ob er die DIP‘s speichert oder zur Nutzung in der jeweiligen
Benutzerschnittstelle hochlädt.45
4.2 Transfer- und Ingest-Microservices (AP 2)
Die folgende Tabelle gibt Aufschluss über die vorhandenen Microservices im Bereich
des Transfers von Archivematica.46 Für den Use Case werden die Services der
Formatidentifikation, der Charakterisierung sowie der Validierung nicht benötigt, da
diese Funktionen bereits innerhalb des Workflows der digiS bestehen. Der Transfer
dient daher lediglich dazu, ein übernahmefähiges SIP zur Übergabe an die Berliner
Lösung zu erstellen.
Name des Microservice Bedeutung/Beschreibung
Approve Transfer Einleitung des Transfers
Verify Transfer Compliance
Überprüfung der Einhaltung der
vorgegebenen Verzeichnisstruktur
Rename with Transfer UUID Vergabe eines Identifiers zur
Identifizierung des Transfers
Include default Transfer
processingMCP.xml
Fügt eine Datei namens
“processingMCP.xml” hinzu. Diese
konfigurierbare XML-Datei dient dazu,
Prozessentscheidungen zu unterstützen.
Wie Transfer-Backups, die Verschiebung
des Transferpakts in den
Quarantänebereich und die SIP-
Erstellung
Assign file UUIDs and Checksums Identifizierung und Prüfung von
Checksummen
Reformat metadata files mitgelieferte Metadaten im JSON-Format
werden in eine metadata.csv überführt
Verify Transfer checksums Prüfung von Checksummen, die im
Metadatenverzeichnis mitgeliefert
45
Vgl. Archivematica: Access. URL: https://www.archivematica.org/en/docs/archivematica-1.4/user-manual/access/access/#access [14.02.2016].
46 Vgl. Archivematica-Wiki: Microservices. URL: https://wiki.archivematica.org/Micro-services
[14.02.2016].
27
wurden
Generate METS.xml document
Erstellung einer METS-Datei für das
Transferpaket
Quarantine Verschiebung in die Quarantäne vor der
Virenprüfung, Update der Virensoftware
Scan for Viruses Virenprüfung
Generate transfer structure report Erzeugt einen Transferbericht zur
Struktur des Informationspakets in txt-
Format
Clean up names Bereinigung der Dateinamen,
Sonderzeichen werden als Bindestriche
dargestellt und der Originalname in
PREMIS abgelegt
Identify file format Identifikation des File-Formats mit FIDO
Extract packages Entpacken der Transferpakete
Update METS.xml Document erstellt eine structuremap im METS-
Dokument
Charactersize and extract metadata Charakterisierung und Extraktion der
Metadaten
Validation Validiert Dateiformate mit JHOVE
Examine contents Durchlauf des Tools “bulk_extractor” und
Erstellung eines Berichts
Complete Transfer Abschluss des Transfers
Create SIP from Transfer Erstellung eines SIPs, Überführung in
Ingest
Tabelle 1: Microservices im Transfer von Archivematica
Die Folgende Tabelle stellt die Microservices von Archivematica im Bereich des
Ingest dar. Da in diesem Anwendungsfall der Ingest innerhalb der digiS mit
Archivematica geschieht, dient diese Übersicht der Nachvollziehbarkeit der dortigen
Prozesse.47
47
Vgl. Archivematica-Wiki: Microservices. URL: https://wiki.archivematica.org/Micro-services [14.02.2016].
28
Microservice Tätigkeit/Beschreibung
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].
49 Vgl. Archivematica-Wiki: Release 1.4. URL: https://wiki.archivematica.org/Release_1.4
[14.02.2016].
31
ExifTool 9.76 Metadatenextraktion
FFmpeg 2.6 Converter für Audio- und Videoformate
File Information
Tool Set (FITS)
0.8.4 File-Formatidentifikation und Validierung,
Integrationstool
fido 1.3.1-78 Formatidentifikation
Siegfried 1.0 Formatidentifikation
JHOVE 1.6+dfsg-
1
Validierung
MediaInfo 0.7.52 Extraktion von Multimedia-Metadaten
Tesseract 3.02.01 Tool für OCR – Optical Charakter Recognition,
Texterkennung
AtoM 2.1.2 Webbasiertes Tool für die Bereiche Beschreibung
und Zugang. Dieses Tool muss gesondert installiert
und an Archivematica angebunden werden
Imagemagick 6.6.9.7 Converter für Bitmap-Grafiken
Inkscape 0.48.3.1 konvertiert Vector-Grafiken in das Scalable Vector
Graphic (SVG)-Format
NFS-common 1.2.5 Network File System Zugang – erlaubt den Zugang
auf digitale Objekte via Netzwerkspeicher
Python-xml 2.3.2 Python-Anbindung für libxml2 und libxslt
The Sleuthkit 4.1.3 Management und Metadaten-Extraktion von
Datenträgern
md5deep 3.9.5 Tool zur Erzeugung und Verifikation von
Prüfsummen in md5-Format
UUID 1.6.2 Erzeugt Universally Unique Identifier (UUID) –
Identifikatoren für Pakete, Dateien und Vorgänge
Ubuntu Linux 14.04.2 Betriebssystem zur Anbindung an die Computer-
Hardware
Zip 3.0 Container-Format zur Erzeugung eines AIP-Pakets
Django 1.5.4 Tool für die Phyton Web-Programmierung
Gearman 0.27 Jobserver, um Aufgaben und Prozesse an
verschiedene Maschinen zu verteilen – parallele
Aufgabenerledigung
32
p7zip 9.20.1 Erzeugung von Containern mit hoher
Kompressionsrate
unar 1.8.1 Entpacken von Paketen
Tabelle 3: Tool's innerhalb von Archivematica
4.4 Möglichkeiten der Metadatenverwaltung (AP 2)
Archivematica besitzt einige Microservices, die das Hinzufügen, Extrahieren und
Erstellen von Metadaten erlauben, bis hin zur Generierung einer METS-Datei, in der
die Informationen gespeichert werden. Bei Generierung einer METS-Datei werden
die beschreibenden Metadaten in Dublin Core, die in Form einer CSV- oder METS-
Datei in der vorgegebenen Ordnerstruktur importiert worden sind, zergliedert. Die
Dublin Core-Elemente werden unter einer generierten <dmdSec> mit MDTYPE=”DC”
eingefügt. Alle Elemente, die nicht mit DC ausgezeichnet sind, werden ebenfalls in
einer generierten <dmdSec> mit MDTYPE=”OTHER” OTHERMDTYPE=”CUSTOM”
in die METS-Datei überführt, welche jedem erstellten SIP im Transfer hinzugefügt
wird.50
Die Vergabe von eindeutigen Identifiern – UUID’s – sowohl für das gesamte
Transferpaket als auch für den Transferprozess und dessen Umbenennung sind
Grundlage für ihre Identifikation und die Verifikation von durchgeführten Prozessen
im Zusammenhang mit Objekten und Paketen im Archiv. Die gleichzeitige
Generierung von Checksummen für alle Objekte des Transferpakets ermöglicht die
Überprüfung von Integritätsverstößen an den digitalen Objekten. Mit dem
Microservice Verify transfer checksums können mitgelieferte Checksummen zum
Transfer im Metadatenordner auf Veränderungen kontrolliert werden.51 Zur
Dokumentation von Prozessen, die im Zusammenhang mit den digitalen Objekten ab
der Übernahme ablaufen, nutzt Archivematica den PREMIS-Standard.52
50
Vgl. Archivematica. Import metadata. URL: https://www.archivematica.org/en/docs/archivematica-1.4/user-manual/transfer/import-metadata/#compound-objects [14.02.2016]; Archivematica: Transfer. URL: https://www.archivematica.org/en/docs/archivematica-1.4/user-manual/transfer/transfer/#transfer [14.02.2016].
51 Vgl. ebd.
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].
33
Des Weiteren ermöglicht der Microservice Generate transfer structure report die
Erzeugung eines Berichts über die Ablagestruktur digitaler Objekte im TIP (Transfer
Information Package) und die Speicherung dessen als Textdatei im AIP, sodass die
Original-Struktur des Transferpakets auch mithilfe dieser strukturellen Metadaten
nachvollzogen werden kann und die Authentizität unterstützt wird. Die Microservices
im Transferbereich bieten aber vor allem die Möglichkeit, Dateiformate zu
identifizieren und zu validieren sowie technische Metadaten, die in Dateien
eingebettet sind, aus digitalen Objekten zu extrahieren. Aber auch ganze Pakete
können entpackt werden.53
Im Ingest besteht noch die Möglichkeit, den Objekten Metadaten hinzuzufügen,
sofern sie zuvor im Zugangssystem hochgeladen wurden. Dabei handelt es sich um
beschreibende und Rechte-Metadaten, die händisch in Felder eingegeben werden
können. Die Hinterlegung der beschreibenden Metadaten erfolgt in Dublin Core,
während für die Rechte-Metadaten PREMIS-Rights genutzt wird.54
53
Vgl. Archivematica: Transfer. URL: https://www.archivematica.org/en/docs/archivematica-1.4/user-manual/transfer/transfer/#format-identification [14.02.2016].
54 Vgl. Archivematica: Ingest. URL: https://www.archivematica.org/en/docs/archivematica-1.4/user-
manual/ingest/ingest/#ingest [14.02.2016].
34
Abbildung 10: Möglichkeiten der Hinzufügung von beschreibenden Metadaten mittels "Add metadata"55
55
Archivematica: Ingest. Image Metadataform1. URL: https://www.archivematica.org/en/docs/archivematica-1.4/_images/Metadataform1.png [14.02.2016].
35
Abbildung 11: Möglichkeiten der Hinzufügung von PREMIS-Rights-Metadaten56
Für den Anwendungsfall macht die Nutzung der Services allerdings keinen Sinn, da
angestrebt wird, die Prozesse zu automatisieren und den Personalaufwand in der
Koordinierungsstelle Brandenburg-digital so gering wie möglich zu halten. Zudem ist
eine Veröffentlichung und Nutzung der Digitalisate aus den Brandenburger
Einrichtungen nicht vorgesehen, es soll lediglich eine Rückgabe von Kopien an die
Einrichtungen erfolgen. Daher ist es nicht notwendig, bspw. Metadaten zum
Copyright, hinzuzufügen.
4.5 Erhaltung signifikanter Eigenschaften (AP 2)
In Archivematica können anhand eines preservation plan lediglich die signifikanten
Charakteristiken eines Dateiformats nach Medientypen analysiert und bestimmt
werden.57 Die Hinterlegung einer Format Policy in der Format Policy Registry (FPR)
56
Archivematica: Ingest. Image CopyrightNext. URL: https://www.archivematica.org/en/docs/archivematica-1.4/_images/CopyrightNext.png [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].
36
ermöglicht dies. Mittels Zuordnung der Dateiformate zu Medientypen und Tools zur
Normalisierung können Migrationsstrategien realisiert werden. Welche Medientypen
Archivematica in der Lage ist anhand der Dateiformate zu erkennen und welche
Tools zur Normalisierung, Extraktion und Formatidentifikation in Archivematica
implementiert werden können, zeigt folgende Tabelle:
Media type File formats Preservatio
n format(s)
Access
format(
s)
Normalization
tool
Audio AC3, AIFF, MP3, WAV, WMA WAVE
(LPCM) MP3 FFmpeg
Email PST MBOX MBOX readpst
Email Maildir** Original
format MBOX md2mb.py
Office Open
XML
DOCX, PPTX, XLSX Original
format
Original
format
Tool search in
progress
Plain text TXT
Original
format
Original
format None
Portable
Document
Format
PDF PDF/A Original
format Ghostscript
Presentatio
n files
PPT
Original
format PDF
Tool search in
progress
Raster
images
BMP, GIF, JPG, JP2*, PCT, PNG*, PSD, TIF
F, TGA
Uncompress
ed TIFF JPEG ImageMagick
Raw
camera
files/Digital
Negative
format**
3FR, ARW, CR2, CRW, DCR, DNG, ERF,
KDC, MRW, NEF, ORF, PEF, RAF, RAW,
X3F
Original
format JPEG
ImageMagick/UFR
aw
Spreadshe
ets
XLS
Original
format
Original
format None
Vector
images
AI, EPS, SVG SVG PDF Inkscape
Video
AVI, FLV, MOV, MPEG-1, MPEG-2, MPEG-
4, SWF,WMV
FFV1/LPCM
in MKV MP4 FFmpeg
37
Word
processing
files
DOC, WPD, RTF Original
format
Original
format
Tool search in
progress***
Tabelle 4: Format Policies58
(*) 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].
38
Abbildung 12: Grobe zu erstellende Ordnerstruktur zur Annahme des TIP’s in Archivematica
Unter /objects sollen die digitalen Objekte liegen und unter /metadata etwaige
Metadaten. Der Ordner /logs soll lediglich erstellt werden ohne Inhalt. Darin schreibt
Archivematica die Protokolldateien zu durchgeführten Prozessen hinein.60 In welcher
Form digitale Objekte und Metadaten mitgeliefert werden können, zeigt folgende
Übersicht:
Abbildung 13: Möglichkeiten zur Erstellung der Ordner- und Ablagestruktur von Objekten und Metadaten im TIP
Unter dem erstellten Ordner /objects besteht entweder die Möglichkeit, eine
Repräsentation des analogen Objekts (=Intellektuelle Entität) – z. B. in Form einer
PDF-Datei, die das analoge Objekt mit seinen Inhalten im Gesamten repräsentiert –
abzulegen, oder einen Unterordner mit Bezeichnung der Repräsentation zu erstellen,
der bspw. einzelne TIFF-Dateien (=Seiten des digitalen Objekts) auf Dateiebene
enthält, welche die Inhalte der Repräsentation wiederspiegeln und ihrerseits als
Repräsentationen zur Repräsentation „digitales Objekt“61 betrachtet werden können.
Die Wahl zwischen diesen beiden Ordner- und Ablagestrukturen des digitalen
60
Vgl. Archivematica: Transfer. URL: https://www.archivematica.org/en/docs/archivematica-1.4/user-manual/transfer/transfer/#create-transfer [14.02.2016].
61 Nur ohne Einbezug des analogen Objektes als Intellektuelle Entität, dann, wenn das digitale Objekt
als Intellektuelle Entität angesehen werden soll.
39
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].
63 Vgl. Archivematica: Transfer. URL: https://www.archivematica.org/en/docs/archivematica-1.4/user-
manual/transfer/transfer/#create-transfer [14.02.2016].
40
4.7 Testdurchläufe (AP 2)
Zur Nachvollziehbarkeit und Validierung der theoretischen Abläufe erfolgten mehrere
Testläufe mit einem Beispieldigitalisat aus dem Projekt Populare Schriftzeugnisse.
Ausgewählt wurde ein Liederbuch64 aus dem Kreis- und Verwaltungsarchiv
Havelland in Friesack, welches aus 49 Bilddateien im TIFF-Format besteht und eine
Gesamtgröße von 911MB aufweist.
Zuerst wurde mit Hilfe des METS-Editors eine METS-Datei erstellt und das
Liederbuch mit Dublin-Core Metadaten beschrieben. Da das Kreis- und
Verwaltungsarchiv Havelland keine eigene ISIL-Erkennungsnummer besitzt, wurde
zur Darstellung die ISIL des Kreisarchivs des Märkischen Kreises verwendet.65
Abbildung 14:TIP METS-Header und dmdsec
Die METS-Datei folgt dem standardmäßigen Aufbau eines XML-Dokuments und der
Einteilung in METS-typische Sektionen. Durch die Vergabe einer ObjectID (hier
“friesack_Liederbuch“) kann eine Identifizierung der METS-Datei erfolgen, wobei
selbst gewählt werden kann, wie diese ID gestaltet werden soll. So sind auch
laufende Nummerierungen möglich. Weiterhin ist die Funktion METS-Agent mit den
Typen Organization, Other-Software sowie Individuell ausdifferenziert und erlaubt
auch die Einbindung der ISIL-Kennung neben dem Organisationsnamen. Die
64
Kreis- und Verwaltungsarchiv Havelland: Liederbuch. URL: http://www.museum-digital.de/nat/index.php?t=objekt&oges=73639 [14.02.2016].
65 Zum Verfahren mit der ISIL-Nummer vgl. Kapitel 7.4.5.
41
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
47
Abbildung 22: AIP Unterverzeichnis /logs
Die METS-Datei des AIP’s vergrößert sich aufgrund der zahlreichen Tools auf eine
Größe von 1,7MB und kann aufgrund der sehr umfangreichen Angaben nur in den
wesentlichen Punkten analysiert werden. Insgesamt besteht die Datei aus einem
METS-Header, 51 amdSec’s, einer fileSec sowie der structMap. Die 52 amdSec’s
spiegeln die 49 Tiff-Dateien, die AIP-METS sowie die Transfer-METS wieder.
In der amdSec 1 findet unter tech_md die Analyse der METS.xml mittels der Tools
innerhalb von Archivematica statt. Technische Metadaten werden extrahiert und die
beschreibenden Metadaten in Dublin Core ausgelesen. Das Tool Tika scheint jedoch
die Felder nur unzureichend auslesen zu können, da diese uneinheitlich
wiedergegeben werden und so eine Weiterverwendung nicht möglich ist (vgl. Abb.
23). An anderer Stelle liest Exiftool diese Metadaten ebenfalls aus, jedoch noch
wesentlich unstrukturierter.
Extractor analysierten Inhalte siehe: ForensicsWiki: Bulk Extractor. URL: http://www.forensicswiki.org/wiki/Bulk_extractor [14.02.2016].
48
Abbildung 23: Dublin-Core mit Tika ausgelesen
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.
71 Servicestelle Digitalisierung: digiS – Servicestelle Digitalisierung Berlin, Berlin 2015. URL:
http://www.servicestelle-digitalisierung.de/confluence/pages/viewpage.action?pageId=917513 [14.02.2016].
50
preservation), sondern ebenfalls die Nachnutzbarkeit, Re-Kontextualisierung und
damit die Langzeitverfügbarkeit der Daten für verschiedene Nutzungsmöglichkeiten
möglich machen. Zur Übernahme der Daten werden zusammen mit den
Projektpartnern Workflows entwickelt.72
Im Jahr 2015 wurden neun Projekte im Rahmen des Förderprogrammes
durchgeführt. Um die Vielfalt der Arten von Informationsobjekten darzustellen, die in
den Kulturerbe-Einrichtungen digitalisiert werden, folgen drei Beispielprojekte: So
wurden in dem Projekt „Stiftung Topographie des Terrors – Dokumentationszentrum
NS-Zwangsarbeit II“ Briefe, Fotografien und Dokumente ehemaliger
Zwangsarbeiter/innen digitalisiert,73 im Rahmen des Projektes „Georg Kolbe Museum
III“ die Digitalisierung von Gipsmodellen im Museum unterstutzt74 und in dem Projekt
„Museum fur Naturkunde II“ eine Tierstimmensammlung des Bioakustikers Hans
Lütgen erschlossen und digitalisiert.75 Trotz der Vielfalt der Arten von
Informationsobjekten wird die Übernahme der Projektdaten in die
Langzeitarchivierung und Langzeitverfügbarkeit mit einem einzigen Workflow (single
core preservation workflow) abgedeckt.
Mit dem Förderprogramm verfolgt die Servicestelle Digitalisierung Berlin das Ziel,
„die Diversität des digitalen Kulturerbes in hoher Qualität zu bewahren und
gleichzeitig zum Zweck der Langzeitverfügbarkeit für Gesellschaft, Kultur, Forschung
und Wissenschaft dauerhaft zugänglich zu machen“.76
5.1 Vergleich der Funktionsarchitektur zum OAIS-Referenzmodell (AP 1)
Im Rahmen des Projekts konnten Informationen uber die Umsetzung der
Archivematica-Lösung im Zuse-Institut Berlin gewonnen werden. Im ZIB wird nicht
72
Vgl. Servicestelle Digitalisierung: digiS – Servicestelle Digitalisierung Berlin, Berlin 2015. URL: http://www.servicestelle-digitalisierung.de/confluence/pages/viewpage.action?pageId=917513 [14.02.2016].
73 Vgl. Servicestelle Digitalisierung: Stiftung Topographie des Terrors – Dokumentationszentrum NS-
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:
http://www.servicestelle-digitalisierung.de/confluence/display/DIG/Georg+Kolbe+Museum+III [14.02.2016].
75 Vgl. Servicestelle Digitalisierung: Museum für Naturkunde II. Berlin 2015. URL:
http://www.servicestelle-digitalisierung.de/confluence/pages/viewpage.action?pageId=8945806 [14.02.2016].
76 Vgl. Servicestelle Digitalisierung: Grundsätze zum Umgang mit Daten in der Servicestelle
Digitalisierung Berlin. Guidance Policy. Berlin 2014. S. 3.
51
allein auf Archivematica gesetzt, sondern einige Komponenten an andere
Programme ausgelagert. Im Folgenden werden die Funktionseinheiten einer OAIS-
konformen Lösung mit dem am Zuse-Institut Berlin vorgestellten verglichen:
Übernahme/Ingest Das ZIB nimmt eine Unterteilung des Ingest-Vorgangs in zwei Teile vor: Deposit (Pre-
Ingest) und Ingest. Im Deposit-Prozess verlaufen die Aufbereitung und der Transfer
der Daten als SIP in einen Quarantäne-Bereich. Dort werden Administrative
Informationen (Submission Manifest), deskriptive Informationen (Mapping auf
Metadatenformate Dublin Core (DC), MODS (Metadata Object Description Schema),
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].
78 Vgl. ebd., S. 4f.
79 Vgl. ebd., S. 4.
53
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].
54
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].
55
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].
57
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].
Phase Tätigkeit
1. Data Deposit Registration
Aufbereitung der digitalen Objekte
Beantragung eines Identifiers im
Webportal
Hinzufügen von PDI, manuell oder im
submission manifest
2. Data Transfer
Upload in staging area
3. Submitting and Compliance Test
Überprüfung auf vorhandene PDI und DI
Integritätsprüfung
4. Restructuring
Strukturierung in ein oder mehrere SIP’s
Extraktion und Mapping der DI
Tabelle 5: Pre-Ingest am ZIB
58
6. Empfehlungen zur technischen & personellen Umsetzung
6.1 Hardwareanforderungen an eine lauffähige Archivematica-Installation
(AP 1)
Die derzeitige Installation auf den beiden Testsystemen in der FH Potsdam entspricht
lediglich den Minimalanforderungen, die Artefactual nur fur kleine Testsysteme
empfiehlt:
Minimalanforderungen:
Processor: Dual Core+ CPU
Memory: 2GB+
Disk space: 7GB plus the disk space required for the collection
Empfohlen:
Processor: dual core i5 3rd generation CPU or better
Memory: 8GB+
Disk space: 20GB plus the disk space required for the collection.84
An der FH Potsdam wird derzeit ein Intel Core 2 Duo-Prozesser mit 4x 2GB Ram und
2x 300GB RAID-Speicher eingesetzt. Dies erweist sich auch in Performancetests der
vorherigen Projektgruppe als problematisch da größere Testläufe mit mehreren TIFF-
Dateien nicht in angemessener Zeit abgeschlossen werden können.
Im Zuse-Institut-Berlin werden zur Verringerung der Hardware-Anforderungen die
Microservices von Archivematica parallelisiert und auf mehrere Rechner verteilt die
uber das Netzwerk miteinander verbunden. Dieser Verbund aus Rechnern bildet ein
Cluster und ermöglicht es, die benötigte Rechenzeit zu verringern.
Um eine Verbesserung der Performance zu erreichen, sollte auf eine aktuellere
Prozessorgeneration zuruckgegriffen werden. Ein Prozessor i5 der dritten Generation
sollte fur vertretbare Performance-Zeiten in einer Produktivumgebung Voraussetzung
sein. Ebenso entsprechen die 8GB Ram nur den minimal empfohlenen
Anforderungen fur Systeme die uber eine Testumgebung hinausgehen sollen.
84
Vgl. Archivematica: Installation. URL: https://www.archivematica.org/en/docs/archivematica-1.4/admin-manual/installation/installation/ [14.02.2016].
59
6.2 Personeller Bedarf (AP 1)
Anforderungsprofil und Anzahl der Mitarbeiter
Empfohlene Minimallösung:
min. 1 dauerhafter Betreuer (Idealfall: technisches und
informationswissenschaftliches Wissen)
min. 1 technischer Experte, extern oder intern, auf Bedarfsbasis
Für die Inbetriebnahme und Unterhaltung eines digitalen Archivs sind die Mitarbeiter
von zentraler Bedeutung. Benötigt werden sowohl technisch orientierte Experten
(Informatiker) als auch informationswissenschaftliche Mitarbeiter (Archivar etc.). Ideal
ist eine möglichst weitgehende Synergie zwischen diesen beiden
Anforderungsprofilen, um eine Abteilungsbildung zu verhindern. So müssen die
technischen Mitarbeiter nach Möglichkeit Kenntnis von der
informationswissenschaftlichen Konzeption des Archivs haben, während Archivare
auch technisches Wissen benötigen, um ihre Arbeit im System zu gewährleisten. Die
technische Betreuung des Archivs als professionelle Aufgabe wurde bislang zu
wenig berücksichtigt, weshalb eine technisch-informatische Fachkraft dringend
benötigt wird.
In einem minimal ausgestatteten digitalen Archiv ist jedoch zu erwarten, dass ein
einzelner Mitarbeiter diese Anforderungsprofile weitgehend in sich vereinen muss,
lediglich unterstützt durch eine teilweise Einbeziehung von externen oder internen
technischen Experten. Im vorliegenden Szenario des Pre-Ingest Systems an der
Koordinierungsstelle Brandenburg-digital entfällt der Großteil der technischen Arbeit
auf die Konzeption und Einrichtung des Systems, während der dauerhafte Betrieb
durch die (angestrebt) weitgehende Automatisierung im Vergleich weniger
Arbeitskraft binden wird. Es ist also vor allem zu Beginn erforderlich, mehrere
fachliche Perspektiven einzubeziehen. Im vorliegenden Anwendungsfall wirken
zudem Projektgruppen aus Studierenden unterstützend an der Konzeption des Pre-
Ingest Systems mit.
Nach der vollständigen Einrichtung ist eine Minimalbesetzung von einem
dauerhaftem Betreuer und einem technischen Berater auf Bedarfsbasis notwendig,
um den Betrieb des Pre-Ingest Systems zu gewährleisten.
60
Weiterbildung/Qualifizierung
Das Design von Archivematica, welches auf weitgehende Automatisierung der
erforderlichen Arbeitsschritte setzt, erleichtert das Erlernen des Umgangs mit dem
Programm. Wenn der wichtigste Schritt, die Einrichtung und Anpassung, erfolgreich
durchgeführt wurde, kann die Benutzung der Programmteile Transfer und Ingest
schnell erlernt werden, da sich die Bedienung des Programms nah am Workflow der
digitalen Archivierung orientiert. Der Hersteller bietet selbst keine
Weiterbildungsmaßnahmen an, es muss also auf Grundlage der Dokumentation oder
durch persönliche Einarbeitung ein entsprechender Wissensstand erreicht werden.
Der Umfang der erforderlichen Weiterbildungsmaßnahmen basiert maßgeblich am
Nutzungsszenario, vor allem, in welchem Ausmaß ein automatisierter
Programmablauf erreicht werden kann. In jedem Fall wird aber eine
Einführungsphase notwendig sein, in dem die Mitarbeiter sich mit dem Programm
vertraut machen können. Auch beachtet werden müssen die Arbeitsschritte vor und
nach der Benutzung von Archivematica, die ebenfalls eine Qualifikation benötigen.
6.3 Institutioneller Bedarf: Raum und Netzwerk (AP 1)
Empfohlene Minimallösung:
niedriger Raumbedarf für Server + Netzwerkspeicher, idealerweise aber
getrennt
min. 2 Arbeitsplätze für die Mitarbeiter, regulärer PC + Monitor ausreichend
Netzwerkverbindung zwischen Server, Netzspeicher und Arbeitsplätzen
Internetverbindung standardmäßig vorgesehen, benötigt Absicherung
(Firewall)
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].
62
6.4 Aufwandseinschätzung: Installation und Einrichtung von Archivematica
(AP 1)
Neben den benötigten Ressourcen und institutionellen Voraussetzungen lohnt sich
auch ein Blick auf den voraussichtlichen Aufwand der Installation und Einrichtung
aller benötigten Systeme. Tatsächlich sind diese Arbeitsschritte wesentlich
komplexer und zeitaufwendiger, als das bei vergleichsweise kleinen Open-Source-
Programmen zu erwarten wäre. Des Weiteren können bereits an diesem frühen
Schritt kritische Fehler entstehen, wie aus Testläufen zur Einrichtung ersichtlich
wurde.
Installation
Geschätzter Zeitaufwand: 3-5 Tage
Archivematica steht als Open-Source-Distribution kostenlos zur Verfügung. Es
müssen zudem keine Lizenzen vereinbart werden, was den Aufwand der Einführung
reduziert. Die Installation muss mit mehreren Arbeitstagen veranschlagt werden, da
neben dem eigentlichen Programm auch die Linux-Distribution Ubuntu einberechnet
werden muss. Die Installation des Systems muss in zwei Teilen betrachtet werden:
dem Einrichten eines Linux-Systems und der Installation von Archivematica. Die
Anpassung der Komponenten von Archivematica und die Einbindung des
Speichermediums sind ebenfalls zu berücksichtigen.
Einrichtung des Linux-Systems und Installation von Archivematica
Archivematica ist für den Betrieb in einem Linux-System vorgesehen. Linux ist ein
kostenloses Betriebssystem, welches in vielen Variationen angeboten wird. Die
Neueinrichtung eines Linux-Systems konnte von der Projektgruppe nicht getestet
werden, jedoch ergaben sich beim Betrieb Probleme mit der Programminstallation
und Updates. Daraus wird ersichtlich, dass die Einrichtung und Wartung von Ubuntu
bereits eine ernst zu nehmende und wichtige Aufgabe ist, die zur Wahrung der
Stabilität des späteren Systems intensiver bearbeitet werden muss.
63
Nach der Einrichtung von Ubuntu ist die Installation des eigentlichen Archivematica-
Programms der nächste Schritt. Die Installation kann nach der offiziellen Anleitung86
aus dem Ubuntu-System gestartet werden (Internetverbindung vorausgesetzt). Es
handelt sich um mehrere Pakete (Server, Client, Dashboard, ElasticSearch), die in
ihrer Gesamtheit das System bilden. Nach dem Download müssen mehrere
Bestandteile, vor allem der Storage Service, manuell eingerichtet werden. Darunter
fällt die Einbindung von Speichermedien, die zur dauerhaften Speicherung der
Archivpakete genutzt werden sollen. Die Einrichtung des Storage Services ist eine
Fehlerquelle, die im Projektverlauf zu Problemen führte.
Anpassung des Systems
Geschätzter Zeitaufwand: min. ein Monat
Der wohl ressourcenintensivste Schritt bei der Einführung von Archivematica ist die
erforderliche Anpassung des Systems an das eigene Nutzungsszenario. Nicht nur
bietet das Programm weitreichende Optionsmöglichkeiten, es ist auch konzeptionell
notwendig, das vorliegende Distributionspaket anzupassen. Dies trifft besonders auf
den Storage Service, die Suchfunktion (Datenverwaltung) und den Zugriff zu.
Der bereits erwähnte Storage Service ist eine Komponente des Archivematica-
Systems, in dem die Speicherorte der wichtigsten Archivpakete festgelegt werden.
Die Einrichtung dieses Services findet getrennt von der eigentlichen
Benutzeroberfläche statt und verfügt auch über eine eigene Benutzerverwaltung. Von
maßgeblicher Bedeutung ist allgemein der Speicherort der AIP‘s. Im Rahmen des
Szenarios, der Einrichtung eines Pre-Ingest Systems, muss aber vor allem das
sogenannte backlog der SIP‘s betrachtet werden. Archivematica sieht die
standardmäßige Benutzung der SIP‘s eigentlich nicht vor, durch einen Befehl am
Ende des Transfer-Schrittes können diese jedoch in ein bestimmtes Zielverzeichnis
gespeichert und von dort auch aus dem System exportiert werden. Es ist also zu
beachten, dass im Storage Service ein passender Speicherort für die
Informationspakete eingerichtet wird.
86
Vgl. Archivematica: Installation. URL: https://www.archivematica.org/en/docs/archivematica-1.4/admin-manual/installation/installation/#install-1-4 [14.02.2016].
64
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].
65
entspricht. Grundsätzlich wird jedoch eine Übernahme von METS-Dateien
angestrebt.
Es wird geschätzt, dass die komplette Umsetzung dieser technischen Bereiche mit
einem Monat veranschlagt werden muss, um auch Zeit für die Fehlerbehebung und
Testläufe einzurechnen.
Bedienung und Wartung im Betrieb
Geschätzter Zeitaufwand: dauerhaft
Archivematica kann nach einer entsprechenden Anpassung weitgehend
automatisiert die wichtigsten Arbeitsschritte durchführen. Die Arbeitsprozesse
können eingestellt werden, um den manuellen Aufwand zu einem Großteil zu
entfernen. Die tatsächliche Arbeit, die dauerhaft beim Betrieb des Systems entsteht,
basiert zu großen Teilen auf dem Anwendungsfall. Insbesondere stellen der Import
der Dateien in das System und der Export aus Archivematica heraus den potentiell
größten manuellen Aufwand dar. Dies wird auch im vorliegenden Anwendungsfall
des Pre-Ingest Systems deutlich, wo die manuelle Einführung der Digitalisate und
nach der Verarbeitung die Übersendung der Übernahmepakete nach Berlin die wohl
größten Quellen manueller Arbeit darstellen dürften, weshalb diese durch
Webanwendungen weitgehend automatisiert werden sollten.
Nicht vernachlässigt werden darf die technische Betreuung des Systems, die
dauerhaft notwendig ist. Aus dem Projektverlauf haben sich Probleme ergeben, die
aus dem langfristigen Betrieb des Systems ohne eine intensive Wartung entstanden
sind. Für das angestrebte System muss also durchgängig eine technische
Fehlerbehebung eingeplant werden. Vor allem das Updaten von Ubuntu und seinen
Bestandteilen und die evtl. daraus resultierenden Kompatibilitätsprobleme mit
Archivematica bedürfen einer ständigen Beobachtung.
6.5 Sicherheitskonzept (AP 1)
Beim Betrieb eines digitalen Archivs spielen Fragen der Sicherheit eine
entscheidende Rolle und zwar in jedem Bereich des Arbeitsprozesses. Die
Herstellung von Datensicherheit muss demnach bereits in der Konzeption umfassend
66
berücksichtigt werden, um die langfristige Archivierung aller dem Archiv anvertrauter
Daten zu gewährleisten. Im Mittelpunkt stehen vor allem zwei Bereiche, deren
Missachtung ein hohes Risiko für die Informationspakete darstellt: die Sicherheit auf
Systemebene (Archivematica) und auf infrastruktureller Ebene (Datensicherheit in
der Einrichtung).
Daten- und Paketebene
Die korrekte Erstellung von Archivpaketen durch Archivematica ist das erste große
Ziel des Arbeitsprozesses. Nur wenn die Daten ordnungsgemäß durch den Ingest
gelaufen sind, können weitere wichtige Schritte der digitalen Archivierung wie die
Metadatenübernahme und Formatumwandlungen in ein Archivformat gewährleistet
werden.88 Im Gegensatz zu den offensichtlichen Sicherheitsrisiken wie Hardware-
Fehlern sind Probleme bei der Erstellung der Archivpakete schwerer zu erkennen.
Archivematica arbeitet deswegen mit Fehlermeldungen, wenn es im Verlauf des
Transfers/Ingest zu Problemen gekommen ist. In der Regel wird der Vorgang
dadurch abgebrochen und muss nach Behebung des Fehlers erneut gestartet
werden. Leider bedeutet ein Durchlauf ohne Fehlermeldung nicht zwangsläufig, dass
der Ingest nach den Bedürfnissen des eigenen Nutzungsszenarios durchgeführt
wurde. Insbesondere die Metadatenübernahme wird vom Programm nicht als kritisch
betrachtet, so dass etwa fehlende Metadaten im Transferpaket nicht zum Abbruch
führen. Es müssen also vor der Verwendung intensive Testläufe durchgeführt
werden, um sicherzustellen, dass die Abläufe dem eigenen Nutzungsszenario
entsprechen und alle Metadaten und Arbeitsschritte korrekt durchgeführt werden.
Auch im Betrieb ist es angeraten, in regelmäßigen Abständen Kontrollen
durchzuführen, um etwaige Fehler zu finden und zu beheben.
Empfohlene Maßnahmen: regelmäßige Tests und Kontrollen der entstandenen SIP’s.
Infrastrukturelle Ebene
Wenn die Sicherheit der Daten im System gewährleistet ist, muss dennoch auch
beachtet werden, dass das System im Ganzen ebenfalls eine sichere Umgebung
benötigt. Ein fehlendes Konzept der Sicherheit der Institution kann zu einer
88
In diesem Anwendungsfall finden diese Schritte in der Lösung der digiS statt.
67
Gefährdung der Daten führen. Folgende Punkte müssen dabei besonders
berücksichtigt werden.
Archivematica speichert seine Archivpakete in Ordnern in vorher festgelegten
Zielverzeichnissen. Die Ordner sind weder verschlüsselt, noch in sonstiger Form vor
Zugriffen geschützt. Die Vorgaben der digitalen Archivierung erfordern diese direkte
Zugänglichkeit der Archivpakete, gleichzeitig entsteht dabei jedoch ein
Sicherheitsrisiko, weil jeder mit Zugriff auf den Speicherort die Datenintegrität ohne
Aufwand zerstören kann. Das gleiche gilt für den Zugriff auf das Archivematica-
System an sich, durch das auf die Daten zugegriffen werden kann. Es muss also
sichergestellt werden, dass keine unbefugten Personen Zugriff auf das System
bekommen. Entsprechende Maßnahmen umfassen neben der Zutrittskontrolle der
Räume auch den Netzwerk-/Internetzugang, an den die Systemkomponenten
angeschlossen sind. Gerade der Internetzugang stellt ein besonderes Problem dar,
da Angriffe auf die Systemsicherheit so durch einen Angriff auf den Server möglich
werden (Hacking). Archivematica sieht standardmäßig die Verbindung mit dem
Internet vor, wie aus dem Vorhandensein des Webclient als zentrale
Bedienoberfläche und dem Storage Service als Systemkomponente ersichtlich wird.
Die Behandlung von Formaten (Migration) basiert ebenfalls auf Zugriffen zu einem
Server (die Format Policy Registry). Auch der Upload zur firmeneigenen
Zugangsplattform AtoM setzt eine Internetverbindung des Systems voraus.
Es stellt sich damit die Frage, ob auf die Internetverbindung beim Betrieb von
Archivematica überhaupt verzichtet werden kann, da deutlich wird, dass zentrale
Bestandteile des Systems auf dem Zugang basieren. Zumindest im Testsystem ist
darum die sichere Isolierung des Systems nicht möglich. Es wird daher vorläufig
empfohlen, die grundsätzlichen Regeln der Netzwerksicherheit zu berücksichtigen,
darunter fallen der sensible Umgang mit Passwörtern und die ständige Kontrolle der
Serverintegrität.
Um das Problem des unberechtigten Zugriffs auf das System über das Netzwerk
oder das Internet zu beheben, wird die Einrichtung einer Firewall und eines Proxy-
Servers empfohlen. Bei der Firewall handelt es sich um eine softwarebasierte
Sicherheitslösung, die Zugriffe auf das System und aus dem System heraus reguliert.
68
Es wäre möglich, alle Zugriffe außerhalb der relevanten Bestandteile von
Archivematica und den Clienten auf den Arbeitsrechnern der Mitarbeiter
auszuschließen. Eine weitere Möglichkeit der Systemabsicherung im Netzwerk ist
das Einrichten eines Proxy-Servers. Darunter ist ein Server zu verstehen, der
zwischen das Netzwerk und dem Internet zwischengeschaltet wird und Anfragen des
Systems nach draußen und umgekehrt kontrolliert weiterleitet. Auf diese Art findet
keine direkte Kommunikation des Archivematica-Systems mit dem Internet statt, der
Zugriff auf vorher festgelegte Bereiche (wie der Format-Datenbank) bleibt aber
weiterhin möglich. Der Proxy-Server ist durch seine genau festgelegte Funktion als
Vermittlungskomponente besser vor Angriffen geschützt als das Archivematica-
System. Die Verbindung von einem Proxy-Server und einer Firewall stellt nach
aktueller Erkenntnis eine gute Sicherheitsumgebung für das System dar.
Die Einrichtung dieser Maßnahmen muss jedoch auf einer höheren Ebene erfolgen,
als die Installation der Programme. Dazu ist die Mithilfe der IT der FH Potsdam
notwendig. Es muss geprüft werden, welche konkreten technischen Maßnahmen für
die Einrichtung einer Firewall und eines Proxy-Servers nötig sind, um das
angestrebte Pre-Ingest System abzusichern.
Empfohlene Maßnahmen: standardmäßige Sicherheitsmaßnahmen
(Zugangskontrolle, sensibler Umgang mit Passwörtern), Einrichtung einer Firewall
und eines Proxy-Servers zur Regulierung der Zugriffe auf und aus dem System
Backup-Strategie
Eine weitere zu beachtende Gefahr sind eventuelle Ausfälle der Hardware,
besonders der Speichermedien. Durch die Anfälligkeit und der begrenzten
Lebensdauer von Speichermedien müssen auch Backups ein integraler Bestandteil
des Sicherheitskonzeptes sein. Nur durch die dauerhafte redundante
Speicherung/Sicherung der Daten kann im Problemfall garantiert werden, dass sich
die Informationspakete wiederherstellen lassen. Archivematica bietet selbst keine
Backup-Funktionen an (lediglich können bereits vorhandene Backups wieder in das
System eingebunden werden), es muss also konzeptionell eine dauerhafte Strategie
zur Erstellung und Bewahrung von kopierten Archivpaketen erarbeitet werden. Die
69
Backupstrategie sollte neben den Archivpaketen auch das System an sich umfassen
(Archivematica-Installation).
Der Netzwerkspeicher, der als Speicherort für das System geplant ist, bietet mehrere
Festplatten im RAID-System, die Daten werden also bereits standardmäßig
redundant gespeichert. Darüber hinaus ist es aber notwendig, eine Sicherung
außerhalb des Geräts durchzuführen. Je nach Dateimenge der Sammlung, die sich
aus dem Use Case ergibt, können dazu externe Festplatten oder sogar ein weiterer
Netzwerkspeicher in Betracht kommen. Es ist zu empfehlen, die Backups in
regelmäßigen Abständen durchzuführen und zwar nach Möglichkeit in einer
automatisierten Form, um Fehlerpotentiale bei der manuellen Bearbeitung
auszuschließen. Gleiches gilt für die notwendige Sicherung der Archivematica-
Installation bzw. der Systemfestplatte im Hauptserver. Hier bietet sich eine
Spiegelung der Festplatte an, um im Problemfall das System in einem älteren,
stabilen Zustand wiederherzustellen.
Empfohlene Maßnahmen: regelmäßige, möglichst automatisierte Sicherung der
Transferpakete und des Systems auf externen Speichermedien
6.6 Anforderungen an eine Web-Anwendung (AP 2)
Eine Web-Anwendung wird im Wesentlichen dazu benötigt, eine einfache Abgabe
von TIP’s per Upload zu ermöglichen und zu dokumentieren, wer wann welches TIP
abgegeben hat. Die Dokumentation des Abgabeprozesses erfolgt schon indirekt
durch die Mitlieferung einer „submission-manifest.txt“ mit administrativen Metadaten
(vgl. Kapitel 4.6), welche jedoch nicht zur Unterstützung des Archivierungsprozesses
eingesetzt werden. Hinzuzufügen wäre also bei Abgabe in den Transfer noch ein
folgendes Mindestmaß an administrativen Metadaten:
Vor- und Nachname der abgebenden Person
Bezeichnung des Transferpakets: ISIL der abgebenden Einrichtung_Signatur
des analogen Schriftzeugnisses
Abgabedatum
Auszuführender Prozess: Transfer
70
Vorstellbar wäre es, die drei letzteren Metadaten automatisch vom System
generieren zu lassen, insbesondere die Bezeichnung des Transferpakets aus der
Dateibenennung des TIP’s zu extrahieren und in ein Metadatenfeld zu uberfuhren.
Lediglich der Vor- und Nachname der abgebenden Person müsste händisch vom
Mitarbeiter der Einrichtung eingetragen werden. Die Abgabe des Transferpaketes in
den Transfer lässt sich mit PREMIS am besten abbilden und in die
Prozessdokumentation von Archivematica – auch im PREMIS-Standard –
integrieren.
Vor dem Auslösen der Abgabe, wenn die administrativen Metadaten hinzugefügt
wurden, wäre es sinnvoll, ein Compliance-Test im Hinblick auf die Einhaltung der
durch Archivematica vorgegebenen Ordnerstruktur durchzuführen, damit es bei
Nichteinhaltung nicht zu unnötigen Hochladeaktionen und Problemen beim Workflow
kommt, die mit Beratungsaufwand für die Koordinierungsstelle Brandenburg-digital
verbunden sind. Um den Aufwand zu verringern, könnte über die Web-Anwendung
bei Nichteinhaltung der vorgegebenen Ordnerstruktur eine automatische Nachricht
mit einer Fehlermeldung vom Computer gesendet werden. Die Verantwortung für die
Richtigkeit der Ordnerstruktur bleibt dabei bei der abgebenden Einrichtung.
Eine weitere Anforderung an die Web-Anwendung ist es – zur Vorbereitung der
Integritätsprüfung im Archivematica-Transfer – für jede digitale Datei des Objekts
MD5-Dateien mit Prüfsummen zu erzeugen und im Paketordner /metadata
abzulegen, sodass Archivematica in der Lage ist, auf die MD5-Dateien
zurückzugreifen, wenn die Validierung ausgeführt wird. Diese Funktion stellt die
fehlerfreie Übertragung des TIP’s sicher.
Des Weiteren sollte die Web-Anwendung über eine automatische Erstellung von
Einlieferungsbelegen verfügen, um den erfolgreichen Upload zu bestätigen und die
Koordinierungsstelle selbst keine Bestätigungen aussenden muss.
Um den Ruckgabeprozess der AIP‘s zu vereinfachen und zu automatisieren, könnte
die Web-Anwendung auch als Schnittstelle fur die Ruckgabe der AIP’s dienen. Mit
einem Button „AIP-Anforderung senden“ könnten die Einrichtungen die Rückgabe in
Form von AIP’s durch das automatische Senden einer E-Mail an eine hinterlegte
Adresse anfordern – unter Angabe des Titels des AIP’s oder Identifiers. Sinnvoll wäre
71
es auch, eine Schnittstelle zum Repository FEDORA in Berlin zu schaffen, um eine
einfache, schnelle und unkomplizierte Rückgabeform zu bieten.89
Weiterführende Funktionen werden bereits durch den Transfer und Ingest von
Archivematica abgedeckt, wie die Extraktion beschreibender und technischer
Metadaten aus dem Objekt oder der Metadatendatei und die Generierung von
technischen Metadaten zur Langzeitarchivierung mittels Formatidentifikation und –
charakterisierung.
6.7 Übernahme-Tools (AP 2)
Das OAIS-Referenzmodell beschreibt den Ingest als diejenige Funktionseinheit,
indem der Produzent ein SIP an das digitale Archiv übergibt. Wie das geschehen
soll, wird an dieser Stelle nicht näher spezifiziert. Aufgrund der heterogenen
Datenbestände beim Produzenten bzw. sehr unterschiedlichen Ausgangslagen im
Bereich der personellen, finanziellen und technischen Ausstattung, entwickelten viele
Gedächtnisinstitutionen eigene Software für die Aufbereitung und Abgabe von
Informationspaketen, sog. (Pre-)Ingest-Tools.
Anhand der gestellten Anforderungen wurden verschiedene Softwareprodukte
getestet, die die Funktion des Ingest unterstützen. Beispielhaft werden im Folgenden
vier davon kurz umrissen, und auf ihre Kompatibilität mit den Projektanforderungen
verglichen: METS-Editor, docuteam packer in Verbindung mit dem Tool SIP Creator,
IngestList, EDIAKT-Packer und Package Handler.
SobekCM METS-Editor
Der SobekCM METS-Editor90 wurde von der University of Florida Libraries und der
Digital Library of the Caribbean als Open-Source-Tool entwickelt und liegt derzeit in
der Version 1.1.0 vom Juli 2013 vor. Es dient dazu, für vorhandene Bestände eine
wohlgeformte METS-Datei zu erstellen und bereits existierende zu bearbeiten. Die
Software ist in der Programmiersprache C# geschrieben und kann als vollwertiges
Programm ausgeführt werden, aber auch über die Kommandozeile automatisiert im
Hintergrund laufen. Der Quellcode ist frei verfügbar,91 des Weiteren gibt es ein
89
Die Rückgabe wird in Kapitel 8: Workflows von der digiS durchgeführt dargestellt. 90
http://sourceforge.net/projects/metseditor/ [31.12.2015]. 91
http://sourceforge.net/projects/metseditor/files/ sowie auch: https://github.com/MarkVSullivan/SobekCM-METS-Editor/tree/master [17.01.2016].
72
Benutzerhandbuch für die Version 1.0.1.92 Eine große Stärke des METS-Editors ist
die Anzahl an verwendbaren Metadatenstandards. Folgende Standards sind als
Primärschema verwendbar:
Dublin Core
MARCXML
MODS
Des Weiteren sind auch der Import und die Transformation verschiedener Formate
möglich:
CSV bzw. Excel-Datei
Dublin Core
EAD
MARC (MARCXML und MARC 21)
MXF
Z39.50
Weiterhin ist auch der Import von Metadaten aus dem Protokoll OAI-PMH möglich.
Diese Funktionen machen den METS-Editor zu einem hervorragenden Werkzeug für
kleine und mittlere Einrichtungen, ohne größere technische Infrastruktur. Vorhandene
Metadaten werden automatisch importiert, fehlende Informationen können manuell
hinzugefügt werden (vgl. Abb. 26). Auch die im METS-Header angegebenen
Metadaten zur abgebenden Einrichtung werden nach einmaliger Eingabe
automatisiert übernommen. Weiterhin lässt sich in der Schaltfläche Structure Map die
Struktur des ausgewählten Ordners nachvollziehen. Alle enthaltenen Dateien werden
aufgelistet und lassen sich über Outer Divs weiter strukturieren. Ebenso ist das
Hinzufügen von weiteren Dateien möglich sowie die Vergabe einer Prüfsumme für
die einzelnen Dateien in MD5. Der METS-Editor ist durch Add-ons, welche bei der
Ersteinrichtung bestimmt werden können, noch erweiterbar. Dadurch ist bspw. eine
genauere Beschreibung von bibliografischen und anderen Informationen oder auch
die Aufnahme von digitalen Dissertationen möglich.
Nach der Auszeichnung aller benötigten Felder lässt sich eine METS-Datei im
ausgewählten Ordner erstellen. Der Aufbau folgt dem üblichen METS-Dokument. Als
problematisch lässt sich der scheinbar fehlende Support bezeichnen, da viele
92
Digital Library of the Caribbean: SobekCM METS Editor Users Guide. URL: http://dloc.com/UF00103089/00003 [14.02.2016].
73
Internetressourcen nicht mehr verfügbar sind und das Projekt dementsprechend nicht
mehr fortgeführt wird.
Abbildung 26: Oberfläche des METS-Editors in Dublin Core
Mit dem METS-Editor können zur Sicherstellung der Integrität zwar Prüfsummen
generiert werden, jedoch gibt es keine Möglichkeit, diese in einzelnen Dateien zu
speichern. Die Prüfsummen werden lediglich in die METS-Datei hinein geschrieben:
Abbildung 27: Abgelegte MD5-Prüfsummen in der Filesection der erstellten METS-Datei
74
Fällt die Wahl auf den METS-Editor, um eine METS-Datei zu erstellen, ist daher zu
berücksichtigen oder darauf zu achten, dass eine ergänzende Web-Anwendung die
Vergabe von Hashwerten ermöglicht.
docuteam packer
Der docuteam packer93 der gleichnamigen Firma Docu Team dient dazu,
Informationspakete für die Einlieferung in ein digitales Archiv zu erstellen, zu
strukturieren und zu verändern. Die Software ist für die gängigen Betriebssysteme
ausgelegt und mit einer Open-Source-Lizenz verfügbar. Die Bedienung gestaltet sich
durch die einfach gehaltene Oberfläche recht intuitiv, kann jedoch auch über die
Kommandozeile bedient werden.94
Abbildung 28: Oberfläche des docuteam packer
In der Erstansicht erscheinen eine Übersicht der bereits bearbeiteten Pakete sowie
das Menü. Es ist möglich, ein neues TIP zu erstellen oder eine Vorlage aus bereits
vorhandenen Paketen zu nutzen, womit bspw. die Ordnerstruktur übernommen wird.
Weiterhin ermöglicht der packer die Prüfung eines Submission Agreements
(Übernahmevereinbarung), welche auf einem Server hinterlegt wurde. TIP’s lassen
sich so bereits im Vorhinein strukturell prüfen.
Nach Auswahl einer Datei oder eines Verzeichnisses erscheint die erweiterte
Ansicht, indem das Paket weiter bearbeitet wird. Die angezeigte Struktur lässt sich
neu anordnen oder weitere Objekte/Verzeichnisse hinzufügen. Daneben sind für die
jeweiligen Objekte technische Eigenschaften verfügbar. Ereignisse wie die Erstellung
und Bearbeitung werden protokolliert und später in PREMIS ausgegeben. Weiterhin
93
https://wiki.docuteam.ch/doku.php?id=docuteam:packer [14.02.2016]. 94
Vgl. Docu Team Wiki: docuteam packer starten und konfigurieren. URL: https://wiki.docuteam.ch/doku.php?id=docuteam:packer_220_config [14.02.2016].
75
lässt der packer die inhaltliche Beschreibung von Objekten mit EAD zu. Nach
Fertigstellung des TIP’s speichert das Programm das Informationspaket mit einer
METS.xml (vgl. Abb. 29). Neben der Erstellung einer METS-Datei ist auch der Export
der beschreibenden Metadaten in eine EAD-Datei als auch in eine CSV-Datei
möglich sowie die Ausgabe in einer Auflistung als PDF.
In Bezug zu den gesetzten Anforderungen des Projekts erscheint das Abspeichern
von Ordnerstrukturen und das Überprüfen nach einer Übernahmevereinbarung
positiv. Auch die Generierung einer METS.xml mit eingebetteten PREMIS-Events,
ohne weitere Software nutzen zu müssen, ist ein Vorteil des docuteam packers.
Die beschreibendenden Metadaten hingegen sind jedoch nur im Metadatenstandard
EAD verfügbar, was die Software speziell auf Archive einschränkt. Da das Projekt
jedoch verschiedene Kultureinrichtungen betrachtet, sollte ein Tool weitere
Standards beherrschen können.
Abbildung 29: Paketansicht im docuteam packer
76
SIP Creator
Der ebenfalls von der Firma Docu Team betriebende SIP Creator95 ist eine
webbasierte Software zur Ablieferung von Informationspaketen an ein Archiv. Das
Tool ist mit seinen zwei Optionen Ablieferungsvereinbarung sowie Dateiauswahl sehr
einfach gehalten. Im Reiter Ablieferungsvereinbarung wird wiedergegeben, welche
Person, resp. welche Organisation, ein Informationspaket abgeben möchte.
Vordefinierte Ablieferungsvereinbarungen lassen sich hier als Datei beifügen, ebenso
wie Anmerkungen zur Abgabe (vgl. Abb. 30). Die Dateiauswahl erlaubt die
Zusammenstellung von Dateiordnern und einzelnen Dateien zu einem
Informationspaket. Bei der Speicherung des Pakets erstellt der SIP Creator im
Hintergrund Prüfsummen zur späteren Integritätskontrolle. Nach Auswahl der Ablage
kann eine automatische Übermittlung an das Archiv erfolgen, bzw. auch die lokale
Speicherung. Abschließend sendet die Software eine automatisch generierte
Nachricht an das Archiv über die erfolgreiche Abgabe. In Kombination mit dem
docuteam packer ist der SIP Creator eine gute Möglichkeit, erzeugte
Informationspakete zu übermitteln.
Abbildung 30: Oberfläche des SIP Creators
95
https://wiki.docuteam.ch/doku.php?id=docuteam:sip-creator [14.02.2016].
77
IngestList
Das Landesarchiv Baden-Württemberg entwickelte im Rahmen eines Konzepts zur
digitalen Archivierung das Werkzeug IngestList96 zur Unterstützung der Übernahme
von digitalen Objekten und stellte dieses 2009 öffentlich bereit. Für die Nachnutzung
durch andere Institutionen steht die Software, welche auf Java basiert, unter einer
GNU General Public License Version 2.0 zur Verfügung. Sie ist quelloffen und weiter
konfigurierbar.
IngestList wurde vor allem für die Übernahme von Fachverfahren entwickelt, schließt
jedoch andere Objekte oder Formate nicht aus. Im Wesentlichen führt die Software
eine Formatidentifikation und Formatcharakterisierung durch. Dabei bedient es sich
neben eigener Werkzeuge auch der Tools JHOVE und DROID und greift damit auf
die PRONOM-Datenbank zu, weshalb eine durchgängige Verbindung mit dem
Internet während der Nutzung erforderlich ist. Weiterhin können MD5-Prüfsummen
ermittelt werden, die sich, wie auch andere Metadaten, bei erneuter Überprüfung
durch IngestList validieren lassen. Die Protokollfunktion sichert dabei jeden
durchgeführten Prozess. Nach Abschluss erstellt die Software eine XML-Datei mit
den erhobenen und eingegebenen Metadaten sowie einer MD5-Datei auf gleicher
Verzeichnisebene, wie das Paket. Über eine FTP-Verbindung besteht die Möglichkeit
der direkten Abgabe an das Archiv.97
96
http://sourceforge.net/projects/ingestlist/?source=typ_redirect [27.01.2016]. 97
Vgl. Landesarchiv Baden-Württemberg: Landesarchiv Baden-Württemberg veröffentlicht kostenlose Software zur digitalen Archivierung. IngestList unterstützt die Übernahme, Validierung, und Bestandserhaltung digitaler Unterlagen, Stuttgart 2009. URL: http://www.landesarchiv-bw.de/web/49289 [14.02.2016].
78
Abbildung 31: erfasste Metadaten in IngestList
Für den vorliegenden Verwendungsfall eignet sich IngestList kaum. Die
Formatidentifikation und Formatcharakterisierung wird nicht benötigt, da diese
beiden Vorgänge in der Lösung der digiS innerhalb des Ingest geschehen und nicht
im Pre-Ingest (Transfer). Eine redundante Datenerhebung wird nicht benötigt.
Ebenso erstellt IngestList zwar eine XML-Datei, diese ist jedoch nicht im geforderten
METS-Format. Die Vorteile von IngestList sind hingegen die Konfigurierbarkeit, die
Erzeugung von Prüfsummen & deren Validierung sowie die Abgabe via FTP.
Wesentliche Anforderungen werden jedoch nicht erfüllt, weshalb IngestList für diesen
Anwendungsfall als nicht geeignet erscheint.
EDIAKT-Creator
Der elektronische Akt (ELAK) bildet in Österreich auf Bundesebene den Standard für
die Führung von Akten und Dokumenten. Um zwischen den unterschiedlichen
Systemen einen Austausch oder eine Übernahme zu gewährleisten, wurde der
Standard EDIAKT (Electronic Data Interchange Akt) entwickelt. Zur Unterstützung
solcher Vorgänge dient die Software EDIAKT-Creator.98 Mithilfe des EDIAKT-
Creators lassen sich Metadaten zum Geschäftsablauf von Dokumenten, Akten und
98
https://www.ag.bka.gv.at/at.gv.bka.wiki-bka/index.php/EDIAKT_-_Viewer [14.02.2016].
79
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.
82
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.
84
Abbildung 34: OAIS-Informationsmodell109
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].
85
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].
86
für den Austausch von digitalen Objekten zwischen Repositorien gedacht. Dieses
Metadatenzielformat für digitale Informationsobjekte wurde 2001 unter Förderung der
Library of Congress von der Digital Library Federation (DLF) erstellt, um die
Entwicklung von Tools und Services zum Informationsmanagement zu unterstützen
sowie den interoperablen Austausch digitaler Objekte zwischen unterschiedlichen
Einrichtungen (und auch Anbietern) zu vereinfachen. Das Schema besteht aus
mehreren Metadaten-Sektionen, die das digitale Informationsobjekt von seiner
Struktur, Form, Herkunft, Beschreibung, Veränderung und seinem Verhalten zu
anderen Objekten her näher spezifizieren und umreißen.114
Ein Vorteil von METS ist, dass unter der Sektion für beschreibende Metadaten
(<dmdSec>) Metadaten in verschiedenen interdisziplinären Standards (MARC,
MODS, EAD, VRA, DC, NISOIMG, LC-AV, TEIHDR, DDI, FGDC) per <mdWrap>-
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].
87
<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].
123 Vgl. DNB: Metadaten. URL: http://www.dnb.de/DE/Standardisierung/Metadaten/metadaten_node.html [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].
88
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].
90
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].
133 Vgl. Gartner, Richard; Lavoie, Brian: Preservation Metadata, S. 17. URL: http://www.dpconline.org/component/docman/doc_download/894-dpctw13-03 [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].
91
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].
92
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].
93
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].
94
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].
155 Vgl. Gartner, Richard; Lavoie, Brian: Preservation Metadata, S. 22. URL: http://www.dpconline.org/component/docman/doc_download/894-dpctw13-03 [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].
95
Bild rekonstruieren zu können, ohne die Integrität zu verletzen. Zur Bestimmung des
Bildwertes und der Qualität spielt die Kenntnis der Auflösung eine wichtige Rolle.
Dieses Metadatum befindet sich im MIX-Standard unter der Kategorie „Image
Capture Metadata“, d. h. unter den Metadaten, die als Kontextinformation des
Objekts zu den Langzeitarchivierungsmetadaten gehören und sich zumeist
automatisch in der Bilddatei befinden, wenn sie aus den Aufnahmegeräten exportiert
wurden. Die Bits pro Farbkomponente und Anzahl der Farbkomponenten pro Pixel
gelten als quantitativer Messwert für die Evaluation der Bildqualität, Schattierung und
Farbe.159 Auch ein Projekt des Masterstudiengangs Bibliotheks- und
Informationswissenschaft befasste sich im Jahr 2013 mit der Bestimmung der
signifikanten Eigenschaften von Fotokollektionen eines Fotografen und verwies auf
die Studie.160 Das InSPECT-Projekt brachte noch mehr Studien hervor, auch zur
Bestimmung der signifikanten Eigenschaften von digitalen Audioaufnahmen,
strukturiertem Text und E-Mails.161
Mittels der JHOVE-Formatcharakterisierung lassen sich die signifikanten
Eigenschaften in Form von Metadaten des NISO-MIX-Standards erzeugen. Das geht
aus den durchgeführten Experimenten der InSPECT-Studie mit JHOVE anhand von
GIF, JPEG und TIFF-Dateien hervor.162
Zu prüfen wäre, ob das FITS-Tool in Archivematica auch in der Lage ist, die
signifikanten Eigenschaften für Rastergrafiken im MIX-Standard zu generieren und
zu speichern. Falls nicht, ist zu empfehlen, das JHOVE-Tool im kompletten
Funktionsumfang in Archivematica zu implementieren.
7.4 Metadaten-Bestandsaufnahme und -Umsetzung
Im Folgenden soll die Entwicklung des Metadatenkonzeptes dargestellt werden.
7.4.1 Erfassung beschreibender Metadaten
Bevor die notwendigen, beschreibenden Metadaten zur Übernahme definiert wurden,
erfolgte eine Erfassung der vorhandenen Metadaten, anhand der mitgelieferten
159
Vgl. Montague, Lynn: Significant Properties Testing Report. Raster Images, S. 8, 10-11. URL: http://www.significantproperties.org.uk/rasterimages-testingreport.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].
161 Vgl. InSPECT Projekthomepage: Testing Reports. URL: http://www.significantproperties.org.uk/testingreports.html [14.02.2016].
162 Vgl. Montague, Lynn: Significant Properties Testing Report. Raster Images, S. 16-26. URL: http://www.significantproperties.org.uk/rasterimages-testingreport.pdf [14.02.2016].
96
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].
97
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].
169 Vgl. Archivematica. Import metadata. URL: https://www.archivematica.org/en/docs/archivematica-1.4/user-manual/transfer/import-metadata/#compound-objects [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.
99
/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].
100
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].
102
Abbildung 39: Deskriptive XMP-Metadaten
Dazu zählt der Dokumenttitel, der aus der Dateibenennung besteht. Die
Dateibenennung setzt sich aus dem Namen und Ort der abgebenden Stelle
(kreis_verwaltungsarchiv_havelland_friesack), dem Titel der Intellektuellen Entität
(anonymus_liederbuch), einer aus zwei Nummern bestehenden ID (id_469_0001)
sowie aus dem abschließenden Formatkürzel (.tif) zusammen. Des Weiteren sind
unter den deskriptiven Metadaten der Autor, also Ersteller des Digitalisats, und
Copyright-Informationen (Status und Hinweis) vorzufinden. Das Erstellungs- und
Änderungsdatum sowie die Bezeichnung der Anwendung, mit der das Bildobjekt
bearbeitet wurde, einschließlich der Formatbezeichnung bilden wichtige
Informationen über die Herkunft des digitalen Objekts:
103
Abbildung 40: Administrative XMP-Metadaten: Herkunftsinformationen
Hinterlegte Kameradaten und Informationen zur Aufnahme belegen bspw. die
ursprüngliche Ausgangsgröße, -ausrichtung und –auflösung und tragen zur
Erhaltung der Authentizität des digitalen Objekts bei.
Abbildung 41: XMP-Metadaten: Kameradaten
Allerdings fehlen Angaben zur Identifikation des Aufnahmegeräts, zumindest
Ausführung und Modell. Weiterhin integriert sind Metadaten zur Erstellungs- und
Bearbeitungshistorie in XMP mit Aktionen, Änderungsdaten und durchgeführten
Programmen.
104
Abbildung 42: XMP-Prozessmetadaten
Integrierte TIFF- und EXIF-Metadaten geben schließlich Aufschluss über die
formatspezifischen Metadaten, worunter sich auch die schon erwähnten signifikanten
Eigenschaften für digitale Bildobjekte nach der Studie von Lynn Montague befinden
(vgl. Kapitel 7.3.7 Anwendung).
105
Abbildung 43: Technische, formatspezifische Metadaten in XMP
7.4.4 Mitzuliefernde Digitalisierungsmetadaten
Als verpflichtend mitzuliefernde Metadaten, die im XMP-Format in die TIFF-Dateien
zu importieren sind, werden festgelegt, um den Kontext, die Herkunft und damit die
Authentizität des Bildobjekts in einer gewissen Qualität zu sichern:
Dokumenttitel, bestehend aus: ISIL-Nummer der Einrichtung_Signatur des
analogen Popularen Schriftzeugnisses_Seitenzahl laufende Nummer ab
0001.tif176
Autor: Hier ist der Ersteller des Digitalisats zu nennen
Die Erstellungs- und Bearbeitungshistorie mit
Ggf. Aktion
Erstellungsdatum
Änderungsdatum
und Ersteller (Person oder Anwendung).
Die Kamera- bzw. Scannerdaten mit
Bezeichnung der Kamera oder des Scangeräts, mit dem das analoge
Kulturgut aufgenommen wurde
176
Zur Erläuterung, warum die Benennung auf diese Weise erfolgt, vgl. Kapitel 7.4.5.
106
Modell: Modell der Kamera oder des Scangeräts, mit dem das analoge
Kulturgut aufgenommen wurde
Scandatum: Datum des Scans
Kompression: Name des Kompressionsverfahrens
Diese Metadaten unterstützen den Migrationsprozess, indem z. B. nach dem
Scandatum der nächste Migrationsprozess automatisiert bestimmt werden kann.
Informationen zum angewandten Komprimierungsalgorithmus ermöglichen das
erneute Entpacken und Anzeigen von Datenströmen.177
Zudem sind die inhaltsbezogenen signifikanten Eigenschaften von den Bildobjekten
mitzuliefern:
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 Pixel
Dokumenttitel und Autor müssen händisch in die entsprechenden Dublin Core-Felder
eingetragen werden. Der Rest wie die Erstellungs- und Bearbeitungshistorie und die
Kameradaten werden z. T. automatisch im Hintergrund von Photoshop generiert bzw.
die Kameradaten importiert. Die signifikanten Eigenschaften sind bereits in den
Aufnahmedaten enthalten.
Um eine Zuordnung zur Intellektuellen Entität und der abgebenden Einrichtung zu
gewährleisten, wird festgelegt, dass der Dokumenttitel bzw. die Dateibenennung aus
der ISIL-Nummer der Einrichtung, der Signatur des analogen Popularen
Schriftzeugnisses und der laufende Nummerierung der Seiten eines Schriftstücks
bestehen soll.
Weitere deskriptive und technische Metadaten können optional mit in die TIFF-
Dateien importiert werden. Diese werden dann im Ingest in Berlin mit Archivematica
extrahiert.
177
Vgl. Enders, Markus: Kap. 17.3 Bilddokumente, S. 15. URL: http://nestor.sub.uni-goettingen.de/handbuch/artikel/nestor_handbuch_artikel_422.pdf [14.02.2016].
107
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].
109
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].
110
Einrichtungen zuzuordnen und auf Plattformen für die Überführung in die DDB zu
präsentieren.182
Zusätzlich zur ISIL wird die Signatur des analogen Objektes in der ID verwendet, um
den eindeutigen Bezug zur Intellektuellen Entität zu schaffen, der die kontextuelle
Zuordnung des Paketes gewährleistet.
Der Recordstatus informiert darüber, in welchem Stadium sich der METS-
Erstellungsprozess befindet, und weist auf den Abschluss und Änderungen am
Dokument hin. LASTMODDATE, das Datum der letzten Aktualisierung der METS-
Datei, beweist vorgenommene Veränderungen am Dokument. Noch wichtiger als das
Aktualisierungsdatum ist das Erstellungsdatum und der Name des Mitarbeiters der
Einrichtung, der die METS-Datei erstellt hat, um bei Unzulänglichkeiten auf einen für
den Prozess verantwortlichen Mitarbeiter zurückgreifen zu können. Die Herkunft des
Transferpakets dokumentiert bereits die ID bzw. die Benennung des Transferpakets
mit der ISIL, sodass der Name der abgebenden Einrichtung nicht noch einmal als
CREATOR im METS-Header eingegeben werden muss. Jedoch relevant ist noch die
Information über die Erstellungssoftware (METS-Editor oder Archivierungssoftware
mit Exportfunktion), um den Entstehungskontext und die Umgebung zu erhalten.
Weitere administrative Metadaten sind beim Abgabeprozess des TIP’s hinzuzufugen,
um den Prozess der Abgabe zu dokumentieren. Welche Metadaten dabei benötigt
werden, ist bereits im Kapitel 6.6 aufgezeigt worden.
7.4.6 Übersicht mitzuliefernder Metadaten im TIP
Hier noch einmal eine Übersicht über die mitzuliefernden Metadaten im TIP mit
Angabe des Prozessbereiches, in dem die Metadaten anfallen:
Festgelegte, mitzuliefernde Metadaten Prozess-Bereich
Dokumenttitel: ISIL_Signatur_Seitenzahl Digitalisierung,
Scanerstellung
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].
111
Ggf. Aktion
Erstellungsdatum
Änderungsdatum
Ersteller (Person oder Anwendung).
Scanbearbeitung
Kamera- bzw. Scannerdaten mit
Bezeichnung der Kamera oder des Scangeräts
Modell
Scandatum
Kompressionsverfahren
Breite/Höhe des Bildes
Auflösung des Bildes
Bits pro Farbkomponente
Anzahl der Farbkomponenten pro Pixel
Digitalisierung
Recordstatus
LASTMODDATE
CREATEDATE
CREATOR: Typ Mitarbeiter oder Software
ID: ISIL_Signatur (=Pakettitel)
METS-Datei-Erstellung
Beschreibende Metadaten:
Titel
Laufzeit
Signatur
METS-Datei-Erstellung,
Mapping
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].
114
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].
115
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
„submission-manifest.txt“-Datei vertraglich zuordnen:
Abbildung 49: „submission-manifest.txt“-Datei
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].
117
ü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].
119
Abbildung 51: Zuordnungen zur Content Information
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].
121
Abbildung 53: OAIS-Informationsmodell193
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.
122
8. Darstellung der Workflows (AP 2)
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].
197 Vgl. ebd., S. 2.
198 Vgl. ebd., S. 4 - 6.
133
11. Zusammenfassung (AP 2)
In Anlehnung an den grundsätzlichen Aufbau des OAIS-Funktionsmodells und die
Abläufe innerhalb eines digitalen Archivs ist eine dem speziellen Anwendungsfall
entsprechende Pre-Ingest-Lösung für die Übernahme und Aufbereitung von
Digitalisaten Brandenburger Kultureinrichtungen entstanden:
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:
136
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.
137
Brandenburg-digital zum Pre-Ingest in Berlin zu schaffen. In dem Fall gilt es auch für
Archive und Museen zu prüfen, ob die Archivematica-Transfer-Lösung in der
Koordinierungsstelle für die TIP-Aufbereitung und SIP-Erstellung überhaupt benötigt
wird und nicht Tools und/oder eine Web-Anwendung dafür ausreichen – zumal die
installierte, technische Umsetzung im Gebäude der FH Potsdam nur den minimalen
Anforderungen entspricht, die zum Betrieb des Systems notwendig sind, und große
Mengen an digitalisiertem Kulturgut aus den Projekten der Koordinierungsstelle
Brandenburg-digital zur Übernahme in das Archivematica-System erwartet werden.
Der Betrieb des Archivematica-Systems erfordert den Ausbau der Speicherlösung
und eine redundante Haltung der Speicher für die Ausfallsicherheit. Organisatorisch
wird ein Informationswissenschaftler benötigt, der die Bedienung und inhaltliche
Ausrichtung von Archivematica übernimmt, sowie eine Person mit technischer
Expertise. Denn auch ein Ergebnis des Projekts ist, dass wir als
Informationswissenschaftler in der Netzwerk-Administration und Anpassung der
Systemumgebung schnell an unsere fachlichen Grenzen stoßen, weshalb eine
Weiterbildung oder externe Betreuung notwendig ist. Bezüglich der Sicherheit und
dem Schutz vor potentiellen Angriffen sollte die Anbindung an das Internet auf das
Notwendigste beschränkt werden – auf die Einrichtung eines Proxy-Servers bzw.
einer Firewall.
Die ganzen technischen und organisatorischen Erfordernisse zum Betrieb des
Systems bringen die Erkenntnis, dass ein hoher finanzieller und personeller Aufwand
seitens der Koordinierungsstelle Brandenburg-digital geleistet werden muss, um das
System aufrechtzuerhalten, und dafür einige Ressourcen benötigt werden. Auch
deshalb ist zu prüfen, ob es sich für den Aufwand lohnt, die Vorteile des
Archivematica-Systems für den Pre-Ingest zu nutzen. Anstelle von Archivematica
wäre es auch denkbar, Tools und/oder eine Web-Anwendung einzusetzen, die die
funktionellen Anforderungen an die Aufbereitung zum TIP oder SIP erfüllen und eine
Schnittstelle zur Lösung in Berlin bilden. Es bietet sich hier an, bereits bestehende
Tools, die individuell anpassungsfähig sind, dafür zu verwenden. Der docuteam
packer in Kombination mit dem SIP-Creator ist in der Hinsicht eine echte
Empfehlung. Der Ausbau zu einer Web-Anwendung mit Abgabe- und
Rückgabefunktion bietet sich hier an.
138
Insgesamt konnte durch das Masterprojekt im Wintersemester 2015/16 eine
Grundlage für den Ausbau zu einem tragfähigen und nachhaltigen Konzept
geschaffen werden, das die Langzeitarchivierung und –verfügbarkeit von
Digitalisaten für Brandenburger Kultureinrichtungen über die Koordinierungsstelle
Brandenburg-digital als Aggregator zur digiS Berlin ermöglicht.
139
12. Verzeichnisse
12.1 Abbildungsverzeichnis
Abbildung 1: Die neu eingebundene NAS mit dazugehörigen Ordnern für AIP, DIP,…
TIP etc……………………………………………………………………………………….16
Abbildung 2: Speicherlokationen auf der lokalen Festplatte (vorher)…………………16
Abbildung 3: Storage-Service von Archivematica mit den neuen Speicherorten der….
NAS (nachher) .......................................................................................................... 17
Abbildung 4: Storage-Bereich von Archivematica mit vollständigen UUID's…………19
Abbildung 5: Hierarchie der UUID's………………………………………………………19
Abbildung 6: Mikroprozesse in Archivematica .......................................................... 21
Abbildung 7: Archivematica - Dashboard.................................................................. 22
Abbildung 8: OAIS-Funktionsmodell ......................................................................... 23
Abbildung 9: Archivematica - Suche im Archivspeicher ............................................ 25
Abbildung 10: Möglichkeiten der Hinzufügung von beschreibenden Metadaten mittels
"Add metadata" ......................................................................................................... 34
Abbildung 11: Möglichkeiten der Hinzufügung von PREMIS-Rights-Metadaten ....... 35
Abbildung 12: Grobe zu erstellende Ordnerstruktur zur Annahme des TIP’s in………..
Archivematica ........................................................................................................... 38
Abbildung 13: Möglichkeiten zur Erstellung der Ordner- und Ablagestruktur von……...
Objekten und Metadaten im TIP ............................................................................... 38
Abbildung 14:TIP METS-Header und dmdsec .......................................................... 40
Abbildung 15: TIP filesec .......................................................................................... 41
Abbildung 16: TIP structmap .................................................................................... 41
Abbildung 17: Aufbau TIP ......................................................................................... 42
Abbildung 18: SIP amdSec ....................................................................................... 43
Abbildung 19: Aufbau SIP ......................................................................................... 44
Abbildung 20: AIP Oberverzeichnisse ...................................................................... 45
Abbildung 21: AIP Unterverzeichnis /objects ............................................................ 46
Abbildung 22: AIP Unterverzeichnis /logs ................................................................. 47
Abbildung 23: Dublin-Core mit Tika ausgelesen ....................................................... 48
Abbildung 24: Systemarchitektur im Zuse-Institut Berlin .......................................... 51
Abbildung 25: UML-Datenmodell der Informationspakete der digiS in Anlehnung an…
das OAIS-Modell ...................................................................................................... 55
140
Abbildung 26: Oberfläche des METS-Editors in Dublin Core .................................... 73
Abbildung 27: Abgelegte MD5-Prüfsummen in der Filesection der erstellten METS-
Datei ......................................................................................................................... 73
Abbildung 28: Oberfläche des docuteam packer ...................................................... 74
Abbildung 29: Paketansicht im docuteam packer ..................................................... 75
Abbildung 30: Oberfläche des SIP Creators ............................................................. 76
Abbildung 31: erfasste Metadaten in IngestList ........................................................ 78
Abbildung 32: Oberfläche des EDIAKT-Creators ...................................................... 79
Abbildung 33: Oberfläche Package Handler ............................................................. 80
Abbildung 34: OAIS-Informationsmodell ................................................................... 84
Abbildung 35: Submission manifest und Mapping in Berlin ...................................... 88
Abbildung 36: Überblick über das PREMIS-Datenmodell ......................................... 90
Abbildung 37: PREMIS-Metadaten als Teilmenge von……………………………………
Langzeitarchivierungsmetadaten .............................................................................. 91
Abbildung 38: Textdatei Submission Manifest der digiS ......................................... 100
Abbildung 39: Deskriptive XMP-Metadaten ............................................................ 102
Abbildung 40: Administrative XMP-Metadaten: Herkunftsinformationen ................ 103
Abbildung 41: XMP-Metadaten: Kameradaten ....................................................... 103
Abbildung 42: XMP-Prozessmetadaten .................................................................. 104
Abbildung 43: Technische, formatspezifische Metadaten in XMP .......................... 105
Abbildung 44: Beispiel einer erstellten Ausgangs-METS-Datei mit dem METS-Editor..
............................................................................................................................... 107
Abbildung 45: Übersicht der am Projekt beteiligten Einrichtungen mit einer ISIL-
Nummer .................................................................................................................. 109
Abbildung 46: TIP-Konzept ..................................................................................... 112
Abbildung 47: Zuordnung der "ead.xml"-Datei ........................................................ 114
Abbildung 48: ID's im Anwendungsfall und deren Zuordnung zu OAIS-
Informationsbestandteilen ....................................................................................... 115
Abbildung 49: „submission-manifest.txt“-Datei ....................................................... 116
Abbildung 50: Bestandteile der "mets.xml"-Datei ................................................... 117
Abbildung 51: Zuordnungen zur Content Information ............................................. 119
Abbildung 52: Zuordnung der Kameradaten zur Context Information ..................... 120
Abbildung 53: OAIS-Informationsmodell ................................................................. 121
Abbildung 54: Gesamtprozess Archivierung von Digitalisaten................................ 123
141
Abbildung 55: Workflow Digitalisierung................................................................... 124
Abbildung 56: Erstellung TIP .................................................................................. 126
Abbildung 57: Erstellung SIP .................................................................................. 127
Abbildung 58: Erstellung AIP .................................................................................. 129
Abbildung 59: OAIS-Funktionsmodell für die Berlin-Brandenburger Archivlösung . 133
12.2 Tabellenverzeichnis
Tabelle 1: Microservices im Transfer von Archivematica .......................................... 27
Tabelle 2: Microservices im Ingest von Archivematica ............................................. 29
Tabelle 3: Tool's innerhalb von Archivematica ......................................................... 32
Tabelle 4: Format Policies ........................................................................................ 37
Tabelle 5: Pre-Ingest am ZIB .................................................................................... 57
Tabelle 6: Übersicht mitzuliefernder Metadaten im TIP bei Abgabe an die
Koordinierungsstelle Brandenburg-digital ............................................................... 111
12.3 Literaturverzeichnis & Webressourcen
Adobe Systems Incorporated: XMP Specification, San Jose 2005. URL:
https://partners.adobe.com/public/developer/en/xmp/sdk/XMPspecification.pdf
[14.02.2016].
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, o. S. URL:
https://opus4.kobv.de/opus4-zib/frontdoor/index/index/docId/5663 [14.02.2016].
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. URL: http://dcevents.dublincore.org/IntConf/dc-
2015/paper/view/362/373 [14.02.2016].
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. URL:
http://dcevents.dublincore.org/IntConf/dc-2015/paper/view/355/389 [14.02.2016].
142
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), Berlin 2016
[Protokoll].
Archivematica: Access. URL: https://www.archivematica.org/en/docs/archivematica-
1.4/user-manual/access/access/#access [14.02.2016].
Archivematica: Archivematica 1.4 Dashboard. URL:
https://www.archivematica.org/en/docs/archivematica-1.4/_images/Dashboard.png
[14.02.2016].
Archivematica: Default access system. Upload-AtoM. URL:
https://www.archivematica.org/en/docs/archivematica-1.4/user-
manual/access/access/#upload-atom [14.02.2016].
Archivematica: ContentDM. https://www.archivematica.org/en/docs/archivematica-
1.4/user-manual/access/contentdm/#contentdm [14.02.2016].
Archivematica: Format Policy Registry. URL:
https://wiki.archivematica.org/Administrator_manual_1.0#Format_Policy_Registry_.2
8FPR.29 [14.02.2016].
Archivematica: Import metadata. URL:
https://www.archivematica.org/en/docs/archivematica-1.4/user-
manual/transfer/import-metadata/#compound-objects [14.02.2016].
Archivematica: Ingest. URL: https://www.archivematica.org/en/docs/archivematica-
1.4/user-manual/ingest/ingest/#ingest [14.02.2016].
Archivematica: Ingest. Image CopyrightNext. URL:
https://www.archivematica.org/en/docs/archivematica-
1.4/_images/CopyrightNext.png [14.02.2016].
Archivematica: Ingest. Image Metadataform1. URL:
https://www.archivematica.org/en/docs/archivematica-
1.4/_images/Metadataform1.png [14.02.2016].
Archivematica: Ingest. Store the AIP. URL:
https://www.archivematica.org/en/docs/archivematica-1.4/user-
manual/ingest/ingest/#store-aip [14.02.2016].
143
Archivematica: Installation. URL:
https://www.archivematica.org/en/docs/archivematica-1.4/admin-
manual/installation/installation/ [14.02.2016].
Archivematica: Microservices. URL:
https://www.archivematica.org/en/docs/archivematica-1.4/_images/Micro-service.png
[14.02.2016].
Archivematica: Suche im Archivspeicher. URL:
https://www.archivematica.org/en/docs/archivematica-
1.4/_images/SearchArchStor.png [14.02.2016].
Archivematica: Transfer. Formatidentifikation. URL:
https://www.archivematica.org/en/docs/archivematica-1.4/user-
manual/transfer/transfer/#format-identification [14.02.2016].
Archivematica: Transfer. URL: https://www.archivematica.org/en/docs/archivematica-
1.4/user-manual/transfer/transfer/#transfer [14.02.2016].
Archivematica: Upload DIP Metadata to Achivist’s Toolkit. URL:
https://www.archivematica.org/en/docs/archivematica-1.4/user-
manual/access/archivists-toolkit/#archivists-toolkit [14.02.2016].
Archivematica: web-based dashboard. URL:
https://www.archivematica.org/en/docs/archivematica-1.4/user-
manual/overview/dashboard/#web-dashboard [14.02.2016].
Archivematica-Wiki: Release 1.4. URL: https://wiki.archivematica.org/Release_1.4
[14.02.2016].
Archivematica-Wiki: Format policies, URL:
https://wiki.archivematica.org/Format_policies [14.02.2016].
Archivematica-Wiki: Microservices. URL: https://wiki.archivematica.org/Micro-
services [14.02.2016].
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_Pote
ntially_Sensitive_Information_on_a_Disk_Image [14.02.2016].
Brown, Adrian: Practical digital preservation. A how-to guide for organizations of any
size, London 2013.
144
Buchegger, Wolfgang: Digitale Archivierung. Methoden und Strategien der
Langzeitarchivierung in digitalen Bibliotheken, Saarbrücken 2012.
Caplan, Priscilla: PREMIS verstehen, aus dem Engl. von Tobias Beinert, Washington
2009 [2009]. URL:
http://www.loc.gov/standards/premis/understanding_premis_german.pdf
[14.02.2016].
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].
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%2
0Conference%20Proceedings%20Final.pdf [14.02.2016].
DCMI: DCMI Metadata Terms, o. O. 2012. URL:
http://dublincore.org/documents/dcmi-terms/ [14.02.2016].
Digital Library Federation: <METS>. Metadata Encoding and Transmission Standard.
Primer and Reference Manual, überarbeitete Version 1.6, o. O. 2010, download
METS-Primer-Datei unter URL: http://www.loc.gov/standards/mets/mets-
schemadocs.html [14.02.2016].
Digital Library of the Caribbean: SobekCM METS Editor Users Guide. URL:
http://dloc.com/UF00103089/00003 [14.02.2016].
Digitales Archiv Nordrhein-Westfalen: Portal, o. O. 2015. URL:
https://www.danrw.de/portal/ [14.02.2016].
Digitales Archiv Nordrhein-Westfalen: DA NRW Knotenstruktur, o. O. 2015 URL:
https://www.danrw.de/fileadmin/_processed_/csm_DA_NRW_geplante_Knotenstrukt
ur_cab017b7c2.png [14.02.2016].
DNB: Metadaten, Leipzig, Frankfurt/Main 2012. URL:
http://www.dnb.de/DE/Standardisierung/Metadaten/metadaten_node.html
[14.02.2016].
Docu Team Wiki: docuteam packer starten und konfigurieren. URL:
https://wiki.docuteam.ch/doku.php?id=docuteam:packer_220_config [14.02.2016].
145
DOI Handbook, o. O. 2015. URL:
https://www.doi.org/doi_handbook/1_Introduction.html [14.02.2016].
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).
ElasticSearch BV: Shield. URL: https://www.elastic.co/products/shield [14.02.2016].
ElasticSearch BV: Installing Shield. URL:
https://www.elastic.co/guide/en/shield/current/installing-shield.html [14.02.2016].
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. 8-18. URL:
http://nestor.sub.uni-
goettingen.de/handbuch/artikel/nestor_handbuch_artikel_422.pdf [14.02.2016].
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. 17-34. URL: https://www.fbi.fh-
koeln.de/institut/papers/malisbuch_2013/1_Engels.pdf [14.02.2016].
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. URL:
http://dcevents.dublincore.org/IntConf/dc-2015/paper/view/334/371 [14.02.2016].
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. URL:
http://www.lwl.org/waa-download/archivpflege/heft80/Heft_80_2014.pdf [14.02.2016].
FITS Projekthomepage: Standard metadata schemas. URL:
http://projects.iq.harvard.edu/fits/standard-metadata-schemas [14.02.2016].
ForensicsWiki: Bulk Extractor. URL: http://www.forensicswiki.org/wiki/Bulk_extractor
[14.02.2016].
146
Gartner, Richard; Lavoie, Brian: Preservation Metadata (2nd edition). DPC
Technology Watch Report 13-03 May 2013, York 2013. URL:
http://www.dpconline.org/component/docman/doc_download/894-dpctw13-03
[14.02.2016].
Gladney, Henry M.: Preserving Digital Information, Berlin 2007.
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].
Harvey, Ross: Preserving Digital Materials, 2. Aufl. [2005], Berlin, Boston 2012
(=Current Topics in Library and Information Practice).
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].
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. 1349-
1359. URL: http://1seminariopreservacaopatrimoniodigital.dglab.gov.pt/wp-
content/uploads/sites/19/2015/08/recurso_25.pdf [14.02.2016].
InSPECT Projekthomepage. URL: http://www.significantproperties.org.uk/index.html
[14.02.2016].
InSPECT Projekthomepage: Testing Reports. URL:
http://www.significantproperties.org.uk/testingreports.html [14.02.2016].
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].
147
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/Downlo
adListPar/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].
Keitel, Christian: DIMAG-Kooperationen. Konzept und aktueller Sachstand. Vortrag
auf dem nestor-Praktikertag am 17.06.2013 in Hamburg, Hamburg 2013. URL:
http://files.dnb.de/nestor/veranstaltungen/Praktikertag2013/2013-06-dimag-keitel.pdf
[14.02.2016].
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-277.
Keitel, Christian; Schoger, Astrid (Hrsg.): Vertrauenswürdige digitale
Langzeitarchivierung nach DIN 31644, Berlin 2013 [Kommentar].
Kooperativer Bibliotheksverbund Berlin-Brandenburg: Service „Langzeitarchivierung“,
Berlin 2015. URL: https://www.kobv.de/services/archivierung/lza/ [14.02.2016].
Koordinierungsstelle Brandenburg-digital: Die Digitale Präsentation von Kulturgut im
Land Brandenburg - Zusammenfassung. - http://www.fh-potsdam.de/fileadmin/fb-
informationswissenschaften/dokumente/fachbereich/Koordinierungsstelle_Brandenbu
rg-digital/konzept-zusammenfassung.pdf [14.02.2016].
Kreis- und Verwaltungsarchiv Havelland: Liederbuch. URL: http://www.museum-
digital.de/nat/index.php?t=objekt&oges=73639 [14.02.2016].
Krumeich, Kirsten: Die Sammlung Aschebücher. Qualitätssicherung in der
Digitalisierung. In: Bibliotheksdienst 47 (2013) 7, S. 507-522.
Krumeich, Kirsten: Virtuelle Rekonstruktion zerrissener Stasi-Unterlagen.
Problemstellungen, 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].
148
Landesarchiv Baden-Württemberg: Landesarchiv Baden-Württemberg veröffentlicht
kostenlose Software zur digitalen Archivierung. IngestList unterstützt die Übernahme,
Validierung, und Bestandserhaltung digitaler Unterlagen, Stuttgart 2009. URL:
http://www.landesarchiv-bw.de/web/49289 [14.02.2016].
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].
Museum-digital: 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=n
at&mtt=Populare%20Schriftzeugnisse [14.02.2016].
Mengel, Holly: Excel to EAD-XML to AT. The spreadsheet from heaven, 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,
2012. URL: http://clir.pacscl.org/wp-content/uploads/2009/07/PACSCL-Finding-Aids-
Spreadsheet-Guide.pdf [14.02.2016].
Montague, Lynn: Significant Properties Testing Report. Raster Images, 2010. URL:
http://www.significantproperties.org.uk/rasterimages-testingreport.pdf [14.02.2016].
Museum-digital: Populare Schriftzeugnisse. Projektbeschreibung. URL:
http://www.museum-
digital.de/themator/ausgabe/showthema.php?m_tid=488&tid=488&ver=nat
[14.02.2016].
Museum-digital: 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].
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.
149
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.
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].
National Science Foundation: Cyberinfrastructure Vision for 21st Century Discovery,
Arlington 2007. URL: http://www.nsf.gov/pubs/2007/nsf0728/nsf0728.pdf
[14.02.2016].
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].
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). URL: http://files.dnb.de/nestor/materialien/nestor_mat_16-2.pdf
[14.02.2016].
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].
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.
PIMTOOLS: PREMIS in METS Toolbox. URL: http://pim.fcla.edu/ [14.02.2016].
PREMIS Editorial Committee: PREMIS Data Dictionary for Preservation Metadata,
Version 3.0, 2015. URL: http://www.loc.gov/standards/premis/v3/premis-3-0-final.pdf
[14.02.2016].
150
Puhl, Johanna; Rau, Lisa: Kap. 3 Langzeitarchivierung. In: 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), S. 20-21.
Qin, Jian; Zeng, Marcia Lei: Metadata, London 2008.
Rost, Christine: 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/Downlo
adListPar/download_1.ocFile/Praesentation%20Rost.pdf [14.02.2016]
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].
Senatskanzlei – Kulturelle Angelegenheiten: Förderrichtlinie der Senatskanzlei –
Kulturelle Angelegenheiten zur Digitalisierung von Objekten des kulturellen Erbes
des Landes Berlin, Berlin 2015.
Servicestelle Digitalisierung: Übernahmevereinbarung, Berlin 2014. URL:
http://ewig.gfz-potsdam.de/wp-
content/uploads/2011/12/ZIB_Muster_Uebernahmevereinbarung.pdf [14.02.2016].
Servicestelle Digitalisierung: Grundsätze zum Umgang mit Daten in der Servicestelle
Digitalisierung Berlin. Guidance Policy, Berlin 2014. URL: http://www.servicestelle-
digitalisierung.de/objects/public/digiS_Leitbild_Guidance.pdf [14.02.2016].
Servicestelle Digitalisierung: digiS – Servicestelle Digitalisierung Berlin, Berlin 2015
URL: http://www.servicestelle-
digitalisierung.de/confluence/pages/viewpage.action?pageId=917513 [14.02.2016].
Servicestelle Digitalisierung: Georg Kolbe Museum III. Berlin 2015. URL:
http://www.servicestelle-
digitalisierung.de/confluence/display/DIG/Georg+Kolbe+Museum+III [14.02.2016].
Servicestelle Digitalisierung: Museum für Naturkunde II. Berlin 2015. URL:
http://www.servicestelle-
digitalisierung.de/confluence/pages/viewpage.action?pageId=8945806 [14.02.2016].
151
Servicestelle Digitalisierung: Stiftung Topographie des Terrors –
Dokumentationszentrum NS-Zwangsarbeit II, Berlin 2015. URL:
http://www.servicestelle-
digitalisierung.de/confluence/display/DIG/Stiftung+Topographie+des+Terrors+-
+Dokumentationszentrum+NS-Zwangsarbeit+II [14.02.2016].
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].
Staatsbibliothek zu Berlin: Deutsche ISIL-Agentur und Sigelstelle: Beantragung eines
neuen ISIL, Berlin 2013. URL: http://sigel.staatsbibliothek-berlin.de/beantragung/
[14.02.2016].
Staatsbibliothek zu Berlin: Deutsche ISIL-Agentur und Sigelstelle: Datenbank
Bibliotheken, Archive, Museen und verwandte Einrichtungen, Berlin 2015. URL:
http://sigel.staatsbibliothek-berlin.de/nc/suche/ [14.02.2016].
Staatsbibliothek zu Berlin: ISIL, Berlin 2013. URL: http://sigel.staatsbibliothek-
berlin.de/de/vergabe/isil/ [14.02.2016].
Thaller, Manfred (Hrsg.): Das Digitale Archiv NRW in der Praxis. Eine
Softwarelösung zur digitalen Langzeitarchivierung, Hamburg 2013.
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).
The Consultative Committee for Space Data Systems: Reference Model for an Open
Archival Information System (OAIS), Washington 2012 [Magenta Book]. URL:
http://public.ccsds.org/publications/archive/650x0m2.pdf [14.02.2016].
The Library of Congress: METS. An Overview & Tutorial, Washington 2011. URL:
http://www.loc.gov/standards/mets/METSOverview.v2.html [14.02.2016].
The Library of Congress: AudioMD and VideoMD. Technical Metadata for Audio and
Video, Washington 2013. URL: https://www.loc.gov/standards/amdvmd/index.html
[14.02.2016].
The Library of Congress: Development of the Encoded Archival Description DTD,
Washington 2013. URL: http://www.loc.gov/ead/eaddev.html [14.02.2016].
152
The Library of Congress: MIX. NISO Metadata for Images in XML Schema,
Washington 2015. URL: http://www.loc.gov/standards/mix/ [14.02.2016].
The Library of Congress: textMD. Technical Metadata for Text, Washington 2016.
URL: https://www.loc.gov/standards/textMD/ [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.
UNESCO: Guidelines for the preservation of digital heritage, Paris 2003. URL:
unesdoc.unesco.org/images/0013/001300/130071e.pdf [14.02.2016].
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. URL:
https://fedora.phaidra.univie.ac.at/fedora/get/o:245912/bdef:Content/get
[14.02.2016].
VdW-Arbeitskreis “Elektronische Archivierung“: Reference Model for an Open
Archival Information System (OAIS), o. O. 2010. URL:
http://www.wirtschaftsarchive.de/arbeitskreise/fachliche-arbeitskreise/elektronische-
archivierung/OAIS_Handreichung_2011_02_04.pdf [14.02.2016].
VdW-Arbeitskreis „Elektronische Archivierung“: Premis Handreichung, o. O. 2011.
URL: http://www.wirtschaftsarchive.de/arbeitskreise/fachliche-
arbeitskreise/elektronische-archivierung/PremisHandreichung.pdf [14.02.2016].
Weitzmann, John H.; Klimpel, Paul: Handreichung. Rechtliche Rahmenbedingungen
für Digitalisierungsprojekte von Gedächtnisinstitutionen, 2. geänd. Aufl., Berlin 2015.
URL: http://www.servicestelle-
digitalisierung.de/objects/public/HandreichungRecht2015_Webversion.pdf
[14.02.2016].
153
Anhang
Anhang 1: Struktur der TIP METS-Datei
Sektion in METS Funktion Beschreibung
METS-Header
Recordstatus Bearbeitung des
Records
abgeschlossen,
teilweise bearbeitet
oder Metadaten
aktualisiert
Lastmoddate Letzte Bearbeitung der
METS
ID Vergebener Identifier
Createdate Erstellungsdatum der
METS
METS-Agent
Organization Einrichtung, welche die
METS erstellte,
vergebener Identifier
(hier ISIL) sowie der
Name
Software Software, welche die
METS erstellte (hier
SobekCM)
Individual Mitarbeiter der
Organisation, welcher
die METS erstellte
dmdSec
Xmldata
dc:title etc. Beschreibende
Metadaten, hier in
154
Dublin Core
fileSec
Filegroup
fileID, mimetype,
checksumtype,
checksum, xLinkhref
Identifikation jeder
einzelnen Datei,
Vergabe einer
Prüfsumme,
Referenzierung durch
den Dateinamen
structmap
div ID, type, Label, Order Ordnung der TIFF-
Dateien in eine
Reihenfolge als Seiten
155
Anhang 2: Struktur der SIP-METS-Datei
Sektion in METS Funktion Beschreibung
Header Createdate
Agent Hier Archivematica
amdSec
digiprov_1 ingestion
digiprov_2 message digest
calculation
Ermittlung der
Prüfsumme
digiprov_3 Quarantine Quarantäne.
Aktualisierung der
Virendefinitionen
digiprov_4 Unquarantine
fileSec
Filegrp Hier zip-Datei als
Ganzes analysiert,
einzelne Dateien
bleiben
unberücksichtigt
structMap Original
structMap processed
156
Anhang 3: Struktur der AIP METS-Datei
Sektion in
METS
Funktion Beschreibung
Header Createdate Erstellungsdatum
amdSec_1
tech_md_1
tool_output
File_utility Erkennung des
XML-Formats
Exif_tool Auslesen der
beschreibenden
MD aus der
Transfer-METS
NLNZ
Metadata
Extractor
Pfadbeschreibung
OIS File
Information
Pfadbeschreibung
und Größe
OIS XML
Information
Erkennung des
Mimetype
Ffident Erkennung des
Mimetype
Tika Auslesen der
beschreibenden
MD
digiprov_1 Unpacking
digiprov_2 message
digest
calculation
Erstellung einer
Prüfsumme
digiprov_3 Virus check
digiprov_4 Format
Identification
(Fido)
157
digiprov_5 fixitiy check
digiprov_6 Premis Agent Preservation
System:
Archivematica
digiprov_7 Premis Agent repository code:
UAS Potsdam
digiprov_8 Premis Agent Archivematica
user PK
amdSec_2
Tech_md_2
Objectidentifier UUID
Algorithm sha256
rdf:Description
(Exitool)
Systemangaben,
IFD0, XMP, IPTC,
Photoshop, Exif,
ICC
digiprov_9 Unpacking
digiprov_10 message
digest
calculation
digiprov_11 Virus check
digiprov_12 Format
Identification
(FIDO)
digiprov_13 Validation
(JHOVE)
digiprov_14 fixity check
digiprov_15 Premis Agent Preservation
System
Archivematica
digiprov_16 Premis Agent repository code:
UAS Potsdam
digiprov_17 Premis Agent Archivematica
158
user PK
fileSec
fileGrp
structMap ID
div Label