SlideShare ist ein Scribd-Unternehmen logo
1 von 37
Downloaden Sie, um offline zu lesen
SIP specifications at the
DIMAG development group
Boris Kraut, Kai Naumann
Landesarchiv Baden-Württemberg
Stuttgart
I. Our SIP and archival culture
II. Our SIP and its technical environment
III. Our present SIP specifications
IV. Our future SIP specifications based on BagIt
Our SIP and archival culture
Policia
Bankmark
Libreria
Archivesia
Mathesia
Lawistan
Socialia
Medicinia Artslands
Biolopal
Publishland
On Archival Cultural Diversity
– let‘s see the professional
world as a continent
Libreria
imports:
ebooks
and
ejournals
other
Trade partners:
Publishland 95 %
Others 5 %
Icons from Silk Iconset by FamFamFam
Policia
Bankmark
Libreria
Archivesia
Mathesia
Lawistan
Socialia
Medicinia Artslands
Biolopal
Publishland
Policia
Bankmark
Libreria
Archivesia
Mathesia
Lawistan
Socialia
Medicinia
Artslands
Biolopal
Publishland
Archivesia
imports:
ebooks
files
films
images
databases
Trade partners:
All countries equally
Icons from Silk Iconset by FamFamFam
Our SIP and its technical
environment
Catalogues for archives are hierarchies
DIMAG SIPs are new components
for this hierarchy
Stability of reference
DIMAG asks for new catalogue records
Catalogue says: here they are!
DIMAG and catalogue IDs in sync forever!
CatalogueSW
DIMAGStorage
DIMAGDB
DIMAGServer
DIMAGIngestSource
SIP
Create catalogue metadata
time
Regular sync
Success
message
Add primary data
to storage
create objects
Success message
Report new catalogue objects with IDs
Process overview (simplified)
All metadata in the catalogue, some in DIMAG
Our present SIP specifications
Our spec and its commands
• https://dimag-wiki.la-bw.de/xwiki/bin/download/
%C3%96ffentliche+Software+und+Informationen/WebHome/Spezifikation_SOAP-Schnittstelle_320.pdf
Operation What it says
importDoc DIMAG (standalone instance), validate and ingest
these SIPs!
getForms DIMAG, ask the catalogue: Which descriptive forms do
you have (e.g. sound recordings, paper files, medieval
charters)!
getFields DIMAG, ask the catalogue: Show me the fields the
catalogue supplies (for e.g. sound recordings description)!
importDocAfis DIMAG, ingest the customized SIPs and create catalogue
entries (for e.g. sound recordings)!
What? Upload single files via Web GUI. Client SW for single SIP (folders)
with 1-5.000 files.
Client SW for file collections,
multiple SIPs
Where to? 1-10 files generate one AIP 10-10.000 files
generate one AIP
10-5.000 folders
generate equal numbers of AIPs
How? DIMAG Core Module via browser
access.
DIMAG IngestList client software,
SFTP access to Core Module.
DIMAG IngestTool client software,
SFTP and SOAP access to Core
Module, additional metadata.
Means to generate SIPs
19
Mapping your own SIPs with DIMAG IngestTool
• Input Elements – choose from CSV, XML, XLSX, TXT, file and folder
names
• Output Elements (DIMAG and catalogue software)
• Mapping Elements – choose from concatenation, datetime
conversions, simple math, string extraction, if-then
Title tag, simple concatenation
…
single file, optionally load DIMAG control file (XML)
folder with files, IngestList metadata file (XML), hashes
flat folder with files, DIMAG control file (XML), hashes
variants with different folder structure etc.
Status Quo: Multiple similar but distinct SIPs
…
single file, optionally load DIMAG control file (XML)
folder with files, IngestList metadata file (XML), hashes
flat folder with files, DIMAG control file (XML), hashes
variants with different folder structure etc.
Status Quo: Multiple similar but distinct SIPs
Our future SIP specifications
based on BagIt
Requirements/Layers
1. metadata
2. primary data
3. primary data file names
4. folder structure
5. additional metadata and process information
6. data integrity
7. SIP serialisation (single file package)
8. data compression
9. data encryption
10. data authenticity
1 2 3 4 5 6
DIMAG Control File ✓ ✓ (✓) (✓)
BagIt (✓) ✓ ✓ (✓) ✓
METS ✓ ✓ (✓) ✓
eCH-0160 ✓ ✓ (✓) ✓ ✓
Evaluating specs and technologies…
Req. 7-10
left out for
shortness
1. metadata
2. primary data
3. primary data file names
4. folder structure
5. additional metadata and process information
6. data integrity
TODO: The road to BagIt
• move IngestList metadata to DIMAG control file format
• define DIMAG specific metadata and structures
• normalization of file names
• process information/output of „worker“ tools
• …
• DIMAG KM understands its control file and every folder
structure it comes with, so it can use bagit even if it doesnt
have a deeper understanding
• make DIMAG KM understand and parse BagIt
• move all ingest tools to bagit format
• keep compatibility with old formats for 3.x branch of
DIMAG KM
BagIt future of DIMAG SIPs
BagIt Specification IETF RFC 8493 https://tools.ietf.org/html/rfc8493
DIMAG SIPs will be conforming to BagIt, with additional requirements
• fetch.txt not accepted
• required hash algorithms: SHA-512 (recommended), MD5, SHA-1, SHA-256,
required tag-manifest
• required DIMAG control.xml (importDoc SOAP Interface XML)
• required dimag Subfolder
• containing outputs of ingest microservices (today: identify, validate, transfer)
• (plus some minor requirements)
cf. https://gitlab.la-bw.de/dimag/public-info/-/blob/master/dimag-bagit.md
DIMAG BagIt example <base directory>/
├── bagit.txt
├── bag-info.txt
├── manifest-sha512.txt
├── tagmanifest-sha512.txt
├── control.xml
├── dimag/
│ ├── identify.xml
│ ├── identify/
│ │ ├── identify.1572814543125.xml
│ │ └── identify.1572814854436.xml
│ ├── validate.xml
│ ├── validate/
│ │ ├── validate.1572814896535.xml
│ │ ├── validate.1572814933255.xml
│ │ └── verapdf-report.txt
│ ├── testdevel.xml
│ ├── testgroups.xml
│ └── testcontrol.xml
└── data/
└── [payload files]
• control.xml is THE central metadata
storage
• worker output (e.g. identify.xml) is
currently for reference only, all vital
information is stored in control.xml
• usage of bag-info.txt (fields, where to
split information between control.xml
and bag-info.txt) is currently in discussion
1. Allgemeine Grundsätze
| 13 | SIP-Format bei der Deutschen
Nationalbibliothek | 10. November 2020
1.1 Es MUSS möglich sein, beliebige digitale
Objekte und Metadaten in ein Informationspaket
aufzunehmen.
Ja, beliebige Dateiarten und -formate.
1.2 Das Informationspaket DARF NICHT die
Mittel, Methoden oder Werkzeuge für den Ingest
einschränken.
Ja.
1.3 Das Paketformat DARF NICHT den logisch-
inhaltlichen Umfang der digitalen Objekte und
Metadaten definieren, die ein Informationspaket
bilden.
Ja, eine oder mehrere Dateien eines logischen
Objekts oder Teilobjekts.
1.4 Das Informationspaket MUSS skalierbar sein. Ja, keine logischen Einschränkungen, allerdings
evtl. technische.
1. Allgemeine Grundsätze
| 13 | SIP-Format bei der Deutschen
Nationalbibliothek | 10. November 2020
1.5 Das Informationspaket MUSS
maschinenlesbar und automatisierbar zu
verarbeiten sein.
Ja, Nutzung von XML-Datei mit Schema.
1.6 Das Informationspaket MUSS interpretierbar
sein, um eine auch für den Menschen inhaltliche
Deutung zu ermöglichen.
Ja, XML in Struktur und Inhalt lesbar.
1.7 Die Spezifikation des Informationspakets
MUSS offen und frei sein.
Ja, SOAP-Spec frei verfügbar.
1.8 Die Komplexität der Spezifikation eines
Informationspakets SOLL angemessen sein.
Ja.
| 13 | SIP-Format bei der Deutschen
Nationalbibliothek | 10. November 2020
2. Grundsätze zur Identifikation eines IP
2.1 Jedes Informationspaket MUSS einen im
archivierenden Archiv eindeutigen und
dauerhaften Identifikator haben oder erhalten
Ja, interne Objekt-ID.
2.2 Jedes Informationspaket SOLL einen
Identifikator besitzen, der global eindeutig und
dauerhaft ist.
Ja, externe Objekt-ID des angebundenen
archivischen Katalogsystems (Findmittelsystem).
2.3 Alle Teile eines Informationspakets SOLLEN
einen eindeutigen und dauerhaften Identifikator
haben.
Ja, als XML-Tagnamen.
3. Struktur eines IP
| 13 | SIP-Format bei der Deutschen
Nationalbibliothek | 10. November 2020
3.1 Das Informationspaket MUSS sicherstellen,
dass Daten und Metadaten logisch voneinander
getrennt sind.
Ja.
3.2 Die Struktur des Informationspakets SOLL die
Trennung verschiedener Arten von Metadaten
ermöglichen.
Ja.
3.3 Die Struktur des Informationspakets SOLL die
Erstellung von Daten und Metadaten in mehreren
Repräsentationen ermöglichen.
Ja, es können mehrere R gleichzeitig angelegt
werden.
3. Struktur eines IP
| 13 | SIP-Format bei der Deutschen
Nationalbibliothek | 10. November 2020
3.4 Die Struktur des Informationspakets SOLL die
Möglichkeiten zum Hinzufügen zusätzlicher Daten
zum Informationspaket explizit definieren.
Ja.
3.5 Jedes Informationspaket SOLL seinen
Informationstypen mitteilen.
Noch nicht, aber in der Entwicklung.
4. Metadaten eines IP
| 13 | SIP-Format bei der Deutschen
Nationalbibliothek | 10. November 2020
4.1 Metadaten im Informationspaket SOLLEN
einem etablierten Standard entsprechen.
Nutzung von XML (etabliert) und künftig BagIt.
4.2 Die exakte Verwendung der Metadaten
SOLLTE in Profilen für Informationstypen
erarbeitet werden.
Möglich, aber im SIP noch nicht umgesetzt.
4.3 Jedes Informationspaket KANN
beschreibende Metadaten enthalten.
Ja.
5. Authentizität und Integrität eines IP
| 13 | SIP-Format bei der Deutschen
Nationalbibliothek | 10. November 2020
5.1 Im Informationspaket SOLLEN Möglichkeiten
enthalten sein, die Authentizität sicherzustellen.
Digitale Signaturmechanismen könnten
eingebaut werden, derzeit aber von keinem
DIMAG-Partner gewünscht.
5.2 Im Informationspaket SOLLEN Möglichkeiten
enthalten sein, die Integrität sicherzustellen.
Ja, Checksummen sind Teil der Metadaten.
Geplant ist, Checksummen verpflichtend zu
machen.
Comparison to nestor Guideline on SIPs
(and to the E-ARK SIP spec)
• https://d-nb.info/1214014216/34
• Everything fine with DIMAG, except
• our metadata are valid XML, but not valid METS (guideline 4.1)
• we do not yet have true information type profiles (guideline 4.2), but will use
them for a conversion and preservation module
• file objects in SIPs are not yet required to submit fixity information (e.g. an
MD5 value), but will do so in the new BagIt environment
Thank you for listening!
Any Questions?
kai dot naumann at la minus bw dot de
0049 711 212 4284

