diff --git a/specification/E-ARK-SIP_specification-v2.0.md b/specification/E-ARK-SIP_specification-v2.0.md index 155908b..5023a43 100644 --- a/specification/E-ARK-SIP_specification-v2.0.md +++ b/specification/E-ARK-SIP_specification-v2.0.md @@ -1,20 +1,22 @@ # Introduction -According to the Open Archival Information System Reference Model (OAIS) every submission of information to an archive occurs as one or more discrete transmissions of Submission Information Packages (SIP). Unfortunately, the OAIS itself does not specify how these information packages should look like. +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. -The EU funded E-ARK project (2014-2017) first acknowledged this problem and started to develop a solution in the form of a package specification. This specification is now part of a set of specifications currently managed by an independent body named the Digital Information LifeCycle Interoperability Standards Board ([DILCIS Board](http://www.dilcis.eu)). +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](http://www.dilcis.eu)), an independent entity dedicated to the maintenance and promotion of digital information lifecycle standards. ## 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: -- Define the general structure for a Submission Information Package format in a way that it is suitable for a wide variety of archival scenarios, e.g. document and image collections, databases or geographical data; +- Define the general structure for a Submission Information Package format in a way that it is suitable for a wide variety of archival scenarios, e.g. document and image collections, databases, geographical data, etc.; - Enhance interoperability between Producers and Archives; - Recommend best practices regarding metadata, content and structure of Submission Information Packages. ## Target audience -The target audience for this specification is records creators, archival institutions and software providers that are responsible with preparing, packaging, delivering and receiving packages of information to be archived in an OAIS, i.e. pre-ingest and ingest functional units. +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. ## Definition of SIP @@ -22,52 +24,52 @@ The OAIS reference model defines a Submission Information Package (SIP) as follo > 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. It enhances the specification by incorporating specific requirements essential for the processes of selecting, packaging, transmitting, receiving, validating, and ingesting information originally held by a Producer. - -In essence, the SIP represents a comprehensive package of information, prepared by a Producer, for transmission to an Archive for the purpose of ingestion by the OAIS. +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. # Structure -The SIP specification follows a structure that is common to all 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). +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](#fig2). A package with zero representations means that it only includes metadata. This is a special type of Information Package that enables Producers to deliver updates to the metadata to previously ingested packages. +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](#fig2). 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](images/Fig_2_SIP.svg) -**Figure 2**: Simplified view of a package structure. +**Figure 2**: Simplified view of the structure of an information package. According to [PREMIS Version 3.0](http://www.loc.gov/standards/premis/v3/premis-3-0-final.pdf): > 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 can contain more than one representation 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, the most common one being the support for discoverability of resources within the OAIS (i.e. descriptive metadata). +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 a `metadata` folder at the representation level. In such cases, the `metadata` folder under representations is considered optional. The SIP also accounts for the following additional folders that can exist both at the root level or under the `representations` folder ([Figure 3](#fig3)): +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](#fig3)): -- `documentation` – for including additional documentation about the `data` included in the package (e.g. a data dictionary for a SIARD file); -- `schemas` – for storing schemas of XML files included in the data or metadata. +- `documentation` – includes materials that provide additional context or clarification about the data it contains. For instance, this might encompass a data dictionary for a SIARD (Software-Independent Archiving of Relational Databases) file. Such documentation is crucial for ensuring that the data can be accurately interpreted, used, and preserved over time. It serves as a valuable resource for understanding the structure, meaning, and organization of the data, making it an essential component of the package for both current users and future stakeholder; +- `schemas` – designated for holding the schemas of XML files that are part of the data or metadata. It serves as a central repository for XML schemas, enabling consistent validation and interpretation of the XML structures within the package. This ensures that both the data and metadata are structured in a manner that adheres to predefined standards and formats, facilitating accurate data exchange and interoperability between systems. ![General SIP structure](images/Fig_3_SIP.svg "Example of the full use of the 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. +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. # METS The Metadata Encoding and Transmission Standard (METS) is a standard for encoding descriptive, administrative, and structural metadata expressed using the XML Schema Language. -The METS Schema for an E-ARK SIP is the same as for an E-ARK AIP or an E-ARK DIP. The actual requirements of the METS used in the E-ARK SIP are defined in the CSIP on section "5.3 Use of METS". However, there are some small differences between a METS instance of an E-ARK SIP and an E-ARK CSIP. Most of the differences consist of setting values of particular attributes, defining controlled vocabularies or making optional elements mandatory. +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. -These differences are manifested by means of a METS profile. The SIP METS profile extends the CSIP METS profile. As stated before, in this document only the differences between the SIP METS and the CSIP METS are highlighted. In order to fully understand how to create or interpret the METS file included within an SIP, it is necessary to read the CSIP. +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. ## Extended use of the METS root element (element `mets`) -The root of a METS document can contain a number of optional attributes, namespaces (`xmlns:`), locations for external schemas (`xsi:`) and a number of other elements. +The root element of a METS document `` 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 Common Specification for Information Packages (CSIP). +The following table describes the differences in the `` element between the E-ARK SIP and the `` element of a Common Specification for Information Packages (CSIP). !INCLUDE "implementation/metadata/mets/mets-root/requirements.md" @@ -75,11 +77,21 @@ The following table describes the differences in the `mets` element between the ## Extended use of the METS header (element `metsHdr`) -The METS header element `` includes information about the creator of the submission package, the original creator of the data, contact information of the person delivering the SIP, among other actors. These entities are typically called "agents" (see element `metsHdr/agent`). +The `` (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 `` element, which is nested within the `` element. + +Each `` element can describe a range of roles and responsibilities associated with the SIP, including but not limited to: -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`). +- **CREATOR**: This refers to the organization or individual responsible for assembling the SIP and preparing it for submission. This agent is typically responsible for ensuring that the SIP conforms to the required standards and specifications. +- **ARCHIVIST**: This agent refers to the individual or organization responsible for the document/collection.. In many cases, this may be different from the creator of the SIP, especially if the SIP contains archived materials or data collected from various sources. +- **SUBMITTER**: This details the contact information for the individual or entity responsible for the actual submission of the SIP to the archive or repository. This information is crucial for communication purposes, especially if there are queries or issues related to the SIP. +- **PRESERVATION**: This details the contact information for the individual or entity responsible for preservation functions. +- **OTHER**: There can be additional agents involved in the lifecycle of the SIP, such as editors, publishers, or custodians, each playing a specific role in the creation, maintenance, or submission of the digital content. -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 `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 `` 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. @@ -91,27 +103,29 @@ The following table describes the differences in the `metsHdr` between an E-ARK The METS descriptive metadata section `` 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 on in the Submission Agreement. +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 this regard, 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). +In the context of the `` 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). ## Extended use of METS administrative metadata section (element `amdSec`) -The METS administrative metadata section `` is used to include or reference technical and preservation metadata. +The `` (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. -Although seldom used, preservation metadata can be included in an SIP Preservation metadata is typically used to record the history of preservation events that influence the state of the information package. Normally, these take place after the package has been ingested into a digital repository, however an example of preservation event that can occur prior to the ingest process is the digitization of analogue material. This event takes place before the information is ingested and can be included in an SIP. +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 guide on [Using PREMIS with METS](https://www.loc.gov/standards/premis/premis-mets.html) provides recommendations on how to use the `` element to reference PREMIS metadata. +The [Using PREMIS with METS guide](https://www.loc.gov/standards/premis/premis-mets.html) 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. -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). +In the context of ``, 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). ## Extended use of the METS file section (element `fileSec`) -The METS file section element `` 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 METS file section element `` is used to describe all the components included in the information package which have not been already included in the `` and `` elements. + +The main purpose of the METS `` 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. -The main purpose of the METS file section 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 included in the package. This means that for all the files included in the package, their location and checksum need to be available and described in the `fileSec` element. That includes files in the `data`, `schemas` and in the `documentation` folders. +This means that the location and checksum of all the files that compose the SIP must be enlisted within the `` 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. +The following table describes the differences in the `` between an E-ARK SIP and the CSIP. !INCLUDE "implementation/metadata/mets/filesec/requirements.md" @@ -121,23 +135,23 @@ The following table describes the differences in the `fileSec` between an E-ARK The mandatory METS structural map element `` 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. -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.6 of the CSIP) +In the context of ``, 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) -# Content Information Type Specifications +# Content Information Type Specifications (CITS) -The concept of a Content Information Type Specification is essentially an extension method which allows for widening the interoperability scope of the E-ARK IPs into a content specific level. +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 Content Information Type Specification 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 in exchanging specific Content Information. +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 presents no 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. +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. -## Submission Agreement +## 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. +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 the Submission Agreement, the E-ARK SIP specification provides a way of referring to it regardless of its form. A submission agreement can be delivered in digital (e.g. PDF or XML file) 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. +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 the [PAIMAS, 2004](https://public.ccsds.org/Pubs/651x0m1.pdf) standard a Submission Agreement should include a complete and precise definition of: +According to [PAIMAS](https://public.ccsds.org/Pubs/651x0m1.pdf) ( Producer-Archive Interface Methodology Abstract Standard) a Submission Agreement should include a complete and precise definition of: - Information to be transferred (e.g. SIP contents, SIP packaging, data models, identification of the designated community, legal and contractual aspects); - Transfer definition (e.g. specification of the OAIS Data Submission Sessions); @@ -145,9 +159,9 @@ According to the [PAIMAS, 2004](https://public.ccsds.org/Pubs/651x0m1.pdf) stand - Change management (e.g. conditions for modification of the agreement, for breaking the agreement); - Schedule (submission timetable). -This specification includes a list of semantic elements that should be present in a standard Submission Agreement (see Appendix A). The E-ARK SIP specification does not require the use of any of these semantic elements or in any way forbids the use of any other Submission Agreement formats. The list of semantic elements provided simply serves as a baseline recommendation. +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 recommended list of semantic elements is inspired by the PAIMAS requirements and the [Submission Agreement template](https://www.ngdc.noaa.gov/wiki/images/f/f4/NOAA_Sub_Agreement.docx) 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. # Appendices @@ -160,8 +174,8 @@ The following list of semantic elements provide a starting point for anyone will ### Project information - **Project** - Elements of a transfer project. - - **Project Name** - Name of the transfer project (e.g. Transfer I, 2016). - - **Project ID** - Identification code of the transfer project (e.g. 201601122044). + - **Project Name** - Name of the transfer project (e.g. Transfer I, 2016). + - **Project ID** - Identification code of the transfer project (e.g. 201601122044). ### Change management @@ -260,16 +274,15 @@ The following list of semantic elements provide a starting point for anyone will # 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. | | +| 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. | diff --git a/specification/appendices/vocabs/vocabs.md b/specification/appendices/vocabs/vocabs.md index 50f85e1..c5db82d 100644 --- a/specification/appendices/vocabs/vocabs.md +++ b/specification/appendices/vocabs/vocabs.md @@ -1,55 +1,55 @@ - ### Package status - -**Maintained By:** DILCIS Board + -**Location:** [http://earksip.dilcis.eu/schema/SIPVocabularyRecordStatus.xml](http://earksip.dilcis.eu/schema/SIPVocabularyRecordStatus.xml) +**Maintained By:** DILCIS Board -**Context:** Used in `@RECORDSTATUS` +**Location:** [http://earksip.dilcis.eu/schema/SIPVocabularyRecordStatus.xml](http://earksip.dilcis.eu/schema/SIPVocabularyRecordStatus.xml) -**Description:** +**Context:** Used in `@RECORDSTATUS` -Describes the status of the package. +**Description:** +Describes the status of the package. ### Alternative record ID's - -**Maintained By:** DILCIS Board + -**Location:** [http://earksip.dilcis.eu/schema/SIPVocabularyRecordIDType.xml](http://earksip.dilcis.eu/schema/SIPVocabularyRecordIDType.xml) +**Maintained By:** DILCIS Board -**Context:** Used in `altrecordID/@TYPE` +**Location:** [http://earksip.dilcis.eu/schema/SIPVocabularyRecordIDType.xml](http://earksip.dilcis.eu/schema/SIPVocabularyRecordIDType.xml) -**Description:** +**Context:** Used in `altrecordID/@TYPE` -Describes the type of the alternative record ID. +**Description:** +Describes the type of the alternative record ID. ### Note type - -**Maintained By:** DILCIS Board + -**Location:** [http://earkcsip.dilcis.eu/schema/CSIPVocabularyNoteType.xml](http://earkcsip.dilcis.eu/schema/CSIPVocabularyNoteType.xml) +**Maintained By:** DILCIS Board -**Context:** Used in `@csip:NOTETYPE` +**Location:** [http://earkcsip.dilcis.eu/schema/CSIPVocabularyNoteType.xml](http://earkcsip.dilcis.eu/schema/CSIPVocabularyNoteType.xml) -**Description:** +**Context:** Used in `@csip:NOTETYPE` -Describes the type of a note for an agent. +**Description:** +Describes the type of a note for an agent. ### OAIS Package type + -**Maintained By:** DILCIS Board +**Maintained By:** DILCIS Board -**Location:** [http://earkcsip.dilcis.eu/schema/CSIPVocabularyOAISPackageType.xml](http://earkcsip.dilcis.eu/schema/CSIPVocabularyOAISPackageType.xml) +**Location:** [http://earkcsip.dilcis.eu/schema/CSIPVocabularyOAISPackageType.xml](http://earkcsip.dilcis.eu/schema/CSIPVocabularyOAISPackageType.xml) -**Context:** Used in `@csip:OAISPACKAGETYPE` +**Context:** Used in `@csip:OAISPACKAGETYPE` -**Description:** +**Description:** -Describes the OAIS type the package belongs to in the OAIS reference model. +Describes the OAIS type the package belongs to in the OAIS reference model. diff --git a/specification/implementation/metadata/mets/amdsec/requirements.md b/specification/implementation/metadata/mets/amdsec/requirements.md index 066ee40..456c488 100644 --- a/specification/implementation/metadata/mets/amdsec/requirements.md +++ b/specification/implementation/metadata/mets/amdsec/requirements.md @@ -1,3 +1,3 @@ -| ID | Name, Location & Description | Card & Level | -| ------- | ---------------------------- | ------------ | -| **REF_CSIP_2** | **Administrative metadata**

