oSIST prEN 9300-021:2026

• Abstract:

  This document specifies requirements for metadata of archive packages intended for the long-term archiving of digital product information.

• Status: Not Published
• Public Enquiry End Date: 09-Sep-2026
• ICS: 01.110 - Technical product documentation
• ICS: 35.240.30 - IT applications in information, documentation and publishing
• ICS: 49.020 - Aircraft and space vehicles in general
• Technical Committee: I13 - Imaginarni 13
• Current Stage: 4020 - Public enquire (PE) (Adopted Project)
• Start Date: 14-Jul-2026
• Due Date: 01-Dec-2026
• Ref Project: prEN 9300-021 - Aerospace series - LOTAR - LOng Term Archiving and Retrieval of digital technical product documentation such as 3D, CAD and PDM data - Part 021: Metadata for archival packages

SLOVENSKI STANDARD
01-september-2026
Aeronavtika - LOTAR - Dolgoročno arhiviranje in iskanje digitalne tehnične
dokumentacije o izdelkih, kot so podatki o 3D, CAD in PDM - 21. del: Metapodatki
za arhivske pakete
Aerospace series - LOTAR - LOng Term Archiving and Retrieval of digital technical
product documentation such as 3D, CAD and PDM data - Part 021: Metadata for archival
packages
Luft- und Raumfahrt - LOTAR - Langzeit-Archivierung und -Bereitstellung digitaler
technischer Produktdokumentationen, wie zum Beispiel von 3D-, CAD- und PDM-Daten -
Teil 021: Metadaten für Archivpakete
Ta slovenski standard je istoveten z: prEN 9300-021
ICS:
01.110 Tehnična dokumentacija za Technical product
izdelke documentation
35.240.30 Uporabniške rešitve IT v IT applications in information,
informatiki, dokumentiranju in documentation and
založništvu publishing
49.020 Letala in vesoljska vozila na Aircraft and space vehicles in
splošno general
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

DRAFT
EUROPEAN STANDARD
NORME EUROPÉENNE
EUROPÄISCHE NORM
June 2026
ICS 01.110
English Version
Aerospace series - LOTAR - LOng Term Archiving and
Retrieval of digital technical product documentation such
as 3D, CAD and PDM data - Part 021: Metadata for archival
packages
Luft- und Raumfahrt - LOTAR - Langzeit-Archivierung
und -Bereitstellung digitaler technischer
Produktdokumentationen, wie zum Beispiel von 3D-,
CAD- und PDM-Daten - Teil 021: Metadaten für
Archivpakete
This draft European Standard is submitted to CEN members for enquiry. It has been drawn up by the Technical Committee ASD-
STAN.
If this draft becomes a European Standard, CEN members are bound to comply with the CEN/CENELEC Internal Regulations
which stipulate the conditions for giving this European Standard the status of a national standard without any alteration.

This draft European Standard was established by CEN in three official versions (English, French, German). A version in any other
language made by translation under the responsibility of a CEN member into its own language and notified to the CEN-CENELEC
Management Centre has the same status as the official versions.

CEN members are the national standards bodies of Austria, Belgium, Bulgaria, Croatia, Cyprus, Czech Republic, Denmark, Estonia,
Finland, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway,
Poland, Portugal, Republic of North Macedonia, Romania, Serbia, Slovakia, Slovenia, Spain, Sweden, Switzerland, Türkiye and
United Kingdom.
Recipients of this draft are invited to submit, with their comments, notification of any relevant patent rights of which they are
aware and to provide supporting documentation.

Warning : This document is not a European Standard. It is distributed for review and comments. It is subject to change without
notice and shall not be referred to as a European Standard.

EUROPEAN COMMITTEE FOR STANDARDIZATION
COMITÉ EUROPÉEN DE NORMALISATION

EUROPÄISCHES KOMITEE FÜR NORMUNG

CEN-CENELEC Management Centre: Rue de la Science 23, B-1040 Brussels
© 2026 CEN All rights of exploitation in any form and by any means reserved Ref. No. prEN 9300-021:2026 E
worldwide for CEN national Members.