Weitere ähnliche Inhalte

Ähnlich wie SIP specifications at the DIMAG development group

TIB DOI-Service und DataCite - PIDs, Best Practices
TIB DOI-Service und DataCite - PIDs, Best PracticesTIB DOI-Service und DataCite - PIDs, Best Practices
TIB DOI-Service und DataCite - PIDs, Best PracticesFrauke Ziedorn
 
OPAL - Open Data Portal Germany
OPAL - Open Data Portal GermanyOPAL - Open Data Portal Germany
OPAL - Open Data Portal GermanyAdrian Wilke
 
Storage Management mit openAttic - LinuxDay - 2015-11-21
Storage Management mit openAttic - LinuxDay - 2015-11-21Storage Management mit openAttic - LinuxDay - 2015-11-21
Storage Management mit openAttic - LinuxDay - 2015-11-21Lenz Grimmer
 
16. DINI-Jahrestagung: Linked Data und Repositorien
16. DINI-Jahrestagung: Linked Data und Repositorien16. DINI-Jahrestagung: Linked Data und Repositorien
16. DINI-Jahrestagung: Linked Data und RepositorienPascal-Nicolas Becker
 
FAL in Extbase-Extensions
FAL in Extbase-ExtensionsFAL in Extbase-Extensions
FAL in Extbase-Extensionsin2code
 
