Specification for Submission Information Packages

Preface

I. Aim of the Specification

This document is one of several related specifications which aim to provide a common set of usage descriptions of international standards for packaging digital information for archiving purposes. These specifications are based on common, international standards for transmitting, describing and preserving digital data. They also utilise the Reference Model for an Open Archival Information System (OAIS), which has Information Packages as its foundation. Familiarity with the core functional entities of OAIS is a prerequisite for understanding the specifications.

The specifications are designed to help data creators, software developers, and digital archives to tackle the challenge of short-, medium- and long-term data management and reuse in a sustainable, authentic, cost-efficient, manageable and interoperable way. A visualisation of the current specification network can be seen here:

OAIS Entities

Figure I: Diagram showing E-ARK specification dependency hierarchy. Note that the image only shows a selection of the published CITS and isn’t an exhaustive list.

Overview of the E-ARK Specifications

Common Specification for Information Packages (E-ARK CSIP)

This document introduces the concept of a Common Specification for Information Packages (CSIP). The main purposes of CSIP are to:

Ultimately the goal of the Common Specification is to reach a level of interoperability between all Information Packages so that tools implementing the Common Specification can be adopted by institutions without the need for further modifications or adaptations.

Specification for Submission Information Packages (E-ARK SIP)

The main aims of this specification are to:

Specification for Archival Information Packages (E-ARK AIP)

The main aims of this specification are to:

Specification for Dissemination Information Packages (E-ARK DIP)

The main aims of this specification are to:

Content Information Type Specifications (E-ARK CITS)

The main aim of a Content Information Type Specification (CITS) is to:

