Theme | submission policy |
|---|---|
Name | Name of Submission policy |
Version of submission policy | X.X |
Date of agreement | DD.MM.YYYY |
| Revision Date | one year after date of agreement |
Owner | responsible organisation unit |
Donating body | Team/institution xyz |
Corresponding contract / Memorandum of Understanding | Contract name Contract date |
Approved by | responsible managers of both sides |
Date of approvement | |
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 of the organizational/structuring directory structure (without data packages)
Directory tree starting from the top directory of the data storage up to the level above the data packages
1.1.2 Overview of the collection structure
Path | Collection ID* | Collection / material type | Subcollection | Legal basis of archiving | Access rights in Rosetta (Access Rights) | Usage rights (dcterms:accessRights) | 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.
| License temrs | documented as | key value | Associated collection ID |
|---|---|---|---|
| Right of access to the document as granted by the producer | dcterms:accessRights | ||
| Legal basis of archiving | dc:rights | ||
Name of the Submission Agreement | dcterms:license |
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 K10plus interface
Collection ID | Use of the K10plus interface |
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/Other |
Mapping specification
| Element Name | Element description | Mandatory (M = Mandatory, O = Optional) | repeatable (Y = Yes, N = No) | Example | Dublin Core Element | String building |
|---|---|---|---|---|---|---|
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 | |
1.2.3 Metadata Profile
| Descriptive MD Elements | DNX Elements |
|---|---|
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. Transfer of legacy holdings (already existing data)
4.1 Data transfer
Description of the legacy data transfer (existing data at the time of the initial transfer)
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. Transfer of newly received data (new additions)
5.1 new additions
Description of the takeover of new additions and the takeover procedure (takeover in a fixed time cycle of stocks added since the initial takeover)
Transfer type | Transmission interval | Location |
|---|---|---|
SFTP / transmission from hard disk | Daily/monthly/.../annually |
5.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 |
6. Preservation level
Description of the existing conservation levels and allocation of the conservation levels to the individual stocksThe following conservation levels have been agreed. Restrictions apply to password-protected files. If password protection prevents preservation measures, only Bitstream Preservation can be guaranteed for these files. Password-protected files must be identified by the submitting institution and reported to the TIB's long-term archiving team when the data is transferred. They are marked with corresponding metadata in the long-term archiving system.
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 and proprietary file formats |
Collection ID | Preservation level | |
|---|---|---|
Full preservation / bit preservation / a mixture of both | ||
| Collection ID | Directory name for pw-protected files | Path |
|---|---|---|
7. 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 |
|---|---|---|---|
8. 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.