Contents Page
European foreword . 3
Introduction . 4
1 Scope . 5
2 Normative references . 5
3 Terms and definitions . 5
4 Principle . 5
5 Background . 6
5.1 Long-term archiving and retrieval (LOTAR) . 6
5.2 Open archival information system reference model (OAIS) . 7
5.2.1 OAIS and LOTAR . 7
5.2.2 Preservation description information (OAIS) . 7
5.2.3 Packaging information (OAIS) . 8
5.2.4 Descriptive information (OAIS) . 8
5.3 LOTAR specific information . 9
5.4 Metadata schema and encoding . 9
5.5 Controlled vocabularies . 10
5.6 Metadata-only information packages . 10
6 Requirements . 10
6.1 General requirements . 10
6.2 Detailed metadata requirements for application of the OAIS reference model to
LOTAR use cases . 11
6.2.1 General. 11
6.2.2 Preservation description information . 11
6.2.3 Packaging information . 14
6.2.4 Descriptive information . 15
Annex A (informative) PREMIS . 18
Annex B (informative) METS . 20
Annex C (informative) XFDU . 22
Annex D (informative) Example metadata . 25
Bibliography . 30

European foreword
This document (prEN 9300-021:2026) has been prepared by ASD-STAN.
After enquiries and votes carried out in accordance with the rules of this Association, this document has
received the approval of the National Associations and the Official Services of the member countries of
ASD-STAN, prior to its presentation to CEN.
This document is currently submitted to the CEN Enquiry.
Introduction
This document was prepared jointly by AIA, ASD-STAN, PDES, Inc., and the prostep ivip association.
The prostep ivip association is an international non-profit association in Europe. For establishing
leadership in IT-based engineering it offers a moderated platform to its nearly 200 members from
leading industries, system vendors and research institutions. Its product and process data
standardization activities at European and worldwide levels are well known and accepted. The prostep
ivip association sees this document and the related parts as a milestone of product data technology.
PDES Inc. is an international non-profit association in the USA. The mission of PDES Inc. is to accelerate
the development and implementation of ISO 10303, enabling enterprise integration and PLM
interoperability for member companies. PDES Inc. gathers members from leading manufacturers,
national government agencies, PLM vendors and research organizations. PDES Inc. supports this
document as an industry resource to sustain the interoperability of digital product information,
ensuring and maintaining authentic longevity throughout their product lifecycle.
The standards will be published under two different standards organizations using different prefixes.
ASD-STAN will publish the standard under the European Standard (EN) number EN 9300-021. AIA will
publish the standard under the National Aerospace Standard (NAS) number NAS 9300-021. The content
in the EN 9300 and NAS9300 documents will be the same. The differences will be noted in the reference
documentation (For example, EN 9300 Geometric Dimensioning and Tolerancing will be referenced in
ISO 1101 and ISO 16792, and for NAS 9300 the same information will be referenced in ASME Y14.5 and
ASME Y 14.41). The document formatting, etc., will follow that of the respective editorial rules of ASD-
STAN and AIA.
1 Scope
This document specifies requirements for metadata of archive packages intended for the long-term
archiving of digital product information.
2 Normative references
The following documents are referred to in the text in such a way that some or all of their content
constitutes requirements of this document. For dated references, only the edition cited applies. For
undated references, the latest edition of the referenced document (including any amendments) applies.
EN 9300-005:2017, Aerospace series — LOTAR — LOng Term Archiving and Retrieval of digital technical
product documentation such as 3D, CAD and PDM data — Part 005: Authentication and Verification
EN 9300-007, Aerospace series — LOTAR — LOng Term Archiving and Retrieval of digital technical
product documentation such as 3D, CAD and PDM data — Part 007: Terms and definitions
3 Terms and definitions
For the purposes of this document, the terms and definitions given in EN 9300-007 and the following
apply.
ISO and IEC maintain terminology databases for use in standardization at the following addresses:
— ISO Online browsing platform: available at https://www.iso.org/obp
— IEC Electropedia: available at https://www.electropedia.org/
3.1
agent
actor, person, organization, or software program/system associated with events in the life of a data
object, or with rights attached to a data object
Note 1 to entry: The Dublin Core Terms (DCMI) defines an agent as ‘a resource that acts or has the power to act.’
3.2
information package
logical container composed of optional information objects
Note 1 to entry: Associated with this information package is packaging information used to delimit and identify
the information object and optional package description information used to facilitate searches for the
information object (OAIS).
3.3
right
assertion of one or more rights (such as access rights) or permissions pertaining to a data object and/or
agent
4 Principle
Since technical product documentation, such as design documents, are generated, exchanged, and used
digitally, it is essential to adapt architecture, technology, processes, data formats and rules to enable
digital retention and long-term archiving.
5 Background
5.1 Long-term archiving and retrieval (LOTAR)
Many companies are migrating their design processes from using traditional hard-copy drawings and
documents to using digital data. New processes are also essential to archive digital data and preserve
access to it in compliance with business and other requirements appropriate to this new media. Some
industries are required to archive data for the life of a product which can exceed 50 years. Over these
time periods, changes in technology impact the ability to retrieve and use product data. Organizations
which use digital product data require strategies and processes that maintain the usability of the data
over multiple generations of technology.
The cost of certain technologies varies over time. As technology ages, the cost of implementation, use,
and maintenance of that technology can provide economic pressure to move to a more current
technology. Newer technology generally provides additional business benefits, which are not reflected
in a cost and benefits comparison. At some point, regardless of cost, it can become impractical or even
impossible to use or maintain older technology due to lack of materials, equipment, tools, and support
for the technology.
Business requirements dictate the archiving of product data for long periods of time. It is generally not
feasible to maintain a single generation of technology over a period of 50 plus years. Over these time
periods, changes in technology impact the ability to retrieve, reproduce and use product data.
Organizations which use digital product data require strategies and processes that maintain the
reproducibility and usability of the data over multiple generations of technology. The retention periods
of digital data are broken into three categories as managed under a master records retention plan (see
also Figure 1):
a) Short term — 0 > 5 years. This includes data that have a short life cycle and has a small impact on
data systems used to manage this data.
b) Medium term — 6 > 10 years. This time-period includes data that have a medium life cycle and
there is minimum impact on the systems used to maintain the data (e.g. S/W service pack updates).
c) Long term — > 10 years. This time-period includes data that have a life cycle that exceeds ten years
and includes a major impact on the systems used to maintain the data (e.g. S/W version upgrades –-
Catia V4 – V5; PDM V1 – V2).
Figure 1 — Data retention periods
Development of new aerospace and defence projects increasingly demands the use of digital product
information for in-service support reasons, by the supply chain, and from the customers. The
requirements described within this document are applicable for the full aerospace product lifecycle.
This document sums up the main business requirements for long term archiving of digital product data.
In some cases, the authentic preservation of design type information is requested, which is described in
other parts of the EN 9300 series.
NOTE See also EN 9300-003.
This document describes requirements for standardized metadata for information packages and/or
archives that ensures that product data are retrievable, reproducible, and usable for the required
retention period. The metadata requirements are described in terms of the open archival information
system (OAIS) reference model (ISO 14721) that provides a conceptual framework for archive systems.
5.2 Open archival information system reference model (OAIS)
5.2.1 OAIS and LOTAR
The LOTAR standards are developed from the open archival information system (OAIS) reference
model (see ISO 14721), which provides a conceptual framework for archive systems. Using the OAIS
reference model and the LOTAR basic and common parts (see EN 9300-001, EN 9300-002,
EN 9300-003, EN 9300-005, EN 9300-007, etc.) as a process guideline, this document establishes a
minimum set of metadata for the archive in support of business and other requirements for long-term
archiving of digital product data. This document establishes the metadata requirements common to all
domains and establishes the framework for common appendices in the specific parts of the
EN 9300 series (−1xx, −2xx, etc.).
An information package is a logical container composed of optional information object(s). Associated
with this information package is packaging information that describes how the components of an
information package are logically or physically bound together and how to identify and extract the
components (OAIS). Neither OAIS nor LOTAR are prescriptive on implementation details for
information packages in a long-term archive which can range from physical, self-contained to virtual
and distributed. Within this document, metadata for archive packages requirements have been written
to reflect this range of implementation choices and where information packages (information
packages), archival information packages (AIPs), submission information packages (SIPs) and
dissemination packages (DIPs) are mentioned it is done so in the context of this range of
implementation options.
In addition to the content information, OAIS defines three main classes of information (metadata) that
should be held in an archive, related to content data (OAIS):
— preservation description information (PDI) — to support the trust in, the access to and context of
the content;
— packaging information (PI) — to either actually or logically, bind or relate the components into an
identifiable entity on specific media;
— descriptive information (DI) — to provide adequate features to allow consumers to locate
information of potential interest, analyse that information, and request desired information.
The following definitions for the three main classes of metadata are taken from the OAIS reference
model and a detailed view of the structure of an archival information package is shown in Figure 2.
5.2.2 Preservation description information (OAIS)
The PDI shall include information that is necessary to adequately preserve the particular content
information with which it is associated. It is specifically focused on describing the past and present
states of the content information, ensuring it is uniquely identifiable, and ensuring it has not been
unknowingly altered.
The following definitions are based on the categories described in OAIS.
— Reference information identifies, and if necessary, describes, one or more mechanisms used to
provide assigned identifiers for the content information. It also provides those identifiers that allow
outside systems to refer, unambiguously, to this particular content information. Examples of these
systems include taxonomic systems, reference systems and registration systems. In the OAIS
Reference model most if not all this information is replicated in package descriptions, which enable
consumers to access content information of interest.
— Context information documents the relationships of the content information to its environment.
This includes why the content information was created and how it relates to other content
information objects existing elsewhere.
— Provenance information documents the history of the content information. This tells the origin or
source of the content information, any changes that can have taken place since it was originated,
and who has had custody of it since it was originated, providing an audit trail for the content
information. This gives future users some assurance as to the likely reliability of the content
information as it contributes to evidence supporting Authenticity. Provenance can be viewed as a
special type of context information.
— Fixity information provides the data integrity checks used to ensure that the particular content
information object has not been altered in an undocumented manner. Fixity information includes
special encoding and error detection schemes that are specific to instances of content objects. Fixity
information does not include the integrity preserving mechanisms provided by the OAIS underlying
services, error protection supplied by the media and device drivers used by Archival Storage. The
Fixity information can specify minimum quality of service requirements for these mechanisms.
— Access rights information identifies the access restrictions pertaining to the content information,
including the legal framework, licensing terms, and access control. It contains the access and
distribution conditions stated within the submission agreement, related to both preservation (by
the OAIS) and final usage (by the consumer). It also includes the specifications for the application of
rights enforcement measures.
These classifications provide a minimum set of PDI; they do not specify a data structure.
5.2.3 Packaging information (OAIS)
Packaging information is that information which, either actually or logically, binds or relates the
components of the package into an identifiable entity on specific media. For example, if the content
information and PDI are identified as being the content of specific files in a container file, then the
packaging information can include the name of the container file and the fact that it is a container file
including details of any specific encoding. The packaging information shall be preserved by an OAIS as
long as the AIP exists; if the AIP is repackaged then the packaging information is changed and the new
packaging information shall be maintained with that repackaged AIP. These structures are most likely
to be used as packaging information. Packaging information is not preserved by all digital migrations.
The OAIS should avoid holding PDI or content information only in the naming conventions of directory
or file name structures because any information saved in file names or directory structures can be lost
when the packaging information is altered. The subject of packaging information is an important
consideration to the migration of information within an OAIS.
5.2.4 Descriptive information (OAIS)
The information objects described previously in Clause 5 provide the information necessary to enable
the long-term preservation function of the archive. In addition to preserving information, the OAIS
should provide adequate features to allow consumers to locate information of potential interest,
analyse that information, and order desired information (see Figure 2). This is accomplished through a
specialization of the information object called descriptive information, which contains the data that
serves as the input to documents or applications called access aids. The descriptive information is
generally derived from the content information and PDI. The descriptive information can be viewed as
an index to enable efficient access to the associated information package via associated access aids.
Access aids are documents or applications that can be used to locate, analyse, retrieve, or order
information from the OAIS.
Figure 2 — Archival information package (detailed view) [OAIS]
5.3 LOTAR specific information
In addition to the metadata requirements of OAIS, there are specific requirements for LOTAR that are
outlined in EN 9300-002, EN 9300-003 and EN 9300-005 as general information requirements and
within specific parts of the EN 9300 series as necessary for a particular content type. General
requirements are referenced and repeated here if they translate into requirements for metadata
(descriptive, packaging or preservation) rather than supporting data or documentation and domain
requirements if they are present across more than one part of the EN 9300 series. Specific metadata
requirements for comprehension and re-use of domain product data (for example representation
information or domain specific content metadata) are further defined within the parts of the EN 9300
series themselves. Such domain specific content metadata functionally acts as content information and
can be mapped to or extend archival information package metadata. Examples of standards for such
metadata include ISO 243 — MoSSEC, a standard is designed to provide a capability to share modelling
and simulation information in a collaborative systems engineering context.
5.4 Metadata schema and encoding
LOTAR is not prescriptive in the choice of schema and encoding methods for metadata, but the use of
recognized standards is encouraged to support a goal of interoperability in submission to,
dissemination from and consolidation of archives. Metadata schema are available for the metadata
required by OAIS detailed above, for example in the Library of Congress standards METS (Metadata
2 3
Encoding and Transmission Standard), XFDU (XML Formatted Data Unit) and PREMIS (Preservation

Library of Congress at: https://www.loc.gov/standards/mets/
CCSDS at: https://ccsds.org/wp-content/uploads/gravity_forms/5-
448e85c647331d9cbaf66c096458bdd5/2025/01//661x0b1.pdf
Library of Congress at: https://www.loc.gov/standards/premis/
Management Implementation Strategies) with schema available for XML. The OAIS requirements for
PDI and PI do not map simply to PREMIS and METS respectively but implementation of requirements
for both can be achieved using these standards. XFDU uses OAIS terminology and there is a clear
mapping to OAIS information requirements and as with METS fulfils the need for PI but references
external resources for other information such as DI, and PDI.
NOTE For further information on Premis, METS, XFDU and example metadata, see Annexes A, B, C and D.
Many standards and encodings (e.g. XML, RDF) exist for DI such as: Extended Archival Description
4 5 6
Dublin Core Metadata Initiative (DCMI), General International Standard Archival Description
(EAD)
(ISAD(G)), Metadata Object Description Schema (MODS) etc and selection of a suitable metadata
schema or a decision to create a local well-formed schema depends on the use-cases of the archive.
General and domain specific metadata which is required to be visible within an information package
independently of the content information data (such as ISO 10303, STEP files) shall to be mapped to
one of the schema detailed above, encoded as extensions to these schema or to a local schema defined
by the archive.
Parts of the EN 9300 series can specify LOTAR and domain specific metadata as described in 5.3 above
and can prescribe use of schema such as MoSSEC (ISO 10303-243). This document does not restrict the
use of such engineering context metadata or alter the requirements of LOTAR domain-specific parts of
the EN 9300 series in any way.
5.5 Controlled vocabularies
To aid machine processing and to avoid ambiguity, the use of controlled vocabularies for metadata
elements is recommended. Metadata standard data dictionaries or profiles can identify where use of
controlled vocabularies is recommended as best practice and corresponding standardized vocabularies
can be available such as those available at the Library of Congress Linked Data Service . Standardized
vocabularies can be extended with local terms and if this is done, then as best practice vocabulary files
should be referenced from within information packages.
Parts of the EN 9300 series can specify use of defined vocabularies (external or within the standard) for
metadata elements within domain-specific metadata, within information-package metadata or through
mapping, both.
5.6 Metadata-only information packages
In some cases, information packages can be required that contain only metadata and no content
information. Such cases could be for example the high-level description of a design or project, definition
of product structure (product, assembly, sub-assembly, part, component etc) and system architecture.
Any archival or information package specifications implemented should allow for metadata only
packages.
6 Requirements
6.1 General requirements
The metadata of archival packages shall be in accordance with Table 1.