The number of possible Content Information Type Specifications is unlimited. For a list of existing Content Information Type Specifications see the DILCIS Board webpage (DILCIS Board, http://dilcis.eu/).

II. Organisational Support

This specification is maintained by the Digital Information LifeCycle Interoperability Standards Board (DILCIS Board, http://dilcis.eu/). The role of the DILCIS Board is to enhance and maintain the draft specifications developed in the European Archival Records and Knowledge Preservation Project (E-ARK project, http://eark-project.com/), which concluded in January 2017. The Board consists of eight members, but no restriction is placed on the number of participants taking part in the work. All Board documents and specifications are stored in GitHub (https://github.com/DILCISBoard/), while published versions are made available on the Board webpage. The DILCIS Board have been responsible for providing the core specifications to the Connecting Europe Facility eArchiving Building Block https://ec.europa.eu/cefdigital/wiki/display/CEFDIGITAL/eArchiving/.

III. Authors & Revision History

A full list of contributors to this specification, as well as the revision history, can be found in the Postface material.

E-ARK SIP

Specification for Submission Information Packages

Version: 2.2.0

Date: 2024-05-17

1. Introduction
1.1. Scope and purpose
1.2. Target audience
1.3. Definition of SIP
2. Structure
3. METS
3.1. Extended use of the METS root element (element mets)
3.2. Extended use of the METS header (element metsHdr)
3.3. Extended use of the METS descriptive metadata section (element dmdSec)
3.4. Extended use of METS administrative metadata section (element amdSec)
3.5. Extended use of the METS file section (element fileSec)
3.6. Extended use of the METS structural map (element structMap)
4. Content Information Type Specifications (CITS)
4.1. Submission Agreements
5. Glossary
6. Bibliography
7. Appendices
7.1. Appendix A: Submission Agreement semantic elements
7.1.1. Project information
7.1.2. Change management
7.1.3. Producer, Archive and Designated Community
7.1.4. Submission Information Package (SIP)
7.1.5. Submission Session Information
7.1.6. Ingest
7.1.7. Submission risks
7.2. Appendix B: E-ARK Information Package METS Example
7.2.1. Example 1: Example of a whole METS document describing an submission information package with no representations.
7.3. Appendix C: External Schema
7.3.1. E-ARK SIP METS Extension
7.3.2. E-ARK CSIP METS Extension
7.4. Appendix D: External Vocabularies
7.4.1. Package status
7.4.2. Alternative record ID's
7.4.3. Note type
7.4.4. OAIS Package type
7.5. Appendix E: E-ARK SIP Metadata Requirements
7.5.1. E-ARK SIP METS Profile 2.1 Requirements

1. Introduction

According to ISO 14721:2012 - Open archival information system (OAIS) Reference model, every submission to an archive is made through one or more distinct transmissions of Submission Information Packages (SIP). However, the OAIS Reference Model itself does not provide detailed guidelines on the structure of these information packages.

Addressing this gap, the European Union-funded E-ARK project, which ran from 2014 to 2017, recognized the issue and initiated the development of a standardized package specification. This effort aimed to define a clear and actionable framework for the creation and management of Submission Information Packages, thereby enhancing the interoperability and effectiveness of digital archiving processes.

Today, this specification is among a series of standards overseen by the Digital Information LifeCycle Interoperability Standards Board (DILCIS Board), an independent entity dedicated to the maintenance and promotion of digital information lifecycle standards.

1.1. Scope and purpose

This document describes how to produce and parse E-ARK Submission Information Packages (SIP). The main objectives of this specification are to:

1.2. Target audience

This specification is designed for a broad audience, including record creators, archival institutions, and software providers tasked with the preparation, packaging, delivery, and reception of information packages for archiving within an Open Archival Information System (OAIS), specifically targeting the pre-ingest and ingest stages.

1.3. Definition of SIP

The OAIS reference model defines a Submission Information Package (SIP) as follows:

An Information Package that is delivered by the Producer to the OAIS for use in the construction or update of one or more AIPs and/or the associated Descriptive Information.

The E-ARK SIP is aligned with this definition, expanding upon the E-ARK Common Specification for Information Packages (CSIP). It enhances this specification by incorporating specific requirements essential for selecting, packaging, transmitting, receiving, validating, and ingesting information originally held by a Producer.

2. Structure

The SIP specification follows a structure that is common to Information Packages in the E-ARK set of specifications. The common structure is fully described in the Common Specification for Information Packages (see Section 4. CSIP structure).

In its simplest form, an SIP consists of metadata and zero or more representations, also composed of data and metadata, as seen in Figure 2. A package with zero representations means that it only contains metadata. This is a special type of Information Package that enables Producers to deliver updates to the metadata to previously ingested packages.

SIP data model

Figure 2: Simplified view of the structure of an information package.

According to PREMIS Version 3.0:

A representation is a set of files, including structural metadata, needed for a complete and reasonable rendition of an Intellectual Entity. For example, a journal article may be complete in one PDF file. This single file constitutes the representation. Another journal article may consist of one SGML file and two image files. These three files constitute the representation. A third article may be represented by one TIFF image for each of 12 pages plus an XML file of structural metadata showing the order of the pages. These 13 files constitute the representation.

As one SIP may contain multiple representations of the same intellectual entity, representations MUST be placed within distinct folders (i.e., rep-001, rep-002, rep-n under the representations folder). In contrast, metadata may exist within each representation folder or at the root level (next to the representations folder). Metadata can serve multiple purposes, being the most common one the support for discoverability of resources within the OAIS (i.e. descriptive metadata).

If metadata is stored at the root level of the package, then there is generally no need to include metadata at the representation level. In such cases, the metadata folder under representations is considered optional. The SIP also accounts for the following additional folders, which can exist both at the root level or under the representations folder (Figure 3):

General SIP structure

Figure 3: Example of the full use of the SIP structure

The details of the internal structure of an SIP including its data and metadata folders can be further specified by Submission Agreements. These can exist for a particular submission, a special collection or a specific Producer.

3. METS

The Metadata Encoding and Transmission Standard (METS) is a standard for encoding descriptive, administrative, and structural metadata expressed using the XML Schema Language.

METS schema is utilized across the various types of packages (SIP, AIP and DIP) maintaining a consistent approach to metadata encoding anda data structuring. The specific application of the METS schema within an E-ARK packages is detailed in the Common Specification for Information Packages (CSIP), particularly in section “5.3 Use of METS”. This section outlines how METS should be implemented, including the precise requirements for its use within the E-ARK information packages.

Although the METS schema serves as a common foundation for SIPs, AIPs, and DIPs within E-ARK information packages, there are subtle differences in its application across these packages. These variations are mainly in the customization of attribute values, the definition of controlled vocabularies, and the adjustment of element optionality - transforming some optional elements into mandatory ones. Such adjustments ensure that the METS schema is optimally tailored to meet the specific needs of each package type, enhancing the precision and utility of metadata encoding for digital preservation and access.

The specific differences between the METS instances for SIP and the Common Specification for Information Packages (CSIP) are articulated through what is known as a METS profile. A METS profile is a detailed document that defines how the METS schema is adapted or extended for particular use cases or types of digital packages. In this context, the SIP METS profile is an extension of the more general CSIP METS profile, focusing on the particular requirements and adaptations necessary for Submission Information Packages within the E-ARK Information Packages framework.

3.1. Extended use of the METS root element (element mets)

The root element of a METS document <mets> can contain a number of optional attributes, namespaces (xmlns:), locations for external schemas (xsi:) and a number of other elements.

The following table describes the differences in the <mets> element between the E-ARK SIP and the <mets> element of a Common Specification for Information Packages (CSIP).

ID Name, Location & Description Card & Level
SIP1 Package name
mets/@LABEL
An optional short text describing the contents of the package, e.g. “Accounting records of 2017”.
0..1
MAY
SIP2 METS Profile
mets/@PROFILE
The value is set to “https://earksip.dilcis.eu/profile/E-ARK-SIP-v2-2-0.xml”.
1..1
MUST

Example: METS example of altrecordID’s, and SIP agents following the SIP profile as well as CS IP.

<agent ROLE="ARCHIVIST" TYPE="ORGANIZATION">
  <name>
    The Swedish health agency
  </name>
  <note csip:NOTETYPE="IDENTIFICATIONCODE">
    VAT:SE201345098701
  </note>
</agent>
<agent ROLE="CREATOR" TYPE="ORGANIZATION">
  <name>
    The agency, Personnel
  </name>
  <note csip:NOTETYPE="IDENTIFICATIONCODE">
    VAT:SE2098109810-AF87
  </note>
</agent>
<agent ROLE="OTHER" TYPE="INDIVIDUAL" OTHERROLE="SUBMITTER">
  <name>
    Sven Svensson
  </name>
  <note>
    Phone: 08-123456, Email: sven.svensson@mail.mail
  </note>
</agent>
<agent ROLE="PRESERVATION" TYPE="ORGANIZATION">
  <name>
    The archives
  </name>
  <note csip:NOTETYPE="IDENTIFICATIONCODE">
    ID:1234567
  </note>
</agent>
<altRecordID TYPE="SUBMISSIONAGREEMENT">
  http://submissionagreement.kb.se/dnr331-1144-2011/20120711/
</altRecordID>
<altRecordID TYPE="PREVIOUSSUBMISSIONAGREEMENT">
  FM 12-2387/12726, 2007-09-19
</altRecordID>
<altRecordID TYPE="REFERENCECODE">
  SE/RA/123456/24/P
</altRecordID>
<altRecordID TYPE="PREVIOUSREFERENCECODE">
  SE/FM/123/123.1/123.1.3
</altRecordID>
</metsHdr>

Example: METS root element example with values from E-ARK-SIP as well as CS IP.

<mets OBJID="uuid-4422c185-5407-4918-83b1-7abfa77de182" LABEL="Accounting records of 2017" TYPE="OTHER" csip:OTHERTYPE="Accounting" PROFILE="https://earksip.dilcis.eu/profileE-ARK-SIP-v2-2-0.xml" xsi:schemaLocation="http://www.loc.gov/METS/ http://www.loc.gov/standards/mets/mets.xsd         http://www.w3.org/1999/xlink http://www.loc.gov/standards/mets/xlink.xsd         https://DILCIS.eu/XML/METS/CSIPExtensionMETS https://earkcsip.dilcis.eu/schema/DILCISExtensionMETS.xsd         https://DILCIS.eu/XML/METS/SIPExtensionMETS https://earksip.dilcis.eu/schema/DILCISExtensionSIPMETS.xsd">
</mets>

3.2. Extended use of the METS header (element metsHdr)

The <metsHdr> (METS header) element is a crucial part of the METS schema, providing metadata about the creation and management of the Submission Information Package (SIP). This element encapsulates information about various actors involved in the creation, preparation, and submission of the SIP. These actors are referred to as “agents” and are represented within the METS schema by the <agent> element, which is nested within the <metsHdr> element.

Each <agent> element can describe a range of roles and responsibilities associated with the SIP, including but not limited to:

The metsHdr/agent elements allow for the detailed documentation of each agent’s role, name, note, and other identifiers, thereby providing a comprehensive record of all parties involved in the SIP’s creation and management. This structured approach not only facilitates accountability and transparency but also enhances the metadata’s richness and usefulness for future archival processing and access.

The <metsHdr> is also used to indicate the type of behaviour to be expected from the OAIS when processing a particular SIP. For example, one might indicate that an SIP should be used to “replace” a particular AIP in the repository or that an SIP is meant for “testing” purposes and therefore it should not create an AIP at the end of the ingest process (see attribute metsHdr/@RECORDSTATUS).

It is also in the metsHdr that the Submission Agreement to which a particular SIP conforms can be identified (see metsHdr/altrecordID/@TYPE=”SUBMISSIONAGREEMENT).

The following table describes the differences in the metsHdr between an E-ARK SIP and the CSIP.

ID Name, Location & Description Card & Level
SIP3 Package status
metsHdr/@RECORDSTATUS
A way of indicating the status of the package and to instruct the OAIS on how to properly handle the package. If not set, the expected behaviour is equal to NEW.
0..1
MAY
SIP4 OAIS Package type information
metsHdr/@csip:OAISPACKAGETYPE
@csip:OAISPACKAGETYPE is used with the value “SIP”.
1..1
MUST
SIP5 Submission agreement
metsHdr/altRecordID
A reference to the Submission Agreement associated with the package.
@TYPE is used with the value “SUBMISSIONAGREEMENT”.
Example: RA 13-2011/5329; 2012-04-12
Example: http://submissionagreement.kb.se/dnr331-1144-2011/20120711/
Note: It is recommended to use a machine-readable format for a better description of a submission agreement.
For example, the submission agreement developed by Docuteam GmbH http://www.loc.gov/standards/mets/profiles/00000041.xml
0..1
MAY
SIP6 Previous Submission agreement
metsHdr/altRecordID
An optional reference to a previous submission agreement(s) which the information may have belonged to.
@TYPE is used with the value “PREVIOUSSUBMISSIONAGREEMENT”.
Example: FM 12-2387/12726, 2007-09-19
Example: http://submissionagreement.kb.se/dnr331-1144-2011/20120711/
Note: It is recommended to use a machine-readable format for a better description of a submission agreement.
For example, the submission agreement developed by Docuteam GmbH http://www.loc.gov/standards/mets/profiles/00000041.xml
0..*
MAY
SIP7 Archival reference code
metsHdr/altRecordID
An optional reference code indicating where in the archival hierarchy the package shall be placed in the OAIS.
@TYPE is used with the value “REFERENCECODE”.
Example: FM 12-2387/12726, 2007-09-19
0..1
MAY
SIP8 Previous archival reference code
metsHdr/altRecordID
In cases where the SIP originates from other institutions maintaining a reference code structure, this element can be used to record these reference codes and therefore support the provenance of the package when a whole archival description is not submitted with the submission.
@TYPE is used with the value “PREVIOUSREFERENCECODE”.
Example: SE/FM/123/123.1/123.1.3
0..*
MAY
SIP9 Archival creator agent
metsHdr/agent
A wrapper element that enables to encode the name of the organisation or person that originally created the data being transferred. Please note that this might be different from the organisation which has been charged with preparing and sending the SIP to the archives.
0..1
MAY
SIP10 Archival creator agent role
metsHdr/agent/@ROLE
The role of the person(s) or institution(s) responsible for the document/collection.
1..1
MUST
SIP11 Archival creator agent type
metsHdr/agent/@TYPE
The type of the archival creator agent is “ORGANIZATION” or “INDIVIDUAL”.
1..1
MUST
SIP12 Archival creator agent name
metsHdr/agent/name
The name of the organisation(s) that originally created the data being transferred.
Please note that this might be different from the organisation which has been charged with preparing and sending the SIP to the archives.
1..1
MUST
SIP13 Archival creator agent additional information
metsHdr/agent/note
The archival creator agent has a note providing a unique identification code for the archival creator.
0..1
MAY
SIP14 Classification of the archival creator agent additional information
metsHdr/agent/note/@csip:NOTETYPE
The archival creator agent note is typed with the value of “IDENTIFICATIONCODE”.
1..1
MUST
SIP15 Submitting agent
metsHdr/agent
A wrapper element that enables to encode the name of the organisation or person submitting the package to the archive.
1..1
MUST
SIP16 Submitting agent role
metsHdr/agent/@ROLE
The role of the person(s) or institution(s) responsible for creating and/or submitting the package.
1..1
MUST
SIP17 Submitting agent type
metsHdr/agent/@TYPE
The type of the submitting agent is “ORGANIZATION” or “INDIVIDUAL”.
1..1
MUST
SIP18 Submitting agent name
metsHdr/agent/name
Name of the organisation submitting the package to the archive.
1..1
MUST
SIP19 Submitting agent additional information
metsHdr/agent/note
The submitting agent has a note providing a unique identification code for the submitter.
0..1
MAY
SIP20 Classification of the submitting agent additional information
metsHdr/agent/note/@csip:NOTETYPE
The submitting agent note is typed with the value of “IDENTIFICATIONCODE”.
1..1
MUST
SIP21 Contact person agent
metsHdr/agent
A wrapper element that enables to encode the name of the contact person for the submission.
0..*
MAY
SIP22 Contact person agent role
metsHdr/agent/@ROLE
The role of the contact person is “CREATOR”.
1..1
MUST
SIP23 Contact person agent type
metsHdr/agent/@TYPE
The type of the contact person agent is “INDIVIDUAL”.
1..1
MUST
SIP24 Contact person agent name
metsHdr/agent/name
Name of the contact person.
1..1
MUST
SIP25 Contact person agent additional information
metsHdr/agent/note
The submitting agent has one or more notes giving the contact information.
0..*
MAY
SIP26 Preservation agent
metsHdr/agent
A wrapper element that enables to encode the name of the organisation or person that preserves the package.
0..1
MAY
SIP27 Preservation agent role
metsHdr/agent/@ROLE
The role of the preservation agent is “PRESERVATION”.
1..1
MUST
SIP28 Preservation agent type
metsHdr/agent/@TYPE
The type of the submitting agent is “ORGANIZATION”.
1..1
MUST
SIP29 Preservation agent name
metsHdr/agent/name
Name of the organisation preserving the package.
1..1
MUST
SIP30 Preservation agent additional information
metsHdr/agent/note
The preservation agent has a note providing a unique identification code for the archival creator.
0..1
MAY
SIP31 Classification of the preservation agent additional information
metsHdr/agent/note/@csip:NOTETYPE
The preservation agent note is typed with the value of “IDENTIFICATIONCODE”.
1..1
MUST

Example: METS example of altrecordID’s, and SIP agents following the SIP profile as well as CS IP.

<agent ROLE="ARCHIVIST" TYPE="ORGANIZATION">
  <name>
    The Swedish health agency
  </name>
  <note csip:NOTETYPE="IDENTIFICATIONCODE">
    VAT:SE201345098701
  </note>
</agent>
<agent ROLE="CREATOR" TYPE="ORGANIZATION">
  <name>
    The agency, Personnel
  </name>
  <note csip:NOTETYPE="IDENTIFICATIONCODE">
    VAT:SE2098109810-AF87
  </note>
</agent>
<agent ROLE="OTHER" TYPE="INDIVIDUAL" OTHERROLE="SUBMITTER">
  <name>
    Sven Svensson
  </name>
  <note>
    Phone: 08-123456, Email: sven.svensson@mail.mail
  </note>
</agent>
<agent ROLE="PRESERVATION" TYPE="ORGANIZATION">
  <name>
    The archives
  </name>
  <note csip:NOTETYPE="IDENTIFICATIONCODE">
    ID:1234567
  </note>
</agent>
<altRecordID TYPE="SUBMISSIONAGREEMENT">
  http://submissionagreement.kb.se/dnr331-1144-2011/20120711/
</altRecordID>
<altRecordID TYPE="PREVIOUSSUBMISSIONAGREEMENT">
  FM 12-2387/12726, 2007-09-19
</altRecordID>
<altRecordID TYPE="REFERENCECODE">
  SE/RA/123456/24/P
</altRecordID>
<altRecordID TYPE="PREVIOUSREFERENCECODE">
  SE/FM/123/123.1/123.1.3
</altRecordID>
</metsHdr>

3.3. Extended use of the METS descriptive metadata section (element dmdSec)

The METS descriptive metadata section <dmdSec> is responsible for recording descriptive metadata for all the data items included in the package.

The SIP specification itself does not prescribe of any particular metadata format. It is a role of the OAIS together with the Producer to set the rules in terms of descriptive metadata. These rules should be set and agreed upon in the Submission Agreement.

In the context of the <dmdSec> element, the SIP specification does not change or extend any of the requirements already defined by the Common Specification for Information Packages (for more information see section 5.3.3 of the CSIP).

3.4. Extended use of METS administrative metadata section (element amdSec)

The <amdSec> (administrative metadata section) in a METS document plays a crucial role in encapsulating or referencing the technical and preservation metadata related to a digital object or collection. This section is pivotal for maintaining the integrity, understanding, and long-term preservation of digital resources.

Preservation metadata, while not always found within Submission Information Packages, holds significant value, especially in recording the history of events affecting the state and stewardship of the information package. Preservation metadata is primarily associated with activities undertaken after a package’s ingestion into a digital repository. However, certain preservation events, such as the digitization of analog materials, may occur prior to ingest and are thus relevant for inclusion within an SIP. Documenting such pre-ingest preservation activities provides a comprehensive record of the efforts taken to convert, preserve, and prepare digital objects for archiving and future access.

The Using PREMIS with METS guide by the Library of Congress offers detailed recommendations on how to effectively incorporate PREMIS metadata within a METS document, ensuring that vital preservation details are accurately represented and accessible.

In the context of <amdSec>, the SIP specification does not change or extend any of the requirements already defined by the Common Specification for Information Packages (for more information see section 5.3.4 of the CSIP).

3.5. Extended use of the METS file section (element fileSec)

The METS file section element <fileSec> is used to describe all the components included in the information package which have not been already included in the <amdSec> and <dmdSec> elements.

The main purpose of the METS <filSec> element is to serve as a “table of contents” or “manifest” for all the files included in the package, thus allowing the OAIS to validate the integrity and completeness of the files that are part of the package.

This means that the location and checksum of all the files that compose the SIP must be enlisted within the <fileSec> element. This includes files in the data, schemas and in the documentation folders.

The following table describes the differences in the <fileSec> between an E-ARK SIP and the CSIP.

ID Name, Location & Description Card & Level
SIP32 File format name
fileSec/fileGrp/file/@sip:FILEFORMATNAME
An optional attribute may be used if the MIMETYPE is not sufficient for the purposes of processing the information package.
Example: “Extensible Markup Language”
Example: “PDF/A”
Example: “ISO/IEC 26300:2006”
0..1
MAY
SIP33 File format version
fileSec/fileGrp/file/@sip:FILEFORMATVERSION
The version of the file format when the use of PREMIS has not been agreed upon in the submission agreement.
Example: “1.0”
0..1
MAY
SIP34 File format registry
fileSec/fileGrp/file/@sip:FILEFORMATREGISTRY
The name of the format registry used to identify the file format when the use of PREMIS has not been agreed upon in the submission agreement.
Example: “PRONOM”
0..1
MAY
SIP35 File format registry key
fileSec/fileGrp/file/@sip:FILEFORMATKEY
Key of the file format in the registry when use of PREMIS has not been agreed upon in the submission agreement.
Example: “fmt/101”
0..1
MAY

Example: METS example of an SIP with file information together with the info from CS IP.

<file ID="docx-file" MIMETYPE="application/vnd.openxmlformats-officedocument.wordprocessingml.document" SIZE="2554366" CREATED="2012-08-15T12:08:15.432+01:00" CHECKSUM="91B7A2C0A1614AA8F3DAF11DB4A1C981F14BAA25E6A0336F715B7C513E7A1557" CHECKSUMTYPE="SHA-256" sip:FILEFORMATNAME="Microsoft Word for Windows" sip:FILEFORMATVERSION="2007 onwards" sip:FORMATREGISTRY="PRONOM" sip:FORMATREGISTRYKEY="fmt/412">
  <FLocat LOCTYPE="URL" xlink:type="simple" xlink:href="documentation/File.docx">
  </FLocat>
</file>

3.6. Extended use of the METS structural map (element structMap)

The mandatory METS structural map element <structMap> is intended to provide an overview of the components included in the package. It can also link elements of that structure to associated content files and metadata. In the CSIP the structMap describes the higher-level structure of all the content in the root and may link to existing representations.

In the context of <structMap>, the SIP specification does not change or extend any of the requirements defined by the Common Specification for Information Packages (for more information see section 5.3.6 of the CSIP)

4. Content Information Type Specifications (CITS)

The concept of Content Information Type Specifications (CITS) constitutes an extension method designed to improve the interoperability and adaptability of the E-ARK Information Packages (IPs) at a content-specific level. By introducing CITS, E-ARK provides detailed guidelines for handling various types of digital content within archival processes, ensuring that these diverse content types are managed, exchanged and preserved in a manner that is both standardized and tailored to their unique characteristics.

A Content Information Type can be understood as a category of Content Information, for example, relational databases, scientific data or digitised maps. A CITS defines in technical terms how data and metadata (mainly in regard to the Information Object) should be formatted and placed within an Information Package in order to achieve interoperability between different stakeholders.

The SIP specification does not introduce extensions or exceptions to the concept of Content Information Type as it is formalised in the Common Specification for Information Packages. More information on this subject can be found in sections 1.2, 1.3 and 6.1 of the CSIP.

4.1. Submission Agreements

Interactions between Producers and the OAIS are often guided by a Submission Agreement, which establishes specific details about how these interactions should take place, e.g. the type of information expected to be exchanged, the metadata the Producer is expected to deliver, the logistics of the actual transfer, statements regarding access restrictions on the submitted material, etc.

Given the importance of Submission Agreements, the E-ARK SIP specification provides a way of referring such documents regardless of their form. A Submission Agreement can be delivered as a digital file (e.g. PDF or XML) or in analogue forms (i.e. paper document). More information about how to reference the Submission Agreement within the SIP can be found in the section dedicated to the metsHdr element.

According to PAIMAS ( Producer-Archive Interface Methodology Abstract Standard) a Submission Agreement should include a complete and precise definition of:

This specification includes a list of semantic elements that should be present in a standard Submission Agreement (see Appendix A). The list of semantic elements is inspired by PAIMAS and the Submission Agreement provided by the National Oceanic and Atmospheric Administration (NOAA).

The E-ARK SIP specification does not require the use of any of these semantic elements or in any way forbids the use of other Submission Agreement formats. This list is merely a recommendation.

5. Glossary

Term Definition
Archival creator Organisation unit or individual that creates records and/or manages records during their active use.
Archive An organisation that intends to preserve information for Access and (re)use by a Designated Community.
Delivering organisation The organisation delivering an information package to the archive. For stating and extending the information use of the “Producer organisation name” and “Submitting organisation name” elements is recommended.
ERMS A type of content management software known as an Electronic Records Management System.
Information Package A logical container composed of optional Content Information and optional associated Preservation Description Information. Associated with this Information Package is Packaging Information used to delimit and identify the Content Information and Package Description information used to facilitate searches for the Content Information.
Ingest The OAIS functional entity that contains the services and functions that accept Submission Information Packages from Producers, prepares Archival Information Packages for storage, and ensures that Archival Information Packages and their supporting Descriptive Information become established within the OAIS.
OAIS The Open Archival Information System is an archive (and a standard: ISO 14721:2003), consisting of an organisation of people and systems that has accepted the responsibility to preserve information and make it available for a Designated Community.
Producing organisation The organisational unit or individual that has the authority to transfer records to an archive. Usually the producer is also the records creator but this is not always the case, sometimes the producer is different from the records creator. For example: An author dies and her literary executor gains the authority to transfer her papers to an archive. The author is the records creator and the literary executor is the producer. For example: Department X gets reorganised out of existence and Department Y, which takes over the functional responsibilities of Department X, gains the authority to transfer the records of Department X to the archive. Department X is the records creator and Department Y is the producer. Counter example: The Department of Widget Science transfers some of its own records to the archive. The Department of Widget Science is the records creator and the producer.
Submission Information Package (SIP) An Information Package that is delivered by the Producer to the OAIS for use in the construction or update of one or more AIPs and/or the associated Descriptive Information.
Submitting organisation Name of the organisation submitting the package to the archive. Extends the delivery information since it may be the case that the content of a creator is held by another part of the organisation.

6. Bibliography

  1. A Checklist for Documenting PREMIS-METS Decisions in a METS Profile, 2010, URL: http://www.loc.gov/standards/premis/premis_mets_checklist.pdf
  2. E-ARK Report on Available Best Practices, 2014, URL: http://eark-project.com/resources/project-deliverables/6-d31-e-ark-report-on-available-best-practices
  3. e-SENS (Electronic Simple European Networked Services) project, 2015, URL: http://www.esens.eu/
  4. Encoded Archival Context for Corporate Bodies, Persons, and Families, 2015, URL: http://eac.staatsbibliothek-berlin.de
  5. FGS packet structure, 2013, URL: https://riksarkivet.se/Media/pdf-filer/Projekt/FGS_Earkiv_Paket.pdf
  6. Guidelines for using PREMIS with METS for exchange, Revised September 17, 2008, URL: http://www.loc.gov/standards/premis/guidelines-premismets.pdf
  7. Media Types, 2015, URL: https://www.iana.org/assignments/media-types/media-types.xhtml
  8. METS, 2015, URL: http://www.loc.gov/standards/mets/
  9. METS Profile Components, 2011, URL: http://www.loc.gov/standards/mets/profile_docs/components.html
  10. METS Profiles, 2012, URL: http://www.loc.gov/standards/mets/mets-profiles.html
  11. Producer, Submission Agreements: Glossary of Terms, 2015, URL: http://sites.tufts.edu/dca/about-us/research-initiatives/taper-tufts-accessioning-program-for-electronic-records/project-documentation/submission-agreements-glossary-of-terms/
  12. Producer-Archive Interface Methodology Abstract Standard (PAIMAS), 2004, URL: https://public.ccsds.org/Pubs/651x0m1.pdf
  13. Producer-Archive Interface Specification (PAIS) – CCSDS, 2014, URL: https://public.ccsds.org/Pubs/651x1b1.pdf
  14. Records Creator, Submission Agreements: Glossary of Terms, 2015, URL: http://sites.tufts.edu/dca/about-us/research-initiatives/taper-tufts-accessioning-program-for-electronic-records/project-documentation/submission-agreements-glossary-of-terms/
  15. Reference Model for an Open Archival Information System (OAIS), 2012, URL: https://public.ccsds.org/Pubs/650x0m2.pdf
  16. Lavoie B, The Open Archival Information System (OAIS) Reference Model: Introductory Guide (2nd Edition), 2014, URL: http://www.dpconline.org/component/docman/doc_download/1359-dpctw14-02

7. Appendices

7.1. Appendix A: Submission Agreement semantic elements

The following list of semantic elements provide a starting point for anyone willing to prepare a Submission Agreement. This list is not prescriptive, or by any means complete. It merely serves the purpose of outlining the most relevant semantic elements that should be present in a Submission Agreement.

7.1.1. Project information

7.1.2. Change management

7.1.3. Producer, Archive and Designated Community

7.1.4. Submission Information Package (SIP)

7.1.5. Submission Session Information

7.1.6. Ingest

7.1.7. Submission risks

7.2. Appendix B: E-ARK Information Package METS Example

7.2.1. Example 1: Example of a whole METS document describing an submission information package with no representations.

<mets:mets xmlns:mets="http://www.loc.gov/METS/" xmlns:csip="https://DILCIS.eu/XML/METS/CSIPExtensionMETS" xmlns:sip="https://DILCIS.eu/XML/METS/SIPExtensionMETS" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" OBJID="uuid-4422c185-5407-4918-83b1-7abfa77de182" LABEL="Accounting records of 2017" TYPE="OTHER" csip:OTHERTYPE="Accounting" PROFILE="https://earksip.dilcis.eu/profile/E-ARK-SIP-v2-2-0.xml" xsi:schemaLocation="http://www.loc.gov/METS/ http://www.loc.gov/standards/mets/mets.xsd         http://www.w3.org/1999/xlink http://www.loc.gov/standards/mets/xlink.xsd         https://DILCIS.eu/XML/METS/CSIPExtensionMETS https://earkcsip.dilcis.eu/schema/DILCISExtensionMETS.xsd         https://DILCIS.eu/XML/METS/SIPExtensionMETS https://earksip.dilcis.eu/schema/DILCISExtensionSIPMETS.xsd">
  <mets:metsHdr CREATEDATE="2018-04-24T14:37:49.602+01:00" LASTMODDATE="2018-04-24T14:37:49.602+01:00" RECORDSTATUS="NEW" csip:OAISPACKAGETYPE="SIP">
    <mets:agent ROLE="CREATOR" TYPE="OTHER" OTHERTYPE="SOFTWARE">
      <mets:name>
        RODA-in
      </mets:name>
      <mets:note csip:NOTETYPE="SOFTWARE VERSION">
        2.7.2
      </mets:note>
    </mets:agent>
    <mets:agent ROLE="ARCHIVIST" TYPE="ORGANIZATION">
      <mets:name>
        The Swedish health agency
      </mets:name>
      <mets:note csip:NOTETYPE="IDENTIFICATIONCODE">
        VAT:SE201345098701
      </mets:note>
    </mets:agent>
    <mets:agent ROLE="CREATOR" TYPE="ORGANIZATION">
      <mets:name>
        The agency, Personnel
      </mets:name>
      <mets:note csip:NOTETYPE="IDENTIFICATIONCODE">
        VAT:SE2098109810-AF87
      </mets:note>
    </mets:agent>
    <mets:agent ROLE="CREATOR" TYPE="INDIVIDUAL">
      <mets:name>
        Sven Svensson
      </mets:name>
      <mets:note>
        Phone: 08-123456, Email: sven.svensson@mail.mail
      </mets:note>
    </mets:agent>
    <mets:agent ROLE="PRESERVATION" TYPE="ORGANIZATION">
      <mets:name>
        The archives
      </mets:name>
      <mets:note csip:NOTETYPE="IDENTIFICATIONCODE">
        ID:1234567
      </mets:note>
    </mets:agent>
    <mets:altRecordID TYPE="SUBMISSIONAGREEMENT">
      http://submissionagreement.kb.se/dnr331-1144-2011/20120711/
    </mets:altRecordID>
    <mets:altRecordID TYPE="PREVIOUSSUBMISSIONAGREEMENT">
      FM 12-2387/12726, 2007-09-19
    </mets:altRecordID>
    <mets:altRecordID TYPE="REFERENCECODE">
      SE/RA/123456/24/P
    </mets:altRecordID>
    <mets:altRecordID TYPE="PREVIOUSREFERENCECODE">
      SE/FM/123/123.1/123.1.3
    </mets:altRecordID>
  </mets:metsHdr>
  <mets:dmdSec ID="dmdSecExample1" CREATED="2018-04-24T14:37:49.609+01:00">
    <mets:mdRef LOCTYPE="URL" MDTYPE="EAD" MDTYPEVERSION="2002" xlink:type="simple" xlink:href="metadata/descriptive/ead2002.xml" SIZE="903" CREATED="2018-04-24T14:37:49.609+01:00" CHECKSUM="F24263BF09994749F335E1664DCE0086DB6DCA323FDB6996938BCD28EA9E8153" CHECKSUMTYPE="SHA-256">
    </mets:mdRef>
  </mets:dmdSec>
  <mets:amdSec>
    <mets:digiprovMD ID="appdx1.digiprov-premis-file-1" CREATED="2018-04-24T14:37:52.783+01:00">
      <mets:mdRef LOCTYPE="URL" xlink:type="simple" xlink:href="metadata/preservation/premis1.xml" MDTYPE="PREMIS" MDTYPEVERSION="3.0" MIMETYPE="text/xml" SIZE="1211" CREATED="2018-04-24T14:37:52.783+01:00" CHECKSUM="8aa278038dbad54bbf142e7d72b493e2598a94946ea1304dc82a79c6b4bac3d5" CHECKSUMTYPE="SHA-256" LABEL="premis1.xml">
      </mets:mdRef>
    </mets:digiprovMD>
    <mets:digiprovMD ID="appdx1.digiprov-premis-file-2" CREATED="2018-04-24T14:47:52.783+01:00">
      <mets:mdRef LOCTYPE="URL" xlink:type="simple" xlink:href="metadata/preservation/premis2.xml" MDTYPE="PREMIS" MDTYPEVERSION="3.0" MIMETYPE="text/xml" SIZE="2854" CREATED="2018-04-24T14:37:52.783+01:00" CHECKSUM="d1dfa585dcc9d87268069dc58d5e47956434ec3db4087a75a3885d287f15126f" CHECKSUMTYPE="SHA-256" LABEL="premis2.xml">
      </mets:mdRef>
    </mets:digiprovMD>
  </mets:amdSec>
  <mets:fileSec ID="appdx1.filesec-docx-file-1">
    <mets:fileGrp ID="appdx1.filegrp-doc" USE="Documentation">
      <mets:file ID="appdx1.docx-file" MIMETYPE="application/vnd.openxmlformats-officedocument.wordprocessingml.document" SIZE="2554366" CREATED="2012-08-15T12:08:15.432+01:00" CHECKSUM="91B7A2C0A1614AA8F3DAF11DB4A1C981F14BAA25E6A0336F715B7C513E7A1557" CHECKSUMTYPE="SHA-256" sip:FILEFORMATNAME="Microsoft Word for Windows" sip:FILEFORMATVERSION="2007 onwards" sip:FORMATREGISTRY="PRONOM" sip:FORMATREGISTRYKEY="fmt/412">
        <mets:FLocat LOCTYPE="URL" xlink:type="simple" xlink:href="documentation/File.docx">
        </mets:FLocat>
      </mets:file>
      <mets:file ID="appdx1.file-2-docx" MIMETYPE="application/vnd.openxmlformats-officedocument.wordprocessingml.document" SIZE="2554366" CREATED="2012-08-15T12:08:15.432+01:00" CHECKSUM="91B7A2C0A1614AA8F3DAF11DB4A1C981F14BAA25E6A0336F715B7C513E7A1557" CHECKSUMTYPE="SHA-256" sip:FILEFORMATNAME="Microsoft Word for Windows" sip:FILEFORMATVERSION="2007 onwards" sip:FORMATREGISTRY="PRONOM" sip:FORMATREGISTRYKEY="fmt/412">
        <mets:FLocat LOCTYPE="URL" xlink:type="simple" xlink:href="documentation/File2.docx">
        </mets:FLocat>
      </mets:file>
    </mets:fileGrp>
    <mets:fileGrp ID="appdx1.filegrp-schema" USE="Schemas">
      <mets:file ID="appdx1.file.ead" MIMETYPE="application/xml" SIZE="123917" CREATED="2018-04-24T14:37:49.617+01:00" CHECKSUM="0BF9E16ADE296EF277C7B8E5D249D300F1E1EB59F2DCBD89644B676D66F72DCC" CHECKSUMTYPE="SHA-256" sip:FILEFORMATNAME="XML Schema Definition" sip:FORMATREGISTRY="PRONOM" sip:FORMATREGISTRYKEY="x-fmt/280">
        <mets:FLocat LOCTYPE="URL" xlink:type="simple" xlink:href="schemas/ead2002.xsd">
        </mets:FLocat>
      </mets:file>
    </mets:fileGrp>
    <mets:fileGrp ID="appdx1.filegrp.data" USE="Representations/Submission/Data" csip:CONTENTINFORMATIONTYPE="SIARDDK">
      <mets:file ID="appdx1.file.siard" MIMETYPE="application/xml" SIZE="1338744" CREATED="2018-04-24T14:37:49.617+01:00" CHECKSUM="7176A627870CFA3854468EC43C5A56F9BD8B30B50A983B8162BF56298A707667" CHECKSUMTYPE="SHA-256" ADMID="appdx1.digiprov-premis-file-2 appdx1.digiprov-premis-file-1" sip:FILEFORMATNAME="Extensible Markup Language" sip:FILEFORMATVERSION="1.0" sip:FORMATREGISTRY="PRONOM" sip:FORMATREGISTRYKEY="fmt/101">
        <mets:FLocat LOCTYPE="URL" xlink:type="simple" xlink:href="representations/submission/data/SIARD.xml">
        </mets:FLocat>
      </mets:file>
    </mets:fileGrp>
  </mets:fileSec>
  <mets:structMap ID="appdx1.struct" TYPE="PHYSICAL" LABEL="CSIP">
    <mets:div ID="appdx1.div.struct" LABEL="uuid-4422c185-5407-4918-83b1-7abfa77de182">
      <mets:div ID="appdx1.div.md" LABEL="Metadata" ADMID="appdx1.digiprov-premis-file-1 appdx1.digiprov-premis-file-2" DMDID="dmdSecExample1">
      </mets:div>
      <mets:div ID="appdx1.div.doc" LABEL="Documentation">
        <mets:fptr FILEID="appdx1.filegrp-doc">
        </mets:fptr>
      </mets:div>
      <mets:div ID="appdx1.div.schm" LABEL="Schemas">
        <mets:fptr FILEID="appdx1.filegrp-schema">
        </mets:fptr>
      </mets:div>
      <mets:div ID="appdx1.div.reps" LABEL="Representations">
        <mets:fptr FILEID="appdx1.filegrp.data">
        </mets:fptr>
      </mets:div>
    </mets:div>
  </mets:structMap>
</mets:mets>

7.3. Appendix C: External Schema

7.3.1. E-ARK SIP METS Extension

Location: https://earksip.dilcis.eu/schema/DILCISExtensionSIPMETS.xsd

Context: XML-schema for the attributes added by SIP

Note: An extension schema with the added attributes for use in this profile. The schema is used with a namespace prefix of sip.

7.3.2. E-ARK CSIP METS Extension

Location: http://earkcsip.dilcis.eu/schema/DILCISExtensionMETS.xsd

Context: XML-schema for the attributes added by CSIP

Note: An extension schema with the added attributes for use in this profile. The schema is identified using the namespace prefix csip.

7.4. Appendix D: External Vocabularies

7.4.1. Package status

Maintained By: DILCIS Board

Location: http://earksip.dilcis.eu/schema/SIPVocabularyRecordStatus.xml

Context: Used in @RECORDSTATUS

Note: Describes the status of the package.

7.4.2. Alternative record ID's

Maintained By: DILCIS Board

Location: http://earksip.dilcis.eu/schema/SIPVocabularyRecordIDType.xml

Context: Used in altrecordID/@TYPE

Note: Describes the type of the alternative record ID.

7.4.3. Note type

Maintained By: DILCIS Board

Location: http://earkcsip.dilcis.eu/schema/CSIPVocabularyNoteType.xml

Context: Used in @csip:NOTETYPE

Note: Describes the type of a note for an agent.

7.4.4. OAIS Package type

Maintained By: DILCIS Board

Location: http://earkcsip.dilcis.eu/schema/CSIPVocabularyOAISPackageType.xml

Context: Used in @csip:OAISPACKAGETYPE

Note: Describes the OAIS type the package belongs to in the OAIS reference model.

7.5. Appendix E: E-ARK SIP Metadata Requirements

7.5.1. E-ARK SIP METS Profile 2.1 Requirements

ID Name, Location & Description Card & Level
SIP1 Package name
mets/@LABEL
An optional short text describing the contents of the package, e.g. “Accounting records of 2017”.
0..1
MAY
SIP2 METS Profile
mets/@PROFILE
The value is set to “https://earksip.dilcis.eu/profile/E-ARK-SIP-v2-2-0.xml”.
1..1
MUST
SIP3 Package status
metsHdr/@RECORDSTATUS
A way of indicating the status of the package and to instruct the OAIS on how to properly handle the package. If not set, the expected behaviour is equal to NEW.
0..1
MAY
SIP4 OAIS Package type information
metsHdr/@csip:OAISPACKAGETYPE
@csip:OAISPACKAGETYPE is used with the value “SIP”.
1..1
MUST
SIP5 Submission agreement
metsHdr/altRecordID
A reference to the Submission Agreement associated with the package.
@TYPE is used with the value “SUBMISSIONAGREEMENT”.
Example: RA 13-2011/5329; 2012-04-12
Example: http://submissionagreement.kb.se/dnr331-1144-2011/20120711/
Note: It is recommended to use a machine-readable format for a better description of a submission agreement.
For example, the submission agreement developed by Docuteam GmbH http://www.loc.gov/standards/mets/profiles/00000041.xml
0..1
MAY
SIP6 Previous Submission agreement
metsHdr/altRecordID
An optional reference to a previous submission agreement(s) which the information may have belonged to.
@TYPE is used with the value “PREVIOUSSUBMISSIONAGREEMENT”.
Example: FM 12-2387/12726, 2007-09-19
Example: http://submissionagreement.kb.se/dnr331-1144-2011/20120711/
Note: It is recommended to use a machine-readable format for a better description of a submission agreement.
For example, the submission agreement developed by Docuteam GmbH http://www.loc.gov/standards/mets/profiles/00000041.xml
0..*
MAY
SIP7 Archival reference code
metsHdr/altRecordID
An optional reference code indicating where in the archival hierarchy the package shall be placed in the OAIS.
@TYPE is used with the value “REFERENCECODE”.
Example: FM 12-2387/12726, 2007-09-19
0..1
MAY
SIP8 Previous archival reference code
metsHdr/altRecordID
In cases where the SIP originates from other institutions maintaining a reference code structure, this element can be used to record these reference codes and therefore support the provenance of the package when a whole archival description is not submitted with the submission.
@TYPE is used with the value “PREVIOUSREFERENCECODE”.
Example: SE/FM/123/123.1/123.1.3
0..*
MAY
SIP9 Archival creator agent
metsHdr/agent
A wrapper element that enables to encode the name of the organisation or person that originally created the data being transferred. Please note that this might be different from the organisation which has been charged with preparing and sending the SIP to the archives.
0..1
MAY
SIP10 Archival creator agent role
metsHdr/agent/@ROLE
The role of the person(s) or institution(s) responsible for the document/collection.
1..1
MUST
SIP11 Archival creator agent type
metsHdr/agent/@TYPE
The type of the archival creator agent is “ORGANIZATION” or “INDIVIDUAL”.
1..1
MUST
SIP12 Archival creator agent name
metsHdr/agent/name
The name of the organisation(s) that originally created the data being transferred.
Please note that this might be different from the organisation which has been charged with preparing and sending the SIP to the archives.
1..1
MUST
SIP13 Archival creator agent additional information
metsHdr/agent/note
The archival creator agent has a note providing a unique identification code for the archival creator.
0..1
MAY
SIP14 Classification of the archival creator agent additional information
metsHdr/agent/note/@csip:NOTETYPE
The archival creator agent note is typed with the value of “IDENTIFICATIONCODE”.
1..1
MUST
SIP15 Submitting agent
metsHdr/agent
A wrapper element that enables to encode the name of the organisation or person submitting the package to the archive.
1..1
MUST
SIP16 Submitting agent role
metsHdr/agent/@ROLE
The role of the person(s) or institution(s) responsible for creating and/or submitting the package.
1..1
MUST
SIP17 Submitting agent type
metsHdr/agent/@TYPE
The type of the submitting agent is “ORGANIZATION” or “INDIVIDUAL”.
1..1
MUST
SIP18 Submitting agent name
metsHdr/agent/name
Name of the organisation submitting the package to the archive.
1..1
MUST
SIP19 Submitting agent additional information
metsHdr/agent/note
The submitting agent has a note providing a unique identification code for the submitter.
0..1
MAY
SIP20 Classification of the submitting agent additional information
metsHdr/agent/note/@csip:NOTETYPE
The submitting agent note is typed with the value of “IDENTIFICATIONCODE”.
1..1
MUST
SIP21 Contact person agent
metsHdr/agent
A wrapper element that enables to encode the name of the contact person for the submission.
0..*
MAY
SIP22 Contact person agent role
metsHdr/agent/@ROLE
The role of the contact person is “CREATOR”.
1..1
MUST
SIP23 Contact person agent type
metsHdr/agent/@TYPE
The type of the contact person agent is “INDIVIDUAL”.
1..1
MUST
SIP24 Contact person agent name
metsHdr/agent/name
Name of the contact person.
1..1
MUST
SIP25 Contact person agent additional information
metsHdr/agent/note
The submitting agent has one or more notes giving the contact information.
0..*
MAY
SIP26 Preservation agent
metsHdr/agent
A wrapper element that enables to encode the name of the organisation or person that preserves the package.
0..1
MAY
SIP27 Preservation agent role
metsHdr/agent/@ROLE
The role of the preservation agent is “PRESERVATION”.
1..1
MUST
SIP28 Preservation agent type
metsHdr/agent/@TYPE
The type of the submitting agent is “ORGANIZATION”.
1..1
MUST
SIP29 Preservation agent name
metsHdr/agent/name
Name of the organisation preserving the package.
1..1
MUST
SIP30 Preservation agent additional information
metsHdr/agent/note
The preservation agent has a note providing a unique identification code for the archival creator.
0..1
MAY
SIP31 Classification of the preservation agent additional information
metsHdr/agent/note/@csip:NOTETYPE
The preservation agent note is typed with the value of “IDENTIFICATIONCODE”.
1..1
MUST
REF_CSIP_1 Descriptive metadata
N/A
The SIP dmdSec element should comply with dmdSec requirements in the CSIP profile.
N/A
SHOULD
REF_CSIP_2 Administrative metadata
N/A
The SIP amdSec element should comply with amdSec requirements in the CSIP profile.
N/A
SHOULD
SIP32 File format name
fileSec/fileGrp/file/@sip:FILEFORMATNAME
An optional attribute may be used if the MIMETYPE is not sufficient for the purposes of processing the information package.
Example: “Extensible Markup Language”
Example: “PDF/A”
Example: “ISO/IEC 26300:2006”
0..1
MAY
SIP33 File format version
fileSec/fileGrp/file/@sip:FILEFORMATVERSION
The version of the file format when the use of PREMIS has not been agreed upon in the submission agreement.
Example: “1.0”
0..1
MAY
SIP34 File format registry
fileSec/fileGrp/file/@sip:FILEFORMATREGISTRY
The name of the format registry used to identify the file format when the use of PREMIS has not been agreed upon in the submission agreement.
Example: “PRONOM”
0..1
MAY
SIP35 File format registry key
fileSec/fileGrp/file/@sip:FILEFORMATKEY
Key of the file format in the registry when use of PREMIS has not been agreed upon in the submission agreement.
Example: “fmt/101”
0..1
MAY
REF_CSIP_3 Structural description of the package
N/A
The SIP structMap element should comply with structMap requirements in the CSIP profile.
N/A
SHOULD
REF_METS_1 structLink
N/A
Section not defined or used in CSIP, additional own uses may occur.
Information regarding the structural links is found in the METS Primer
N/A
MAY
REF_METS_2 behaviorSec
N/A
Section not defined or used in CSIP, additional own uses may occur.
Information regarding the behavior section is found in the METS Primer
N/A
MAY

Postface

I Authors

Name Organisation
Miguel Ferreira KEEP SOLUTIONS (KEEPS)

I.I. Contributors to previous version

Name Organisation
Carl Wilson Open Preservation Foundation
Tarvo Kärberg Estonian National Archives (NAE)
Anders Bo Nielsen Danish National Archives (DNA)
Björn Skog ES Solutions (ESS)
Gregor Zavrsnik Slovenian National Archives (SNA)
Hélder Silva KEEP SOLUTIONS (KEEPS)
Miguel Ferreira KEEP SOLUTIONS (KEEPS)
Karin Bredenberg Kommunalförbundet Sydarkivera (SYD)
Kathrine Hougaard Edsen Johansen Danish National Archives (DNA)
Levente Szilágyi National Archives of Hungary (NAH)
Phillip Mike Tømmerholt Danish National Archives (DNA)
Kuldar Aas Estonian National Archives (NAE)
Sven Schlarb Austrian Institute of Technology (AIT)
David Anderson University of Brighton
Andrew Wilson University of Brighton
Jaime Kaminski (reviewer) Highbury Associates
Luís Miguel Ferros (reviewer) KEEP SOLUTIONS (KEEPS)

II Revision History

Revision Date Authors Org Description
0.1 20.10.2014 Tarvo Kärberg NAE First draft.
0.2 13.11.2014 Tarvo Kärberg NAE Updating content.
0.3 02.12.2014 Tarvo Kärberg NAE Updating content.
0.4 17.01.2015 Tarvo Kärberg NAE Updating content.
0.6 23.01.2015 Anders Bo Nielsen DNA Updating content.
0.5 21.01.2015 Karin Bredenberg ESS Updating content.
0.7 23.01.2015 Kathrine Hougaard Edsen DNA Updating content.
0.71 26.01.2015 Björn Skog ESS Updating content.
0.72 27.01.2015 Hélder Silva KEEPS Updating content.
0.8 27.01.2015 Angela Dappert DLM/UPHEC Quality assurance and proof-reading.
0.9 29.01.2017 Kuldar Aas NAE Quality assurance and proof-reading.
0.91 30.01.2015 David Anderson UPHEC Quality assurance and proof-reading.
1.0 30.01.2015 Tarvo Kärberg NAE Final version (D3.2).
0.1 11.05.2015 Karin Bredenberg ESS/NAS Updating content.
0.3 27.07.2015 Tarvo Kärberg NAE Updating content.
0.2 30.06.2015 Tarvo Kärberg NAE Updating content.
0.4 23.10.2015 Tarvo Kärberg NAE Updating content, synchronising with the SMURF profile.
0.41 17.11.2015 Tarvo Kärberg NAE Integrating the feedback.
0.42 07.12.2015 Tarvo Kärberg NAE Updating content.
0.5 12.01.2016 Tarvo Kärberg NAE Updating content, synchronising with the Common Specification.
0.6 15.01.2016 Anders Bo Nielsen DNA Updating content.
0.61 15.01.2016 Gregor Zavrsnik SNA Updating content.
0.62 18.01.2016 Tarvo Kärberg NAE Updating content.
0.63 20.01.2016 Phillip Mike Tømmerholt DNA Updating content.
0.64 25.01.2016 Phillip Mike Tømmerholt DNA Updating content.
0.7 26.01.2016 Sven Schlarb AIT Quality assurance and proof-reading.
0.8 27.01.2016 Kuldar Aas NAE Quality assurance and proof-reading.
0.9 29.01.2016 Andrew Wilson and David Anderson University of Brighton Quality assurance and proof-reading.
1.0 29.01.2016 Tarvo Kärberg NAE Final version (general paart of D3.3)
1.1 14.07.2016 Tarvo Kärberg NAE Incorporating agreements made in the Common Specification work group.
1.2 12.12.2016 Tarvo Kärberg NAE Incorporating agreements made in the Common Specification work group.
1.3 13.01.2017 Tarvo Kärberg NAE Small updates.
1.4 31.01.2017 Tarvo Kärberg NAE Finalising the specification.
2.0.0 15.03.2019 Miguel Ferreira KEEPS Updated to v2.0 with CSIP
2.0.1 09.09.2019 Karin Bredenberg SNA Correction @LABEL and @USE attributes, typos, layout and PDF formatting.
2.0.2 28.10.2019 Karin Bredenberg SYD Fixed schema paths.
2.0.3 08.01.2020 K. Bredenberg, C.Wilson SYD & OPF Fixed error in value list note type.
2.0.4 12.06.2020 K. Bredenberg, C.Wilson & J. Kaminski SYD, OPF & HIGH Update in example ID:s, preface text and output display update
2.1.0 15.10.2021 K. Bredenberg, C.Wilson SYD & OPF Update of specification to version 2.1. Changed the cardinality of agent elements to follow METS and added more agents examples.
2.2.0 17.05.2024 Miguel Ferreira KEEPS Fixes to elements cardinality. Versioning of the METS profile. Overall improvements to the specification text.

III Acknowledgements

The Common Specification for Information Packages was first developed within the E-ARK project in 2014 – 2017. E-ARK was an EC-funded pilot action project in the Competiveness and Innovation Programme 2007- 2013, Grant Agreement no. 620998 under the Policy Support Programme.

We would like to thank the National Archives of Sweden and Karin Bredenberg for their support and the availability of the Swedish national Common Specifications, upon which most of this document has been built.

The authors of this deliverable would like to thank all national archives, tool developers and other stakeholders who provided valuable knowledge about their requirements for information packages and feedback to this specification!

IV Contact & Feedback

The Common Specification for Information Packages is maintained by the Digital Information LifeCycle Interoperability Standard Board (DILCIS Board). For further information about the DILCIS Board or feedback on the current document please consult the website http://www.dilcis.eu/ or contact us at info@dilcis.eu.