Kickoff Workshop zum Projekt amsl mit den sächsischen Hochschulbibliotheken
Kickoff Workshop zum Projekt amsl mit den sächsischen HochschulbibliothekenKickoff Workshop zum Projekt amsl mit den sächsischen Hochschulbibliotheken
Kickoff Workshop zum Projekt amsl mit den sächsischen HochschulbibliothekenLydiaU
 
AMSL Kick-off-Meeting sächsischer Hochschulbibliotheken
AMSL Kick-off-Meeting sächsischer HochschulbibliothekenAMSL Kick-off-Meeting sächsischer Hochschulbibliotheken
AMSL Kick-off-Meeting sächsischer HochschulbibliothekenBjörn Muschall
 
DURAARK at AUdS 2015
DURAARK at AUdS 2015DURAARK at AUdS 2015
DURAARK at AUdS 2015panitzm
 
Fit für die digitale Bibliothek? (2007)
Fit für die digitale Bibliothek? (2007)Fit für die digitale Bibliothek? (2007)
Fit für die digitale Bibliothek? (2007)Ralf Stockmann
 
Add-on für SAP: Das schlanke Ablage- und Archivsystem von inPuncto
Add-on für SAP: Das schlanke Ablage- und Archivsystem von inPunctoAdd-on für SAP: Das schlanke Ablage- und Archivsystem von inPuncto
Add-on für SAP: Das schlanke Ablage- und Archivsystem von inPunctoinPuncto GmbH
 