Library of Congress at: https://www.loc.gov/ead/
DublinCore at: https://www.dublincore.org/
International Council on Archives at: https://www.ica.org/resource/isadg-general-international-standard-
archival-description-second-edition/
Library of Congress at: https://www.loc.gov/standards/mods/
Library of Congress at: https://id.loc.gov/
Table 1 — Requirements of category “General requirements”
No. Requirement
Metadata schema: Wherever possible standardized metadata shall be used and where
GR1 required extended profiles or schema shall be included or referenced within each
information package.
Metadata encoding: Metadata shall be encoded by standardized, recognized protocols
GR2
such as: XML or RDF/XML.
Controlled vocabularies: Controlled vocabularies shall be used for certain (identified)
metadata elements using standardized, extended or local vocabularies. If extended or local
GR3
vocabularies are used, they shall be included or referenced within each information
package.
Metadata-only packages: Whatever information package implementation is used, it shall
allow for metadata only instances for the high-level description of collections of content
GR4
such as designs and the structure of such content via inter IP and object relationships (e.g.
product design structures).
Metadata classes: The archive shall contain metadata defined by OAIS to describe
information packages, namely: preservation description information (PDI), packaging
GR5
information (PI), including relevant and necessary LOTAR specific metadata and should
include descriptive information (DI) in order to aid searches and interoperability.
6.2 Detailed metadata requirements for application of the OAIS reference model to
LOTAR use cases
6.2.1 General
6.2 defines the metadata requirements applicable to the long-term archiving and retrieval of digital
product data for conformity to OAIS. These requirements are categorized into the main OAIS classes for
information that should be included in an information package beyond the content data itself.
Where possible examples are given of common standards used for encoding such metadata within
archival packages, for example: Metadata Encoding and Transmission Standard (METS), Preservation
Metadata: Implementation Strategies (PREMIS) and Dublin Core Metadata Initiative (DCMI) terms.
According to OAIS: “It is necessary to distinguish between an information package that is preserved by
an OAIS and the information packages that are submitted to, or disseminated from, an OAIS.” Namely
the archival information package (AIP), submission information package (SIP) and dissemination
information package (DIP).
Specific requirement terms (shall, may, should, can) are used in this document where necessary for
package variants and otherwise are stated for generic information packages. In general:
a) metadata required for content to be retained in the OAIS is submitted in a SIP;
b) metadata in an AIP is based on that submitted in the SIP plus preservation description information
(PDI) generated within the OAIS;
c) metadata in a DIP is as defined between the archive and consumer.
6.2.2 Preservation description information
Preservation description information of archival packages shall be in accordance with Table 2.
Table 2 — Requirements of category “Preservation description information”
No. Requirement
PD1 Fixity: Each digital object in an information package shall have fixity information such as
to be protected against unauthorized changes while archived. The fixity information shall
Ref parts
take the form of a checksum and the algorithm used to generate it, (e.g. PREMIS:
002.S13,
@messageDigest, @messageDigestAlgorithm; METS: @CHECKSUM, @CHECKSUMTYPE;
003.5.2.1
XFDU(xsd): @checksum, @checksumName).
PD2 File format: Each digital object in an information package shall have information about
its format. Information about file formats, for example MIME types (together with
Ref part
information on creating software and software version, see PD5) enables analysis and
002.DM10
identification of format obsolescence risk and is used in the preservation planning
process, (e.g. PREMIS: @formatName; METS: @MIMETYPE, XFDU(xsd) @mimeType).
PD3 Created date: Each digital object in an information package shall have information about
the date it was created by the creating software, (e.g. PREMIS:
@dateCreatedByApplication; METS: @CREATED).
PD4 Size: Each digital object (File,bitstream) in an information package shall have information
about the size of the file recorded as an integer, in bytes, (e.g. PREMIS: @size; METS:
@size; XFDU @size).
PD5 Creating software: Each digital object in an information package shall have sufficient
metadata about the software used to create it, including for example the version number
Ref part
and information standard used to create the content (e.g. the ISO 10303 series). In the
002.DM30,
case of derived content information (e.g. STEP files for product models,), the creating
100.C11
software is the software used for the transformation, (e.g. PREMIS: /creatingApplication
with extended semantic components defined locally).
PD6 Transformation events: Each derivative presentation of a content information in an
information package shall contain metadata related to its transformation event
Ref part
(normalization, migration), including event identifier, event type, event date time, links to
002:DM5
any corresponding agent (transforming software) and corresponding event reports, (e.g.
PREMIS: /event) using an event type value taken from a standard , extended or local
vocabulary.
PD7 Transforming agents: For each transformation event there shall be corresponding agent
information (transforming software and/or user), including agent identifier, agent name,
Ref part 002:
agent type, agent version and links to any processes (such as process IDs), (e.g. PREMIS:
DM5
/agent).
PD8 Relationships between digital objects: Information packages should include
information related to relationships between digital objects to enable their maintenance
Ref part
during operations such as migration, (e.g. PREMIS /relationship) using relationship type
002.DM14
and sub-type values taken from a standard , extended or local vocabulary.
PD9 Provenance: The archive shall have the ability to determine what application and version
was used to create or revise an archived product data object and a link to the report (or
Ref part
the reports) on the conversion (e.g. PREMIS /creatingApplication, /agent)
002.DM31,
100.PI1
Library of Congress at: https://id.loc.gov/vocabulary/preservation/EventType.html
Library of Congress at: https://id.loc.gov/vocabulary/preservation/relationshipType.html and
https://id.loc.gov/vocabulary/preservation/relationshipSubType.html
No. Requirement
PD10 Preservation audit trail: AIPs shall include records of events related to their archiving
and preservation, (e.g. PREMIS /event) using an event type value taken from a standard,
Ref part
extended or local vocabulary.
002.S15
Planned retention and disposal schedules: Each AIP shall include information
PD11
regarding the planned retention period for data to be held in the archive with at
Ref part
minimum: a marker that deletion is possible, a date for the start of the retention period
002.AC5
and a date for disposal of the data.
PD12 Disposal: If product data are deleted then AIPs shall include records of events related to
its disposal (e.g. PREMIS /event) using an event type value taken from a standard,
Ref part
extended or local vocabulary and including the name of the authorizing agent and reasons
002.AC5
for deletion.
002.S18
PD13 Quality control criteria: Each AIP shall contain information that links validation and
verification events to the relevant validation rules data and data quality rules (verification
Ref part
rules data) used in the procedures. (e.g. PREMIS /linkingObjectIdentifier).
002.GR5
Quality control events: If qualification levels above 0 are required by the relevant data
PD14
domain specific part of LOTAR, then each AIP shall contain information recording
Ref part
validation and verification events on content information, including validation or
002.DP1,
verification level, event identifier, date time, event type and event outcome which
002.DP2
distinguishes between “passed”, “failed” and “not performed”. (e.g. PREMIS /event).
PD15 Authentication reports: Each AIP shall include information linking content information
with corresponding validation and verification properties reports or data. (e.g. PREMIS
Ref part
/linkingObjectIdentifier). The format of reports can be, for example to ISO 10303-59
002.DP1,
“Quality of product shape data”.
002.DP2,
100.RM2,
100.PI1,
100.F11,
100.PD12
Authentication agents: Each AIP shall include information linking validation and
PD16 verification events with software agents that have conducted and approved validation and
verification procedures, including software version (e.g. PREMIS /linkingAgentIdentifier).
PD17 Approval prior to release: Each AIP shall include information on the identification of the
approver(s) of submissions and evidence documenting the approval such as an electronic
Ref part
signature. Electronic signatures should include the approver name and date of approval.
002.IN1,
(e.g. PREMIS /signatureInformation).
005.3.1.3
005.7
Digital signatures (engineering signatures): If digital signatures in accordance with
PD18
EN 9300-005:2017 3.1.4 are used for documenting evidence of approval, then information
Ref part
packages shall contain information for each signature, including: owner name, public key,
information about the algorithm used to generate the public key, start and end time of the
005.3.1.4
certificate, identification number for certificate, name of certificate office and information
005.7.1.1
on restrictions about the use of the key. (e.g. PREMIS /signatureInformation).
No. Requirement
Digital signature supporting documentation: Each information package containing
PD19
digital signatures shall include information that links those digital signatures with
supporting documentation such as digital signature procedures. (e.g. PREMIS

/signatureInformation Extension).
6.2.3 Packaging information
Packaging information of archival packages shall be in accordance with Table 3.
Table 3— Requirements of category “Packaging information”
No. Requirement
P1 Package identifier: Each AIP shall have an identifier that is unique within the archive, for
example, a UUID which should be combined with information such as: package name, part
Ref part
number and version number. (e.g. METS mets/@OBJID; XFDU packageHeader/@ID)
002.DM13
P2 OAIS package type information: Where physical information packages exist in a process,
each OAIS package type shall be identifiable, or each package shall declare its package
type. (SIP, AIP, DIP). (e.g. METS mets/metHdr; XFDU
informationPackageMapType/@packageType)
P3 Content structure: Each information package shall contain information describing (at
minimum) the physical or logical structure of the content information and the
Ref part
relationships between data objects such that the required structure of the data are known
002.DM14
regardless of a folder structure being in place and is maintained during operations such as
data format migration. Appropriate metadata structures for given data types (database,
graph, file structures) shall be used in each case. (e.g. METS mets/structMap; XFDU
informationPackageMap).
P4 Content type: Each information package shall contain information that identifies the
content data type as defined in LOTAR domain-specific parts of the EN 9300 series,
Ref part
together with sufficient contextual information or attributes as specified in the relevant
002.DM10
domain-specific part of the EN 9300 series, for example with sufficient specificity to
determine retention periods based on business or other applicable requirements, (e.g.
METS mets/@TYPE).
P5 Package creating software: If physical (i.e stored as a container or file structure on
storage media) information packages exist in a process then each information package
shall contain information that identifies the software used to create the package (e,g,
METS metsHdr/Agent/@CREATOR).
P6 Submission agreement: SIPs shall contain information that reference the submission
agreement between producer and archive (e.g. METS metsHdr/altRecordID)
Ref part
002.AD1
P7 Created date: Each information package shall include a reference to a date of creation
(e.g. METS metsHdr/@CREATEDATE).
P8 Modified date: Each information package shall include a reference to the last
modification date (e.g. METS metsHdr/@LASTMODDATE).
No. Requirement
P9 Producer: Each SIP shall include information about the producer organization of the
package. This information can be accompanied by a unique identifier (e.g. CAGE code ,
METS metsHdr/Agent/@CREATOR).
P10 Digital object storage location: If digital objects are not stored within an information
package, for example for very large data volumes, then information related to the storage
location shall be included in the package (e.g. PREMIS 1.7).
P11 AIP versions: OAIS considers an AIP version to be “An AIP resulting from changing the
content information or preservation description information of a source AIP, in order to
preserve the information. An AIP Version is considered to be the result of a data format
migration. (OAIS 2024, 1–9)” If AIP versions exist, then the version of an AIP shall be
clearly identified, with version control managed by an applicable archive quality
management system (QMS) standard (e.g. AS 9100, EN 9100).
P12 Rights: Each archive shall contain information related to the management of access rights
such as copyright, export control, license, data privacy, and national/governmental
Ref part
security protection information which should be included in each information package
002.LD4,
and may be associated to the information package, representations, folders, files or
002.S17,
bitstreams (e.g. PREMIS rightsStatement, DCMI Metadata Terms rights, accessRights,
002.
...