Template for submission policies
Date of agreement | DD.MM.YYYY |
---|---|
Version of submission policy | X.X |
Donating body | Team/institution xyz |
Corresponding contract / Memorandum of Understanding | Contract name Contract date |
Applicable to following collections | Collection ID |
1. Description of data storage
1.1 Content
Description of data storage (folder names / directory structure / path names), the material types deposited there, and the applicable licence texts and versions in each case.
1.1.1 Directory tree (excluding data packages)
Directory tree, starting from the top directory of data storage to the level above the data packages.
A data package contains files organised in several representations, depending on the type of transmission chosen, as well as corresponding metadata as dc.xml and/or source metadata, where applicable.
The data package can be named after an external identifier as the package name, which is issued in reporting. An MD5 checksum must be transferred with every file. This checksum is used for integrity assurance during data transfer and submission to the digital archive, but it is not part of the archive package.
Grouping criterion, e.g. licence term | Corresponding collection ID |
Criterion 1, e.g. CC licence | 123 |
Criterion 2, e.g. in the public domain | Digital reproductions_in the public domain |
Criterion 3, e.g. licence agreement XY | Published literature_licence agreement_XY |
1.1.2 Overview of the collection structure
Path | Collection ID* | Collection / material type | Subcollection | Legal basis of archiving | Access rights | Password-protected files |
Digital reproductions_in the public domain | ||||||
123 | ||||||
Published literature_licence agreement_XY_with_PW |
*A collection ID corresponds to an ingest process for data packages with identical ingest parameterisation.
1.1.3 Licence texts and versions
Overview of the licence terms applicable to objects in the collection.
Name of licence term | Corresponding collection ID |
CC licence | 123 |
In the public domain | Digital reproductions_in the public domain |
Licence agreement XY | Published literature_licence agreement_XY |
1.2 Metadata
Description of metadata delivered (use of the GVK interface, description of additional metadata with the metadata standard)
1.2.1 Use of the GVK interface
Collection ID | Use of the GVK interface | Other interfaces |
Yes/no | Yes/no |
1.2.2 Additional metadata delivered
Collection ID | dc.xml | Source metadata with the metadata standard |
Yes/no | Dublin Core/METS/MODS/EAD |
1.3 Structure
Structure of data packages in data storage (agreed structure and responsibilities)
1.3.1 Data model of the agreed data structure(s)
The donating body is responsible for creating the agreed data structure. TIB’s Digital Preservation team checks the delivered packages for conformity with the agreed data structure. Non-compliant packages are sent back to the donating body by the Digital Preservation team.
Generic data model (1-n)
1.3.2 Assignment of collections to the corresponding SIP specification
Collection ID | SIP specification |
---|---|
1-n representations with 1-n files or complex data structures | |
2. Configuration and ingest parameterisation
Assignment of the collection structure in the donating body’s data storage for ingest parameterisation in the digital preservation system
Collection ID | Collection | Subcollection | Institution | Department | Producer | dcterms:license | Boilerplate | Material flow | Approval group | User defined A | User defined B | IE entity type | Status | Material type | Access right | Validation task | Enrichment routine |
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Digital reproductions_in the public domain | Digital reproductions | In the public domain | XYZ | Retro-digitisation | XYZ retro-digitisation | XYZ_in the public domain_under_Section_64_German Copyright Act (UrhG) | Submission policy_with_XYZ | METS_deposit | Default | XYZ_digital reproductions | --- | Book | Active | Digital reproduction | No restriction | Full | Dependent on 1.2.1 |
3. Representations
Description of representations to be recorded (name of representation, content, assignment of files/directories from the collection to the representations)
Representation | Description |
---|---|
MASTER | Original files |
MODIFIED_MASTER | Modified copy of original files before ingest |
DERIVATIVE_COPY | Access copy |
OCR | OCR |
... | Additional representations can be created. |
Collection ID | MASTER | MODIFIED_MASTER | DERIVATIVE_COPY | OCR | Additional representations | |
---|---|---|---|---|---|---|
Content | Digital reproductions_in the public domain | TIFF files | --- | JPEG files | XML files with OCR | --- |
123 | 1-n PDF files in the “Original” directory | 1-n PDF files in the “edited” directory with additionally created title page | 1-n PDF files from the “edited” directory are compressed into 1 PDF file for the presentation platform | --- | --- |
4. Submission of collections
Description of data delivery, comprising data transfer and the submission procedure
4.1 Data transfer
Description of the data transfer to TIB
Data packages are submitted with the structure defined in 1.3. Checksums (MD5) are also delivered at the file level.
Transfer type | Transmission interval | Location |
---|---|---|
SFTP / transmission from hard disk | Daily/monthly/.../annually |
4.2 Submission procedure
Description of the submission procedure for the first delivery as well as regular additions
Submission interval: daily/weekly/monthly/quarterly/half-yearly/annually (Delete where inapplicable)
Collection ID | Submission procedure |
---|---|
Manual/automatic |
5. Preservation level
Description of the preservation levels available and assignment of preservation levels to individual collections
Preservation levels are defined in the TIB Preservation Policy in the section on “Preservation levels”.
The following preservation levels are agreed on. Restrictions apply to password-protected files. If preservation management is prevented due to password protection, only bitstream preservation can be ensured for those files. Password-protected files shall be identified by the donating body and reported to TIB’s Digital Preservation team during data delivery. Such files are marked with metadata in the digital preservation system accordingly.
Preservation level | Description | Concerns |
---|---|---|
Full preservation | Preservation of data flow and content by preservation management | Files without password protection |
Bit preservation | Preservation of the data flow | Password-protected files |
Collection ID | Preservation level | |
---|---|---|
Full preservation / bit preservation / a mixture of both |
Collection ID | Directory name for pw-protected files | Path |
---|---|---|
6. Reporting
Description of the elements and frequency of reports
Report following data submission
A report is created each time a data delivery is transmitted. Where needed, a report can be created for each collection ID.
The package name is the directory name of the delivered data package, as described in 1.1.1.
Package name | SIP ID in the system | Status |
---|---|---|
Report during operations
A report on the donating body’s collections or subcollections can be created during DP operations, by arrangement. The desired content must be agreed with TIB’s Digital Preservation team.
Reporting interval | Package name | ID in the system | Agreed content of report |
---|---|---|---|
7. Export
Description of export
Packages can be exported from the DP system. The following options are available:
- Complete export of a package with all representations, including all metadata, in the form of an METS-XML
- Export of individual representations, including all metadata, in the form of an METS-XML
The donating body defines the desired form of export for individual packages.
Export can be performed quarterly using the routines currently available in the program. In the process, all newly created packages and packages that have been modified during this period are exported for that interval (quarter).
Packages are exported in the structure in which they were ingested. Export of an individual AIP is based on the “File Original Path” element. “File Original Path” contains the original name of the data package. The package name is the directory name of the delivered data package, as described in 1.1.1. On this basis, the original directory structure is reconstructed during export. Packages are compressed into subcollections based on the metadata assigned in ingest parameterisation, ensuring preservation of the structure of subcollections (see 1.1.2 Overview of the collection structure).
In the event of the export of a service user’s whole collection from TIB’s digital archive, the contract regulates the relevant deadlines and lead times.
The exit scenario is the complete export of all of the donating body’s archived objects. The exit strategy is based on the export functions described above.