Speichermedium Tape – Warum es keine Alternative gibt – data://disrupted® 2020
Speichermedium Tape – Warum es keine Alternative gibt – data://disrupted® 2020Speichermedium Tape – Warum es keine Alternative gibt – data://disrupted® 2020
Speichermedium Tape – Warum es keine Alternative gibt – data://disrupted® 2020data://disrupted®
 
Status of syslog as of 2005
Status of syslog as of 2005Status of syslog as of 2005
Status of syslog as of 2005Rainer Gerhards
 
Tutorial-XML-FastInfoset-einfuehrung
Tutorial-XML-FastInfoset-einfuehrungTutorial-XML-FastInfoset-einfuehrung
Tutorial-XML-FastInfoset-einfuehrungtutorialsruby
 
Tutorial-XML-FastInfoset-einfuehrung
Tutorial-XML-FastInfoset-einfuehrungTutorial-XML-FastInfoset-einfuehrung
Tutorial-XML-FastInfoset-einfuehrungtutorialsruby
 
Top 10 Internet Trends 2000
Top 10 Internet Trends 2000Top 10 Internet Trends 2000
Top 10 Internet Trends 2000Jürg Stuker
 
KI, Sprachtechnologie und Digital Humanities: Ein (unvollständiger) Überblick
KI, Sprachtechnologie und Digital Humanities: Ein (unvollständiger) ÜberblickKI, Sprachtechnologie und Digital Humanities: Ein (unvollständiger) Überblick
KI, Sprachtechnologie und Digital Humanities: Ein (unvollständiger) ÜberblickGeorg Rehm
 