The DIP amdSec element should comply with
amdSec requirements in the CSIP profile. |
SHOULD | +| ID | Name, Location & Description | Card & Level | +| --------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------- | ------------ | +| **REF_CSIP_2** | **Administrative metadata**

The DIP amdSec element should comply with
amdSec requirements in the CSIP profile. |
SHOULD | diff --git a/specification/implementation/metadata/mets/filesec/examples.md b/specification/implementation/metadata/mets/filesec/examples.md index 5481515..a7a335c 100644 --- a/specification/implementation/metadata/mets/filesec/examples.md +++ b/specification/implementation/metadata/mets/filesec/examples.md @@ -1,10 +1,22 @@ - **Example:** METS example of an SIP with file information together with the info from CS IP. ```xml - - - + + + + ``` - diff --git a/specification/implementation/metadata/mets/filesec/requirements.md b/specification/implementation/metadata/mets/filesec/requirements.md index 30a4ed4..ff25174 100644 --- a/specification/implementation/metadata/mets/filesec/requirements.md +++ b/specification/implementation/metadata/mets/filesec/requirements.md @@ -1,6 +1,6 @@ -| ID | Name, Location & Description | Card & Level | -| ------- | ---------------------------- | ------------ | +| 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 | +| **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 | diff --git a/specification/implementation/metadata/mets/mets-root/examples.md b/specification/implementation/metadata/mets/mets-root/examples.md index a663161..43873c0 100644 --- a/specification/implementation/metadata/mets/mets-root/examples.md +++ b/specification/implementation/metadata/mets/mets-root/examples.md @@ -1,8 +1,12 @@ - **Example:** METS root element example with values from E-ARK-SIP as well as CS IP. ```xml - + ``` - diff --git a/specification/implementation/metadata/mets/mets-root/requirements.md b/specification/implementation/metadata/mets/mets-root/requirements.md index c8a2f8e..7370b79 100644 --- a/specification/implementation/metadata/mets/mets-root/requirements.md +++ b/specification/implementation/metadata/mets/mets-root/requirements.md @@ -1,4 +1,4 @@ -| 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.xml". | **1..1**
MUST | +| 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-1-1.xml". | **1..1**
MUST | diff --git a/specification/implementation/metadata/mets/metshdr/examples.md b/specification/implementation/metadata/mets/metshdr/examples.md index 6c454eb..f779e89 100644 --- a/specification/implementation/metadata/mets/metshdr/examples.md +++ b/specification/implementation/metadata/mets/metshdr/examples.md @@ -1,28 +1,36 @@ - **Example:** METS example of altrecordID's, and SIP agents following the SIP profile as well as CS IP. ```xml - + + The Swedish health agency VAT:SE201345098701 + The agency, Personnel VAT:SE2098109810-AF87 + Sven Svensson Phone: 08-123456, Email: sven.svensson@mail.mail + The archives ID:1234567 + http://submissionagreement.kb.se/dnr331-1144-2011/20120711/ FM 12-2387/12726, 2007-09-19 SE/RA/123456/24/P SE/FM/123/123.1/123.1.3 + ``` - diff --git a/specification/implementation/metadata/mets/metshdr/requirements.md b/specification/implementation/metadata/mets/metshdr/requirements.md index 3e9b663..be2b796 100644 --- a/specification/implementation/metadata/mets/metshdr/requirements.md +++ b/specification/implementation/metadata/mets/metshdr/requirements.md @@ -1,31 +1,31 @@ -| 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.
**See also:** [Package status](#VocabularyRECORDSTATUS) | **0..1**
MAY | -| **SIP4** | **OAIS Package type information**
`metsHdr/@csip:OAISPACKAGETYPE`
`@csip:OAISPACKAGETYPE` is used with the value "SIP".
**See also:** [OAIS Package type](#VocabularyOAISPackageType) | **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
**See also:** [Alternative record ID's](#VocabularyaltrecordIDTYPE) | **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
**See also:** [Alternative record ID's](#VocabularyaltrecordIDTYPE) | **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
**See also:** [Alternative record ID's](#VocabularyaltrecordIDTYPE) | **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
**See also:** [Alternative record ID's](#VocabularyaltrecordIDTYPE) | **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. | **0..***
MAY | -| **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".
**See also:** [Note type](#VocabularyNoteType) | **1..1**
MUST | -| **SIP15** | **Submitting agent**
`metsHdr/agent`
The name of the organisation or person that 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**
MAY | -| **SIP19** | **Submitting agent additional information**
`metsHdr/agent/note`
The submitting agent has a note providing a unique identification code for the archival creator. | **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".
**See also:** [Note type](#VocabularyNoteType) | **1..1**
MUST | -| **SIP21** | **Contact person agent**
`metsHdr/agent`
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`
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**
MAY | -| **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".
**See also:** [Note type](#VocabularyNoteType) | **1..1**
MUST | +| 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.
**See also:** [Package status](#VocabularyRECORDSTATUS) | **0..1**
MAY | +| **SIP4** | **OAIS Package type information**
`metsHdr/@csip:OAISPACKAGETYPE`
`@csip:OAISPACKAGETYPE` is used with the value "SIP".
**See also:** [OAIS Package type](#VocabularyOAISPackageType) | **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
**See also:** [Alternative record ID's](#VocabularyaltrecordIDTYPE) | **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
**See also:** [Alternative record ID's](#VocabularyaltrecordIDTYPE) | **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
**See also:** [Alternative record ID's](#VocabularyaltrecordIDTYPE) | **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
**See also:** [Alternative record ID's](#VocabularyaltrecordIDTYPE) | **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. | **0..\***
MAY | +| **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".
**See also:** [Note type](#VocabularyNoteType) | **1..1**
MUST | +| **SIP15** | **Submitting agent**
`metsHdr/agent`
The name of the organisation or person that 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 archival creator. | **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".
**See also:** [Note type](#VocabularyNoteType) | **1..1**
MUST | +| **SIP21** | **Contact person agent**
`metsHdr/agent`
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`
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".
**See also:** [Note type](#VocabularyNoteType) | **1..1**
MUST | diff --git a/specification/implementation/metadata/mets/structmap/requirements.md b/specification/implementation/metadata/mets/structmap/requirements.md index 2b99e0e..c9dd243 100644 --- a/specification/implementation/metadata/mets/structmap/requirements.md +++ b/specification/implementation/metadata/mets/structmap/requirements.md @@ -1,3 +1,3 @@ -| ID | Name, Location & Description | Card & Level | -| ------- | ---------------------------- | ------------ | -| **REF_CSIP_3** | **Structural description of the package**

The DIP structMap element should comply with
structMap requirements in the CSIP profile. |
SHOULD | +| ID | Name, Location & Description | Card & Level | +| --------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------- | ------------ | +| **REF_CSIP_3** | **Structural description of the package**

The DIP structMap element should comply with
structMap requirements in the CSIP profile. |
SHOULD | diff --git a/specification/metadata.md b/specification/metadata.md index 4d0e160..ffdfb8d 100644 --- a/specification/metadata.md +++ b/specification/metadata.md @@ -2,19 +2,7 @@ title: E-ARK SIP subtitle: Specification for Submission Information Packages abstract: | - This document constitutes a specification on how to produce and parse - E-ARK Submission Information Packages (SIP). The main objectives of this - specification are to define the general structure for a Submission - Information Package format in a way that it is suitable for a wide - variety of archival scenarios, e.g. document and image collections, - databases or geographical data, etc.; enhance interoperability between - Producers and Archives and recommend best practices regarding metadata, - content and structure of Submission Information Packages. The target - audience for this specification is records creators, archival - institutions and software providers that are responsible with preparing, - packaging, delivering and receiving packages of information to be archived - in an Open Archival Information System Reference Model (OAIS), i.e. - pre-ingest and ingest functional units. +This document provides a comprehensive specification for the creation and parsing of E-ARK Submission Information Packages (SIP). Its primary goals include outlining a general-purpose structure for Submission Information Packages that accommodates a diverse array of archival materials—such as document and image collections, databases, and geographical data. Additionally, it aims to improve interoperability between Producers and Archives by recommending best practices for metadata, content, and the structural organization of Submission Information Packages. 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. version: ${RELEASE_VERSION} date: ${RELEASE_DATE} --- diff --git a/specification/postface/authors.md b/specification/postface/authors.md index e1856bf..a7df8e4 100644 --- a/specification/postface/authors.md +++ b/specification/postface/authors.md @@ -1,31 +1,27 @@ +## I Authors -I Authors ---------- - -| Name | Organisation | -| -------------------------------- | -------------------------------------------------- | -| Miguel Ferreira | Keep Solutions (KEEPS) | -| Hélder Silva | Keep Solutions (KEEPS) | -| Karin Bredenberg | Kommunalförbundet Sydarkivera (SYD) | -| Carl Wilson | Open Preservation Foundation | -| Jaime Kaminski (reviewer) | Highbury Associates | -| Luís Miguel Ferros (reviewer) | Keep Solutions (KEEPS) | +| Name | Organisation | +| --------------- | ---------------------- | +| Miguel Ferreira | KEEP SOLUTIONS (KEEPS) | ### I.I. Contributors to previous version -| Name | Organisation | -| -------------------------------- | -------------------------------------------------- | -| 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) | -| Helder 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 | +| 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) | diff --git a/specification/postface/revisions.md b/specification/postface/revisions.md index 6bdee25..6494a67 100644 --- a/specification/postface/revisions.md +++ b/specification/postface/revisions.md @@ -1,45 +1,44 @@ +## II Revision History -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. | +| 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. |