SIP specifications at the DIMAG development group

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

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

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

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
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.

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
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.
Erstellung von Daten und Metadaten in mehreren
Repräsentationen ermöglichen.
Ja, es können mehrere R gleichzeitig angelegt
werden.

3. Struktur eines IP
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
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
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

SIP specifications at the DIMAG development group

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Ähnlich wie SIP specifications at the DIMAG development group

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

SIP specifications at the DIMAG development group