EAD – Facts & Figures. Grundlagen, Werkzeuge und die Zukunft mit EAD3
EAD – Facts & Figures. Grundlagen, Werkzeuge und die Zukunft mit EAD3EAD – Facts & Figures. Grundlagen, Werkzeuge und die Zukunft mit EAD3
EAD – Facts & Figures. Grundlagen, Werkzeuge und die Zukunft mit EAD3Tobias Wildi
 

Ähnlich wie SIP specifications at the DIMAG development group (20)

TIB DOI-Service und DataCite - PIDs, Best Practices
TIB DOI-Service und DataCite - PIDs, Best PracticesTIB DOI-Service und DataCite - PIDs, Best Practices
TIB DOI-Service und DataCite - PIDs, Best Practices
 
OPAL - Open Data Portal Germany
OPAL - Open Data Portal GermanyOPAL - Open Data Portal Germany
OPAL - Open Data Portal Germany
 
Storage Management mit openAttic - LinuxDay - 2015-11-21
Storage Management mit openAttic - LinuxDay - 2015-11-21Storage Management mit openAttic - LinuxDay - 2015-11-21
Storage Management mit openAttic - LinuxDay - 2015-11-21
 
TYPO3 Translations
TYPO3 Translations TYPO3 Translations
TYPO3 Translations
 
16. DINI-Jahrestagung: Linked Data und Repositorien
16. DINI-Jahrestagung: Linked Data und Repositorien16. DINI-Jahrestagung: Linked Data und Repositorien
16. DINI-Jahrestagung: Linked Data und Repositorien
 
FAL in Extbase-Extensions
FAL in Extbase-ExtensionsFAL in Extbase-Extensions
FAL in Extbase-Extensions
 
Fedora
FedoraFedora
Fedora
 
Kickoff Workshop zum Projekt amsl mit den sächsischen Hochschulbibliotheken
Kickoff Workshop zum Projekt amsl mit den sächsischen HochschulbibliothekenKickoff Workshop zum Projekt amsl mit den sächsischen Hochschulbibliotheken
Kickoff Workshop zum Projekt amsl mit den sächsischen Hochschulbibliotheken
 
AMSL Kick-off-Meeting sächsischer Hochschulbibliotheken
AMSL Kick-off-Meeting sächsischer HochschulbibliothekenAMSL Kick-off-Meeting sächsischer Hochschulbibliotheken
AMSL Kick-off-Meeting sächsischer Hochschulbibliotheken
 
DURAARK at AUdS 2015
DURAARK at AUdS 2015DURAARK at AUdS 2015
DURAARK at AUdS 2015
 
Fit für die digitale Bibliothek? (2007)
Fit für die digitale Bibliothek? (2007)Fit für die digitale Bibliothek? (2007)
Fit für die digitale Bibliothek? (2007)
 
Add-on für SAP: Das schlanke Ablage- und Archivsystem von inPuncto
Add-on für SAP: Das schlanke Ablage- und Archivsystem von inPunctoAdd-on für SAP: Das schlanke Ablage- und Archivsystem von inPuncto
Add-on für SAP: Das schlanke Ablage- und Archivsystem von inPuncto
 
Speichermedium Tape – Warum es keine Alternative gibt – data://disrupted® 2020
Speichermedium Tape – Warum es keine Alternative gibt – data://disrupted® 2020Speichermedium Tape – Warum es keine Alternative gibt – data://disrupted® 2020
Speichermedium Tape – Warum es keine Alternative gibt – data://disrupted® 2020
 
DEPAROM 1. User Group Treffen (2008)
DEPAROM 1. User Group Treffen (2008)DEPAROM 1. User Group Treffen (2008)
DEPAROM 1. User Group Treffen (2008)
 
Status of syslog as of 2005
Status of syslog as of 2005Status of syslog as of 2005
Status of syslog as of 2005
 
Tutorial-XML-FastInfoset-einfuehrung
Tutorial-XML-FastInfoset-einfuehrungTutorial-XML-FastInfoset-einfuehrung
Tutorial-XML-FastInfoset-einfuehrung
 
Tutorial-XML-FastInfoset-einfuehrung
Tutorial-XML-FastInfoset-einfuehrungTutorial-XML-FastInfoset-einfuehrung
Tutorial-XML-FastInfoset-einfuehrung
 
Top 10 Internet Trends 2000
Top 10 Internet Trends 2000Top 10 Internet Trends 2000
Top 10 Internet Trends 2000
 
KI, Sprachtechnologie und Digital Humanities: Ein (unvollständiger) Überblick
KI, Sprachtechnologie und Digital Humanities: Ein (unvollständiger) ÜberblickKI, Sprachtechnologie und Digital Humanities: Ein (unvollständiger) Überblick
KI, Sprachtechnologie und Digital Humanities: Ein (unvollständiger) Überblick
 
EAD – Facts & Figures. Grundlagen, Werkzeuge und die Zukunft mit EAD3
EAD – Facts & Figures. Grundlagen, Werkzeuge und die Zukunft mit EAD3EAD – Facts & Figures. Grundlagen, Werkzeuge und die Zukunft mit EAD3
EAD – Facts & Figures. Grundlagen, Werkzeuge und die Zukunft mit EAD3
 

SIP specifications at the DIMAG development group

  • 1. SIP specifications at the DIMAG development group Boris Kraut, Kai Naumann Landesarchiv Baden-Württemberg Stuttgart
  • 2. I. Our SIP and archival culture II. Our SIP and its technical environment III. Our present SIP specifications IV. Our future SIP specifications based on BagIt
  • 3. Our SIP and archival culture
  • 5. Libreria imports: ebooks and ejournals other Trade partners: Publishland 95 % Others 5 % Icons from Silk Iconset by FamFamFam Policia Bankmark Libreria Archivesia Mathesia Lawistan Socialia Medicinia Artslands Biolopal Publishland
  • 7. Our SIP and its technical environment
  • 8. Catalogues for archives are hierarchies
  • 9. DIMAG SIPs are new components for this hierarchy
  • 11. DIMAG asks for new catalogue records
  • 12. Catalogue says: here they are!
  • 13. DIMAG and catalogue IDs in sync forever!
  • 14. CatalogueSW DIMAGStorage DIMAGDB DIMAGServer DIMAGIngestSource SIP Create catalogue metadata time Regular sync Success message Add primary data to storage create objects Success message Report new catalogue objects with IDs Process overview (simplified)
  • 15. All metadata in the catalogue, some in DIMAG
  • 16. Our present SIP specifications
  • 17. Our spec and its commands • https://dimag-wiki.la-bw.de/xwiki/bin/download/ %C3%96ffentliche+Software+und+Informationen/WebHome/Spezifikation_SOAP-Schnittstelle_320.pdf Operation What it says importDoc DIMAG (standalone instance), validate and ingest these SIPs! getForms DIMAG, ask the catalogue: Which descriptive forms do you have (e.g. sound recordings, paper files, medieval charters)! getFields DIMAG, ask the catalogue: Show me the fields the catalogue supplies (for e.g. sound recordings description)! importDocAfis DIMAG, ingest the customized SIPs and create catalogue entries (for e.g. sound recordings)!
  • 18. What? Upload single files via Web GUI. Client SW for single SIP (folders) with 1-5.000 files. Client SW for file collections, multiple SIPs Where to? 1-10 files generate one AIP 10-10.000 files generate one AIP 10-5.000 folders generate equal numbers of AIPs How? DIMAG Core Module via browser access. DIMAG IngestList client software, SFTP access to Core Module. DIMAG IngestTool client software, SFTP and SOAP access to Core Module, additional metadata. Means to generate SIPs
  • 19. 19 Mapping your own SIPs with DIMAG IngestTool • Input Elements – choose from CSV, XML, XLSX, TXT, file and folder names • Output Elements (DIMAG and catalogue software) • Mapping Elements – choose from concatenation, datetime conversions, simple math, string extraction, if-then
  • 20. Title tag, simple concatenation
  • 21. … single file, optionally load DIMAG control file (XML) folder with files, IngestList metadata file (XML), hashes flat folder with files, DIMAG control file (XML), hashes variants with different folder structure etc. Status Quo: Multiple similar but distinct SIPs
  • 22. … single file, optionally load DIMAG control file (XML) folder with files, IngestList metadata file (XML), hashes flat folder with files, DIMAG control file (XML), hashes variants with different folder structure etc. Status Quo: Multiple similar but distinct SIPs
  • 23. Our future SIP specifications based on BagIt
  • 24. Requirements/Layers 1. metadata 2. primary data 3. primary data file names 4. folder structure 5. additional metadata and process information 6. data integrity 7. SIP serialisation (single file package) 8. data compression 9. data encryption 10. data authenticity
  • 25. 1 2 3 4 5 6 DIMAG Control File ✓ ✓ (✓) (✓) BagIt (✓) ✓ ✓ (✓) ✓ METS ✓ ✓ (✓) ✓ eCH-0160 ✓ ✓ (✓) ✓ ✓ Evaluating specs and technologies… Req. 7-10 left out for shortness 1. metadata 2. primary data 3. primary data file names 4. folder structure 5. additional metadata and process information 6. data integrity
  • 26. TODO: The road to BagIt • move IngestList metadata to DIMAG control file format • define DIMAG specific metadata and structures • normalization of file names • process information/output of „worker“ tools • … • DIMAG KM understands its control file and every folder structure it comes with, so it can use bagit even if it doesnt have a deeper understanding • make DIMAG KM understand and parse BagIt • move all ingest tools to bagit format • keep compatibility with old formats for 3.x branch of DIMAG KM
  • 27. BagIt future of DIMAG SIPs BagIt Specification IETF RFC 8493 https://tools.ietf.org/html/rfc8493 DIMAG SIPs will be conforming to BagIt, with additional requirements • fetch.txt not accepted • required hash algorithms: SHA-512 (recommended), MD5, SHA-1, SHA-256, required tag-manifest • required DIMAG control.xml (importDoc SOAP Interface XML) • required dimag Subfolder • containing outputs of ingest microservices (today: identify, validate, transfer) • (plus some minor requirements) cf. https://gitlab.la-bw.de/dimag/public-info/-/blob/master/dimag-bagit.md
  • 28. DIMAG BagIt example <base directory>/ ├── bagit.txt ├── bag-info.txt ├── manifest-sha512.txt ├── tagmanifest-sha512.txt ├── control.xml ├── dimag/ │ ├── identify.xml │ ├── identify/ │ │ ├── identify.1572814543125.xml │ │ └── identify.1572814854436.xml │ ├── validate.xml │ ├── validate/ │ │ ├── validate.1572814896535.xml │ │ ├── validate.1572814933255.xml │ │ └── verapdf-report.txt │ ├── testdevel.xml │ ├── testgroups.xml │ └── testcontrol.xml └── data/ └── [payload files] • control.xml is THE central metadata storage • worker output (e.g. identify.xml) is currently for reference only, all vital information is stored in control.xml • usage of bag-info.txt (fields, where to split information between control.xml and bag-info.txt) is currently in discussion
  • 29. 1. Allgemeine Grundsätze | 13 | SIP-Format bei der Deutschen Nationalbibliothek | 10. November 2020 1.1 Es MUSS möglich sein, beliebige digitale Objekte und Metadaten in ein Informationspaket aufzunehmen. Ja, beliebige Dateiarten und -formate. 1.2 Das Informationspaket DARF NICHT die Mittel, Methoden oder Werkzeuge für den Ingest einschränken. Ja. 1.3 Das Paketformat DARF NICHT den logisch- inhaltlichen Umfang der digitalen Objekte und Metadaten definieren, die ein Informationspaket bilden. Ja, eine oder mehrere Dateien eines logischen Objekts oder Teilobjekts. 1.4 Das Informationspaket MUSS skalierbar sein. Ja, keine logischen Einschränkungen, allerdings evtl. technische.
  • 30. 1. Allgemeine Grundsätze | 13 | SIP-Format bei der Deutschen Nationalbibliothek | 10. November 2020 1.5 Das Informationspaket MUSS maschinenlesbar und automatisierbar zu verarbeiten sein. Ja, Nutzung von XML-Datei mit Schema. 1.6 Das Informationspaket MUSS interpretierbar sein, um eine auch für den Menschen inhaltliche Deutung zu ermöglichen. Ja, XML in Struktur und Inhalt lesbar. 1.7 Die Spezifikation des Informationspakets MUSS offen und frei sein. Ja, SOAP-Spec frei verfügbar. 1.8 Die Komplexität der Spezifikation eines Informationspakets SOLL angemessen sein. Ja.
  • 31. | 13 | SIP-Format bei der Deutschen Nationalbibliothek | 10. November 2020 2. Grundsätze zur Identifikation eines IP 2.1 Jedes Informationspaket MUSS einen im archivierenden Archiv eindeutigen und dauerhaften Identifikator haben oder erhalten Ja, interne Objekt-ID. 2.2 Jedes Informationspaket SOLL einen Identifikator besitzen, der global eindeutig und dauerhaft ist. Ja, externe Objekt-ID des angebundenen archivischen Katalogsystems (Findmittelsystem). 2.3 Alle Teile eines Informationspakets SOLLEN einen eindeutigen und dauerhaften Identifikator haben. Ja, als XML-Tagnamen.
  • 32. 3. Struktur eines IP | 13 | SIP-Format bei der Deutschen Nationalbibliothek | 10. November 2020 3.1 Das Informationspaket MUSS sicherstellen, dass Daten und Metadaten logisch voneinander getrennt sind. Ja. 3.2 Die Struktur des Informationspakets SOLL die Trennung verschiedener Arten von Metadaten ermöglichen. Ja. 3.3 Die Struktur des Informationspakets SOLL die Erstellung von Daten und Metadaten in mehreren Repräsentationen ermöglichen. Ja, es können mehrere R gleichzeitig angelegt werden.
  • 33. 3. Struktur eines IP | 13 | SIP-Format bei der Deutschen Nationalbibliothek | 10. November 2020 3.4 Die Struktur des Informationspakets SOLL die Möglichkeiten zum Hinzufügen zusätzlicher Daten zum Informationspaket explizit definieren. Ja. 3.5 Jedes Informationspaket SOLL seinen Informationstypen mitteilen. Noch nicht, aber in der Entwicklung.
  • 34. 4. Metadaten eines IP | 13 | SIP-Format bei der Deutschen Nationalbibliothek | 10. November 2020 4.1 Metadaten im Informationspaket SOLLEN einem etablierten Standard entsprechen. Nutzung von XML (etabliert) und künftig BagIt. 4.2 Die exakte Verwendung der Metadaten SOLLTE in Profilen für Informationstypen erarbeitet werden. Möglich, aber im SIP noch nicht umgesetzt. 4.3 Jedes Informationspaket KANN beschreibende Metadaten enthalten. Ja.
  • 35. 5. Authentizität und Integrität eines IP | 13 | SIP-Format bei der Deutschen Nationalbibliothek | 10. November 2020 5.1 Im Informationspaket SOLLEN Möglichkeiten enthalten sein, die Authentizität sicherzustellen. Digitale Signaturmechanismen könnten eingebaut werden, derzeit aber von keinem DIMAG-Partner gewünscht. 5.2 Im Informationspaket SOLLEN Möglichkeiten enthalten sein, die Integrität sicherzustellen. Ja, Checksummen sind Teil der Metadaten. Geplant ist, Checksummen verpflichtend zu machen.
  • 36. Comparison to nestor Guideline on SIPs (and to the E-ARK SIP spec) • https://d-nb.info/1214014216/34 • Everything fine with DIMAG, except • our metadata are valid XML, but not valid METS (guideline 4.1) • we do not yet have true information type profiles (guideline 4.2), but will use them for a conversion and preservation module • file objects in SIPs are not yet required to submit fixity information (e.g. an MD5 value), but will do so in the new BagIt environment
  • 37. Thank you for listening! Any Questions? kai dot naumann at la minus bw dot de 0049 711 212 4284