Content Information Type Specification for 3D Product Model (CITS 3D PM)

Preface

I. Aim of the Specification

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

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

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

Overview of the E-ARK Specifications

Common Specification for Information Packages (E-ARK CSIP)

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

• Establish a common understanding of the requirements which need to be met to achieve interoperability of Information Packages.
• Establish a common base for the development of more specific Information Package definitions and tools within the digital preservation community.
• Propose the details of an XML-based implementation of the requirements using, to the largest possible extent, standards which are widely used in international digital preservation.

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

Specification for Submission Information Packages (E-ARK SIP)

The main aims of this specification are to:

• Define a general structure for a Submission Information Package format suitable for a wide variety of archival scenarios, such as document and image collections, databases or geospatial data.
• Enhance interoperability between Producers and Archives.
• Recommend best practices regarding the structure, content and metadata of Submission Information Packages.

Specification for Archival Information Packages (E-ARK AIP)

The main aims of this specification are to:

• Define a generic structure of the AIP format suitable for a wide variety of data types, such as document and image collections, archival records, databases or geospatial data.
• Recommend a set of metadata related to the structural and the preservation aspects of the AIP as implemented by the eArchiving Reference Implementation (earkweb).
• Ensure the format is suitable to store large quantities of data.

Specification for Dissemination Information Packages (E-ARK DIP)

The main aims of this specification are to:

• Define a generic structure of the DIP format suitable for a wide variety of archival records, such as document and image collections, databases or geographical data.
• Recommend a set of metadata related to the structural and access aspects of the DIP.

Content Information Type Specifications (E-ARK CITS)

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

• Define, in technical terms, how data and metadata must be formatted and placed within a CSIP Information Package to achieve interoperability in exchanging specific Content Information.

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

II. Organisational Support

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

III. Authors & Revision History

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

CITS-3DPM

Content Information Type Specification for 3D Product Model (CITS 3D PM)

Version: 1.0.0

Date: 2024-12-13

1. Introduction
1.1. Purpose
1.2. Scope
1.3. Layered Data Model
2. Specification
2.1. CITS 3D PM Requirements Structure
2.2. Principles
2.2.1. Principle - support for LOTAR conformance
2.2.2. Principle - use of PREMIS
2.3. Use Cases for Archiving of Product Model Data
3. Implementation
3.1. Package Structure
3.2. Metadata and Supporting Information
3.2.1. Descriptive Metadata
3.2.2. Authentication
3.2.2.1. Validation
3.2.2.2. Verification
3.2.2.3. Digital Signatures
3.2.3. Preservation Metadata
3.2.4. Rights Metadata
3.2.5. METS
3.2.5.1. Use of METS in CITS 3D PM
3.2.5.2. Root METS File
3.2.5.3. Root METS root element
3.2.5.4. Root METS header element (element metsHdr)
3.2.5.5. Root METS descriptive metadata section (element dmdSec)
3.2.5.6. Root METS administrative metadata section (element amdSec)
3.2.5.7. Root METS file metadata section (element fileSec)
3.2.5.8. Root METS structural map (element structMap)
3.2.5.9. Representation METS Files
3.2.5.10. Representation METS root element
3.2.5.11. Representation METS header element (element metsHdr)
3.2.5.12. Representation METS descriptive metadata section (element dmdSec)
3.2.5.13. Representation METS administrative metadata section (element amdSec)
3.2.5.14. Representation METS file metadata section (element fileSec)
3.2.5.15. Representation METS structural map (element structMap)
3.2.6. PREMIS
3.2.6.1. Use of PREMIS in CITS 3D PM
3.2.6.2. Attribute values and controlled vocabularies
3.2.6.3. Use of PREMIS at package level
3.2.6.4. Preservation information
3.2.6.5. Rights Information
3.2.6.6. Use of PREMIS at Representation level
3.2.6.7. Preservation information
3.2.6.8. Validation and Verification information
3.2.6.9. Digital Signatures for Product Information Models
4. Glossary
5. Appendices
5.1. Appendix A: CITS3D Information Package METS Examples
5.1.1. Example 1: Example of a whole METS document describing a submission information package following CITS 3D PM (cits-3dpm_v1_0).
5.1.2. Example 2: Example of a whole METS document describing a representation following CITS 3DPM (cits3dpm_v1_0).
5.2. Appendix B: External Schema
5.2.1. E-ARK SIP METS Extension
5.2.2. E-ARK CSIP METS Extension
5.3. Appendix C: External Vocabularies
5.3.1. Content information type specification
5.3.2. Content category and folder definitions in 3DPM
5.4. Appendix E: E-ARK CITS3D Metadata Requirements
5.4.1. E-ARK 3D PM root METS Profile 1.0 Requirements
5.4.2. E-ARK 3DPM representation METS Profile 1.0 Requirements

1. Introduction

1.1. Purpose

The purpose of this document is to describe the Content Information Type Specification (CITS) for 3D Product Models (3DPM). The specification is designed to be used for the transfer to archives as well as for records exchange between different 3D Product Information Model systems. The specification is supported by METS profiles for the Root and Representation METS files and accompanying Guideline document.

1.2. Scope

Use of 3D data is widespread across many domains, with a plethora of applications and data formats. This 3D Product Model content specification limits its scope to the area of 3D digital product data such as computer aided design (CAD) or product data model (PDM) data. There is an international standard for the long term archiving of this class of data in the LOTAR “Long Term Archiving and Retrieval of digital technical product information”¹, which is published as the EN/NAS 9300 series. However although LOTAR extensively references and extends ISO 14721 the “Open reference model for Archiving Information System”, (OAIS) it does not extend into areas detailed in the E-ARK common specification for information packages (CSIP). LOTAR also references and builds on ISO 10303, the Standard for the Exchange of Product model data (STEP) and so with this E-ARK 3DPM CITS we have the opportunity to add to a layered standards model as seen in Layered Data Model.

1.3. Layered Data Model

This section introduces the role of the CITS 3DPM and its dependencies on the basic structures of the Information Package.

This specification is created based on the requirements of the Common Specification for Information Packages (CSIP), the specification for Submission Information Packages (E-ARK SIP) and the specification for Archival Information Packages (E-ARK AIP). To fully understand its requirements, we highly recommend that users review the requirements and the terminology of the source documents, before using this specification.

The data model structure is based on a layered approach for information package definitions Figure 2). The Common Specification for Information Packages (CSIP) forms the outermost layer. The general SIP, AIP and DIP specifications add respectively, submission, archiving and dissemination information to the CSIP specification. The third layer of the model represents specific content information type specifications, such as this 3DPM specification. Additional layers for business-specific specifications and local variant implementations of any specification can be added to suit the needs of the organisation.

Figure 2: Data Model Structure

Every level in the data model structure inherits metadata entities and elements from the higher levels. In order to increase adoption, a flexible schema has been developed. This will allow for extension points where the schema in each layer can be extended to accommodate additional information on the next specific layer until, finally, the local implementation can add specific entities or metadata elements to satisfy specific local needs. Extension points can be implemented by:

• Embedding foreign extension schemas (in the same way as supported by METS and PREMIS These both support increasing the granularity of existing metadata elements by using more detailed data structures as well as adding new types of metadata.
• Substituting metadata schemas for standards more appropriate for the local implementation.

The structure allows the addition of more detailed requirements for metadata entities, for example, by:

• Increasing the granularity of metadata elements by using more detailed data structures, or
• Adding local controlled vocabularies.

For consistency, design principles are reused between layers as much as possible.

The CITS 3DPM builds on the existing LOTAR standard for “long-term archiving of digital technical product information” which in itself builds on the standard for an Open Archival Information System (OAIS, ISO 14721) and the Standard for the Exchange of Product Model Data (STEP, ISO 1303). So for CITS 3DPM in particular we have a layered data model as seen in Figure 3. Note however that compliance with LOTAR or STEP is not mandatory within 3D PM but is recommended. Individual organisational archiving strategies for 3D Product Model data may or may not include STEP representations of model data and may include all or some of the elements of the LOTAR standard. The 3DPM CITS provides for accomodation of these standards but makes compliance an organisational choice.

Figure 3: CITS 3DPM Layered Data Model.

2. Specification

2.1. CITS 3D PM Requirements Structure

The Content Information Type Specification for 3D Product Model data aims to define the necessary elements required to preserve the accessibility and authenticity of 3D Product Model data over time and across changing technical environments. The specification builds on the international standard for long-term archiving of Product Model data (LOTAR) and facilitates conformance to the standard within an E-ARK packaging framework. In order to achieve this the specification elevates the level (and adjusts the cardinality) of some of the requirements set out in the Common Specification (CSIP) and package specifications (namely SIP and AIP) and adds new requirements for the package structure, descriptive metadata, preservation metadata and accompanying METS files. It also introduces new requirements for authentication. The specification sets out general principles that underpin the specific requirements and further context for the requirements and principles can be found in the accompanying guideline to this document.

2.2. Principles

2.2.1. Principle - support for LOTAR conformance

The LOTAR “Long Term Archiving of digital technical product information” series is an international standard for the long term archiving of Product Model data (such as computer aided design CAD or product data model PDM data). LOTAR extensively references and extends ISO 14721 the “reference model for an Open Archival Information System”, (OAIS) but does not extend into areas detailed in the E-ARK common specification for information packages (CSIP). LOTAR also references and builds on ISO 10303, the Standard for the Exchange of Product Model data (STEP). This eArchiving 3D Product Model CITS creates a layered model for creating archival packages for Product Models that allows conformance to LOTAR and STEP whilst maintaining conformance with the CSIP and with the individual eArchiving package specifications (SIP, AIP and DIP). Specifically:

• no mandatory requirements in this specification should conflict with (mandatory) requirements of LOTAR;
• specific (mandatory) requirements of LOTAR with regard to essential data or metadata elements in Information Packages ate translated as optional requirements in the 3D PM CITS;
• the scope of the E-ARK specifications are not altered to encompass areas covered by LOTAR but not covered by E-ARK, for example process requirements and management procedures.

A conformant E-ARK 3DPM Information Package will not imply conformance or validation against LOTAR, but an archive will be able to use use the E-ARK 3DPM CITS together with the other E-ARK package specifications to produce Information Packages that can support LOTAR compliance.

2.2.2. Principle - use of PREMIS

PREMIS can be usefully used to meet the requirements in LOTAR for the recording of Validation and Verification events, Digital Signatures, Rights and Digital Provenance Information). Neither CSIP or 3DPM CITS makes the use of PREMIS mandatory but guidance as to how it can be used to provide LOTAR conformance is provided by this CITS.

From the CSIP and PREMIS CITS:

• PREMIS should be used to record detailed technical metadata;
• Technical information should be included in PREMIS metadata by using extension schemas;
• Information about agents carrying out preservation actions must be recorded in the PREMIS metadata (this is because METS agents describe agents relevant for generic IP level events, such as the creation or submission of the package, not the preservation of the data);
• Event descriptions should be included in PREMIS metadata. Use of the official PREMIS event vocabulary (https://id.loc.gov/vocabulary/preservation/eventType.html) is recommended;
• Detailed rights information should be included in PREMIS. High-level rights information in METS indicates restrictions. Detailed, object-specific rights information will be included in the PREMIS metadata;
• File format information for all files should be included as Persistent Unique Identifier (PUID) values in the appropriate PREMIS semantic units.

Technical and preservation metadata in the context of the 3DPM CITS can include:

• Creating agent;
• Reference to the content information standard (e.g. STEP);
• Reference to the LOTAR standard part for the content information type;
• Information about the generating system.

Event descriptions in the context of the 3DPM CITS can include:

• Creation events;
• Conversion or change events;
• Digital Signature events;
• Verification events and results;
• Validation events and results.

Detailed technical metadata in the context of the 3DPM CITS can include:

• File format, characterisation, checksums;
• Detailed part number, version, product model and issue information;
• Relationships for the digital object (is part of, contains parts).

Rights information in the context of 3DPM CITS can include:

• Access rights;
• Export controls;
• License restrictions;
• Security classification;
• Personal identifiable information restrictions;
• Company specific classifications.

Use of PREMIS must conform to the requirements of the CAPM.

2.3. Use Cases for Archiving of Product Model Data

Further detail of the use cases for long-term archiving of data in general and the rationales given in LOTAR specifically for Product Model data are given in the accompanying guideline. In summary, the use cases for archiving of Product Model data are determined to be:

• To enable the submission of 3D Product Model data from engineering departments in an organisation to a centralised or distributed archive, in a common format;
• To store archival 3D Product Model data in a manner that will allow consolidation of archives intra-organisationially or with sources added through mergers or acquisitions;
• To allow dissemination of Product Model archival data within the organisation or to external regulatory bodies preserving both the integrity of the data objects and the information packages.

3. Implementation

3.1. Package Structure

The CITS 3D Product Model information structure inherits its package structure from the E-ARK Common Specification for Information Packages and is shown in Figure 4. It can be seen that additional folders have been added for authentication documentation at root and representation level but otherwise the structure is identical.

Figure 4: Example Information Package Folder Structure

A 3D Product Model Information package can consist of one to many representations comprising Product Information Models of the same product. It is likely for example that a Product Model archival package will at minimum contain a representation in Native Format and one in Standardised Open Format (e.g. STEP). As described in LOTAR, long-term usability of proprietary Native Format data is a risk and conversely open derivations such as STEP are at risk of losing some properties from the original.

LOTAR requires the inclusion of information to support Validation and Verification of the data and representations, including:

• Validation Properties Rules Data
• Validation Properties
• Validation reports
• Data Quality Rules (Verification)
• Verification reports

Validation and Verification rules information relate to the package and their outputs (properties, reports) relate to each individual representation. Within CITS 3DPM, a sub-folder named Authentication is included at root and representation levels within the Documentation folders to store the respective information related to Validation and Verification.

It is strongly recommended that as much documentation as possible related to the production, context, provenance and terms of use of the Product Model is included in the information package such as for example: images, licence terms, project overviews, model creation information. 3DPM CITS recommends the inclusion of such information related to the Product Model in a documentation/other sub-folder and related to specific Product Information Models in representation/documentation/other sub-folders. LOTAR also requires the inclusion of a Submission Agreement in the information package that references the location of the references for Validation Properties Rules Data and Data Quality Rules (Verification) within Descriptive Information (metadata). The Submission Agreement should be located in the documentation/other sub-folder.

Specific requirements for the CITS 3D Product Model folder structure are as follows:

3DPM1: the package MUST have at least one representation in the Representations folder

3DPM2: the Documentation folder at package level and representation level SHOULD include a sub-folder named Authentication. This is an extension of CSIPSTR16.

3DPM3: the Documentation folder at package and representation level SHOULD include a sub-folder named Other. This is an extension of CSIPSTR16.

3.2. Metadata and Supporting Information

3.2.1. Descriptive Metadata

According to LOTAR: “The producer creates a set of Descriptive Information (DI), which includes archive metadata meeting the archives requirements (according to ISO 14721:2003 – OAIS).”

Neither CSIP or LOTAR prescribe specific schemas for descriptive information and so this is left to be determined by the user organisation. According to CSIP this should be according to a standardised schema such as for example EAD, Dublin Core, MODS or a locally defined schema that must be included in the package.

It is assumed that it would also be desirable that Validation information, i.e. Validation Properties rules data is also referenced. This specification does not specify where this information should be located in any respective standardised descriptive metadata schema and this will be an organisational decision. LOTAR does however prescribe that the location of information references in SIPs be stated in a Submission Agreement. This specification also recommends that Verification and Validation supporting documentation as described below is included in the package and that Verification and Validation events are recorded within PREMIS.

3.2.2. Authentication

3.2.2.1. Validation

LOTAR requires that data selected for archiving undergoes Validation checks involving the generation of Validation properties from the data and checks that the data representations meet with the recommended data quality criteria (Validation Properties Rules Data). Good archival practice dictates that we should not only include the results of those Validation checks but that Validation Properties Rules Data and Validation Properties should be included in the package. This specification also recommends that Validation events and results are recorded within preservation metadata (PREMIS).

3DPM4: the package Authentication sub-folder SHOULD contain Validation Rules Data files or documents.

3DPM5: each representation Authentication sub-folder SHOULD contain Validation results report files or documents.

3.2.2.2. Verification

LOTAR requires that each representation of the Product Model be verified using Data Quality Rules and that these documents are referenced from Descriptive Information (DI). The data Verification process is supported by the following documents:

• Data Quality Rules (Verification)
• Data Verification results report

Good archival practice states that we should not only include the reference to Verification results in Descriptive Metadata but should include the Data Quality Rules and the Verification reports within each Representation. This specification also recommends that Verification events and results are recorded with Preservation Metadata (PREMIS).

3DPM6: the Information Package SHOULD contain Data Quality Rules files or documents within the /documentation/authentication sub-folder.

3DPM7: each Representation SHOULD contain files or documents containing Verification results reports in the representation/documentation/authentication sub-folder.

This specification does not detail the content or format of Validation and Verification information which may be specified within other standards such as LOTAR.

3.2.2.3. Digital Signatures

A Digital Signature is a defined method to sign an object in electronic environments; it provides means to authenticate the signatory and the signed object in an unambiguous and safe way by attaching to or logically associating data in digital form to other digital objects. In LOTAR it is defined by an encrypted hash code with additional information such as time of creation and owner of the signature.

LOTAR requires that a Digital Signature is provided on Ingest, i.e. production of AIPs from SIPs. Note that LOTAR also requires that signatures are ‘created using means that the signatory can maintain’, which may exclude the use of 3rd party certificate and time stamp providers.

3DPM8: Information Packages MAY contain Digital Signatures associated with Product Model Representations that are encoded within a Representation PREMIS file.

This specification recommends that any Digital Signature information be recorded within PREMIS see Specification. PREMIS also requires that the operations to be performed for validating a Digital Signature are known. This can be by means of a canonicalized method, or if by a local method either documentation or a persistent link to archived documentation or a resource must be provided.

3DPM9: If Digital Signatures are provided then documentation MUST be included in the documentation/authentication folder or a persistent link provided to a resource.

3.2.3. Preservation Metadata

LOTAR requires that Information Packages include Preservation Description Information (PDI) which in turn comprises information related to:

• Provenance
• Reference
• Fixity
• Context

According to the Common Specification for Presevation Metadata (CSPM): “When using Preservation Metadata together with the Common Specification for Information Packages (CSIP) (http://earkcsip.dilcis.eu), it is recommended that these are included in the information package in PREMIS format. Although this is not mandatory, all tools claiming to be able to validate CSIP compliant Information Packages may also validate PREMIS metadata once it exists within the package. The two high-level requirements for the use of PREMIS in Common Specification IPs are that:

• All preservation metadata is created according to official PREMIS guidelines;
• All PREMIS metadata is referenced from the amdSec/digiprovMD element of the appropriate METS file.

It is recommended that users review the Common Specification for Preservation Metadata.

3DPM recommends the inclusion of PREMIS files at Representation level to include Authentication events, Provenance and Digital Signature information for Product Information Models and Content Objects.

3DPM10: there SHOULD be a PREMIS file produced according to the CSPM and the requirements of this CITS in the representation/metadata/preservation folder of each Representation of the Information Package.

3.2.4. Rights Metadata

From the principle above detailed Rights information should be recorded within PREMIS and as such a PREMIS file should be included at package level to contain this.

3DPM11: there SHOULD be a PREMIS file produced according to the CSPM and the requirements of this CITS in the metadata/preservation folder of the Information Package containing Rights information.

3.2.5. METS

3.2.5.1. Use of METS in CITS 3D PM

CSIP specifies that METS files be located at the root of the package folder structure (Root METS) and optionally in each of the Representations within its respective root folder (Representation METS). The CITS 3D PM has a requirement to contain at least one Representation and so will contain at minimum a root METS and a Representation METS file.

3.2.5.2. Root METS File

The root METS file must adhere to the requirements of the CSIP and Information Package specifications. In addition, there are specific requirements for CITS 3D PM and in some cases, the level of the CSIP or package requirements have been increased (but never decreased).

3.2.5.3. Root METS root element

CITS 3D PM does not change or extend any of the requirements for the Root METS root element. Information is given in the tables regarding the specific content type attributes to be used in CITS 3D PM.

Example: METS example of root METS element for an IP following the CITS 3D PM

<mets:mets xmlns:mets="http://www.loc.gov/METS/" xmlns:csip="https://DILCIS.eu/XML/METS/CSIPExtensionMETS" xmlns:sip="https://DILCIS.eu/XML/METS/SIPExtensionMETS" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xlink="http://www.w3.org/1999/xlink" xsi:schemaLocation="http://www.loc.gov/METS/ http://www.loc.gov/standards/mets/mets.xsd         http://www.w3.org/1999/xlink http://www.loc.gov/standards/mets/xlink.xsd         https://DILCIS.eu/XML/METS/CSIPExtensionMETS https://earkcsip.dilcis.eu/schema/DILCISExtensionMETS.xsd         https://DILCIS.eu/XML/METS/SIPExtensionMETS https://earksip.dilcis.eu/schema/DILCISExtensionSIPMETS.xsd" OBJID="Product Model Package" TYPE="OTHER" csip:OTHERTYPE="Product Model Data" csip:CONTENTINFORMATIONTYPE="cits3dpm_v1_0" LABEL="Product Model Data from Landivisiau Engineering SARL" PROFILE="https://cits3dpm.dilcis.eu/profile/E-ARK-3dpm-ROOT-v1-0-0.xml">
</mets:mets>

3.2.5.4. Root METS header element (element metsHdr)

The tables describe the differences in the package metsHdr element between CSIP, IP and the CITS 3D PM specification.

Example: METS example of root METS Header with submission agreements for an eHealth1 IP.

<mets:metsHdr CREATEDATE="2024-04-24T14:37:49.602+01:00" LASTMODDATE="2024-04-24T14:37:49.602+01:00" RECORDSTATUS="NEW" csip:OAISPACKAGETYPE="SIP">
  <mets:altRecordID TYPE="SUBMISSIONAGREEMENT">
    http://submissionagreement.le.fr/dnr331-1144-2011/20120711/
  </mets:altRecordID>
  <mets:altRecordID TYPE="PREVIOUSSUBMISSIONAGREEMENT">
    http://submissionagreement.le.fr/dnr330-1122-2009/20110613/
  </mets:altRecordID>
  <mets:altRecordID TYPE="REFERENCECODE">
    SE/RA/123456/24/P
  </mets:altRecordID>
  <mets:altRecordID TYPE="PREVIOUSREFERENCECODE">
    SE/FM/122684/22/H
  </mets:altRecordID>
  <mets:agent ROLE="CREATOR" TYPE="OTHER" OTHERTYPE="SOFTWARE">
    <mets:name>
      product model sip software
    </mets:name>
    <mets:note csip:NOTETYPE="SOFTWARE VERSION">
      version 1.1
    </mets:note>
  </mets:agent>
  <mets:agent ROLE="CREATOR" TYPE="ORGANIZATION">
    <mets:name>
      Lanivisiau Engineering
    </mets:name>
    <mets:note csip:NOTETYPE="IDENTIFICATIONCODE">
      ID:89101112
    </mets:note>
  </mets:agent>
  <mets:agent ROLE="CREATOR" TYPE="INDIVIDUAL">
    <mets:name>
      Tanguy Mesguen
    </mets:name>
    <mets:note>
      Phone: 33 6 12 34 56, Email: tanguy.mesguen@landi.mail
    </mets:note>
  </mets:agent>
  <mets:agent ROLE="PRESERVATION" TYPE="ORGANIZATION">
    <mets:name>
      Landivisiau Engineering
    </mets:name>
    <mets:note csip:NOTETYPE="IDENTIFICATIONCODE">
      ID:1234567
    </mets:note>
  </mets:agent>
</mets:metsHdr>

3.2.5.5. Root METS descriptive metadata section (element dmdSec)

According to LOTAR: “the producer creates a set of Descriptive Information (DI), which includes archive metadata meeting the archives requirements (according to ISO 14721:2003 – OAIS).” Neither CSIP or LOTAR make any assumptions regarding the use of specific descriptive metadata schemas and so this is left to the user organisation with a recommendation to use standardised or defined schemas.

There are no specific requirements in CITS 3D PM for the root METS descriptive metadata section.

3.2.5.6. Root METS administrative metadata section (element amdSec)

The administrative metadata section contains four sub-sections each used to record different types of metadata for package content: technical metadata (element techMD) records technical metadata; rights metadata (element rightsMD) records intellectual property rights information; source metadata (element sourceMD) records descriptive technical or rights metadata for an analogue source for a digital object; and digital provenance metadata (element digiprovMD) records digital preservation information, e.g. audit information for an object’s lifecycle.

The CSIP (and METS) categorise preservation metadata as administrative metadata, specifically digital provenance metadata (following the avaiable guidelines published by the Library of Congress): (http://www.loc.gov/standards/premis/guidelines2017-premismets.pdf) and hence all preservation metadata should be referenced from a digiprovMD element within the amdSec.

As detailed Rights information is required by LOTAR for the package then CITS 3D PM recommends the inclusion of a PREMIS file in the metadata/preservation folder containing detailed Rights information as described in Rights Metadata and any digital provenance metadata as described in the CITS Preservation Metadata.

3.2.5.7. Root METS file metadata section (element fileSec)

The CSIP does not make use of the METS fileSec element mandatory, but it is strongly recommended. In the 3D PM CITS the use of the METS fileSec element at the package level becomes mandatory, such as to reference the METS files within each representation.

Example: METS example of Root METS fileSec following CITS 3D PM with file information.

<mets:fileSec ID="filesec-example">
  <mets:fileGrp ID="filegrp-documentation-authentication" USE="Authentication Documentation">
    <mets:file ID="file-data-quality-rules" MIMETYPE="application/vnd.openxmlformats-officedocument.wordprocessing.document" SIZE="43445212" CREATED="2023-08-15T12:08:15.432+01:00" CHECKSUM="160D71F56C2CE685CE7FBD679076FD76B3C67EE9AB5062F5EF5C99AE39C1F43B" CHECKSUMTYPE="SHA-256" ADMID="digiprov-premis-file1">
      <mets:FLocat LOCTYPE="URL" xlink:type="simple" xlink:href="documentation/authentication/dataquality1.docx">
      </mets:FLocat>
    </mets:file>
    <mets:file ID="file-documentation-validation-properties-rules-data" MIMETYPE="application/vnd.openxmlformats-officedocument.wordprocessingml.document" SIZE="31462826" CREATED="2023-08-15T14:44:45.432+01:00" CHECKSUM="0FE9683451D0390BCDEF19CE10CFD287A2D944B6A33D246681FEF27F44FFAF1D" CHECKSUMTYPE="SHA-256" ADMID="digiprov-premis-file1">
      <mets:FLocat LOCTYPE="URL" xlink:type="simple" xlink:href="documentation/authentication/valpropsrulesdata1.docx">
      </mets:FLocat>
    </mets:file>
  </mets:fileGrp>
  <mets:fileGrp ID="filegrp-documentation-other" USE="Other Documentation">
    <mets:file ID="file-submission-agreement" MIMETYPE="application/pdf" SIZE="21464778" CREATED="2024-08-15T12:08:15.432+01:00" CHECKSUM="0FE9683451D0390BCDEF19CE10CFD287A2D944B6A33D246681FEF27F44FFAF1D" CHECKSUMTYPE="SHA-256" ADMID="digiprov-premis-file1">
      <mets:FLocat LOCTYPE="URL" xlink:type="simple" xlink:href="documentation/other/subagreement.pdf">
      </mets:FLocat>
    </mets:file>
    <mets:file ID="file-electronic-signature-validation" MIMETYPE="application/pdf" SIZE="3162826" CREATED="2024-08-15T14:44:45.432+01:00" CHECKSUM="160D71F56C2CE685CE7FBD679076FD76B3C67EE9AB5062F5EF5C99AE39C1F43B" CHECKSUMTYPE="SHA-256" ADMID="digiprov-premis-file1">
      <mets:FLocat LOCTYPE="URL" xlink:type="simple" xlink:href="documentation/other/signaturevalidation.pdf">
      </mets:FLocat>
    </mets:file>
  </mets:fileGrp>
  <mets:fileGrp ID="filegrp-schemas" USE="Schemas">
    <mets:file ID="file-ptr-schema1" MIMETYPE="text/xsd" SIZE="123917" CREATED="2021-04-24T14:37:49.617+01:00" CHECKSUM="4073D09CA1BAE023D5A7E2010819BF0E8A8EB3C015444D0673733630DE08461C" CHECKSUMTYPE="SHA-256" ADMID="digiprov-premis-file1">
      <mets:FLocat LOCTYPE="URL" xlink:type="simple" xlink:href="schemas/ead.xsd">
      </mets:FLocat>
    </mets:file>
    <mets:file ID="file-ptr-schema2" MIMETYPE="application/xml" SIZE="6814" CREATED="2015-12-04T09:59:45" CHECKSUM="B565CA93CD86950503F233A7906E4DB709088BA42B9D109D4A8D6F183799603F" CHECKSUMTYPE="SHA-256" ADMID="digiprov-premis-file1">
      <mets:FLocat xlink:href="schemas/METS.xsd" xlink:type="simple" LOCTYPE="URL">
      </mets:FLocat>
    </mets:file>
  </mets:fileGrp>
  <mets:fileGrp ID="filegrp-rep-original-product-model" USE="representations/original-product-model" ADMD="preservation-premis-file1 rights-premis-file2" DMDID="dmd-ead-file1" csip:CONTENTINFORMATIONTYPE="cits3dpm_v1_0">
    <mets:file ID="file-ptr-repmets1" MIMETYPE="xml" SIZE="1338744" CREATED="2024-04-24T14:33:23.617+01:00" CHECKSUM="B1CF59678A21C2805370536AB1097735D7E9F3FDDDCAE3757426ED85F6350A48" CHECKSUMTYPE="SHA-256">
      <mets:FLocat LOCTYPE="URL" xlink:type="simple" xlink:href="representations/original-product-model/mets.xml">
      </mets:FLocat>
    </mets:file>
  </mets:fileGrp>
  <mets:fileGrp ID="filegrp-rep-derived-product-model" USE="representations/step-product-model" ADMD="preservation-premis-file1 rights-premis-file2" DMDID="dmd-ead-file1" csip:CONTENTINFORMATIONTYPE="cits3dpm_v1_0">
    <mets:file ID="file-ptr-repmets2" MIMETYPE="xml" SIZE="1338744" CREATED="2018-04-24T14:33:23.617+01:00" CHECKSUM="B1CF59678A21C2805370536AB1097735D7E9F3FDDDCAE3757426ED85F6350A48" CHECKSUMTYPE="SHA-256">
      <mets:FLocat LOCTYPE="URL" xlink:type="simple" xlink:href="representations/step-product-model/mets.xml">
      </mets:FLocat>
    </mets:file>
  </mets:fileGrp>
</mets:fileSec>

3.2.5.8. Root METS structural map (element structMap)

The METS structural map element is the only mandatory element in the METS specification. It provides an overview of the components described in the METS document. It can also link the elements in the structure to associated content files and metadata. In CITS 3D PM the package structMap describes the high-level structure of all the content in the package and links to at least one Representation. To allow for the inclusion of multiple Product Model Representations in each package, the CITS 3D PM specification requires that each Product Model has a discrete div element.

The Representation METS.xml is referenced from the package METS.xml via the element, and hence the requirements for the structMap element within the package METS.xml (CSIP requirements CSIP80 to CSIP118) are unchanged. Because a Representation is present, the need for a Content Division in the package METS.xml structMap is not required (CSIP101 to CSIP105).

The structural map should reference the documentation/authentication file group located in the documentation/authentication sub-folder by means of a separate div element.

The structural map should reference the documentation/other file group located in the documentation/other sub-folder by means of a separate div element.

Implementers are welcome to define additional structural maps for their internal purposes by repeating the structMap element. The specific requirements for elements, sub-elements and attributes for 3D PM CITS, which differ from the CSIP, are listed in the table.

Example: METS root example of the mandatory structural map including representations for eHealth1

<mets:structMap ID="struct-map-example" TYPE="PHYSICAL" LABEL="CSIP">
  <mets:div ID="struct-map-example-div" LABEL="cits-3dpm-example">
    <mets:div ID="struct-map-metadata-div" LABEL="Metadata" DMDID="dmd-ead-file" ADMD="digiprov-premis-file1 rights-premis-file1 rights-premis-file1">
    </mets:div>
    <mets:div ID="struct-map-documentation-div" LABEL="Documentation">
      <mets:div ID="structmap-documentation-authentication-div" LABEL="Documentation">
        <mets:fileptr FILEID="filegrp-documentation-authentication">
        </mets:fileptr>
      </mets:div>
      <mets:div ID="structmap-documentation-other-div" LABEL="Documentation">
        <mets:fileptr FILEID="filegrp-documentation-other">
        </mets:fileptr>
      </mets:div>
    </mets:div>
    <mets:div ID="struct-map-schemas-div" LABEL="Schemas">
      <mets:fptr FILEID="filegrp-schemas">
      </mets:fptr>
    </mets:div>
    <mets:div ID="struct-map-rep1-div" LABEL="Representations/original-product-model">
      <mets:mptr LOCTYPE="URL" xlink:type="simple" xlink:href="representations/original-product-model/METS.xml" xlink:title="filegrp-rep-original-product-model">
      </mets:mptr>
    </mets:div>
    <mets:div ID="struct-map-rep2-div" LABEL="representations/step-product-model">
      <mets:mptr LOCTYPE="URL" xlink:type="simple" xlink:href="representations/step-product-model/METS.xml" xlink:title="filegrp-rep-derived-product-model">
      </mets:mptr>
    </mets:div>
  </mets:div>
</mets:structMap>

3.2.5.9. Representation METS Files

The Representation METS files are used to describe the data structure as included in the data folder of each Representation (Product Model representations) via the structMap element and to reference additional descriptive and preservation metadata.

3.2.5.10. Representation METS root element

CITS 3D PM does not change or extend any of the requirements for the Representation root element but particular notice is drawn to the specific requirements of a Representation METS root element and the specific content type attributes to be used in CITS 3D PM.

Example: METS example of representation Root METS element for an IP following the CITS 3DPM

<mets:mets xmlns:mets="http://www.loc.gov/METS/" xmlns:csip="https://DILCIS.eu/XML/METS/CSIPExtensionMETS" xmlns:sip="https://DILCIS.eu/XML/METS/SIPExtensionMETS" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xlink="http://www.w3.org/1999/xlink" OBJID="original-product-model" TYPE="OTHER" csip:OTHERTYPE="Product Model Data" csip:CONTENTINFORMATIONTYPE="cits3dpm_v1_0" PROFILE="https://cits3dpm.dilcis.eu/profile/E-ARK-3dpm-REPRESENTATION-v1-0-0.xml" xsi:schemaLocation="http://www.loc.gov/METS/ http://www.loc.gov/standards/mets/mets.xsd http://www.w3.org/1999/xlink http://www.loc.gov/standards/mets/xlink.xsd https://DILCIS.eu/XML/METS/CSIPExtensionMETS https://earkcsip.dilcis.eu/schema/DILCISExtensionMETS.xsd https://DILCIS.eu/XML/METS/SIPExtensionMETS https://earksip.dilcis.eu/schema/DILCISExtensionSIPMETS.xsd">
</mets:mets>

3.2.5.11. Representation METS header element (element metsHdr)

There are no specific requirements for the header element in a CITS 3D PM Representation METS. The 3D PM Representation metsHdr element should comply with the metsHdr requirements in the appropriate Information Package profile and can be used to identify specific agents related to a Product Model Representation.

3.2.5.12. Representation METS descriptive metadata section (element dmdSec)

There are no specific requirements in CITS 3D PM for the Representation METS Descriptive Metadata section.

3.2.5.13. Representation METS administrative metadata section (element amdSec)

The Administrative Metadata section contains four sub-sections each used to record different types of metadata for package content: technical metadata (element techMD) records technical metadata; rights metadata (element rightsMD) records intellectual property rights information; source metadata (element sourceMD) records descriptive technical or rights metadata for an analogue source for a digital object; and digital provenance metadata (element digiprovMD) records digital preservation information, e.g. audit information for an object’s lifecycle.

The CSIP (and METS) categorise preservation metadata as Administrative Metadata, specifically digital provenance metadata (following the available guidelines published by the Library of Congress): (http://www.loc.gov/standards/premis/guidelines2017-premismets.pdf) and hence all preservation metadata should be referenced from a digiprovMD element within the amdSec.

As detailed provenance, authentication and technical metadata is required by LOTAR for each Product Information Model then CITS 3D PM strongly recommends the inclusion of a PREMIS file in the representation/metadata/preservation folder containing detailed metadata for: Verification events, Validation events, Digital Signatures and digital provenance information.

Example: METS example of representation METS amdSec

<mets:amdSec>
  <mets:digiprovMD ID="preservation-premis-file3" CREATED="2024-04-24T15:27:45.702+01:00" STATUS="CURRENT">
    <mets:mdRef LOCTYPE="URL" xlink:href="metadata/preservation/premis3.xml" xlink:type="simple" MDTYPE="PREMIS" MIMETYPE="application/xml" SIZE="1211" CREATED="2024-04-24T14:11:29.309+01:00" CHECKSUM="8aa278038dbad54bbf142e7d72b493e2598a94946ea1304dc82a79c6b4bac3d5 " CHECKSUMTYPE="SHA-256">
    </mets:mdRef>
  </mets:digiprovMD>
</mets:amdSec>

3.2.5.14. Representation METS file metadata section (element fileSec)

The CSIP does not make the use of the METS fileSec element mandatory, but it is strongly recommended. In the 3D Product Model CITS, the use of the METS fileSec element at the Representation level becomes mandatory, such as to reference the Content Data Objects within each Representation and link to preservation information held within mandatory PREMIS files.

Example: METS representation mets example for an IP following CITS 3DPM with administrative metadata at group level.

<mets:fileSec ID="filesec-example">
  <mets:fileGrp ID="filegrp-documentation-authentication" USE="Documentation">
    <mets:file ID="file-validation-report" MIMETYPE="application/vnd.openxmlformats-officedocument.wordprocessing.document" SIZE="43445212" CREATED="2023-08-15T12:08:15.432+01:00" CHECKSUM="160D71F56C2CE685CE7FBD679076FD76B3C67EE9AB5062F5EF5C99AE39C1F43B" CHECKSUMTYPE="SHA-256">
      <mets:FLocat LOCTYPE="URL" xlink:type="simple" xlink:href="documentation/authentication/validationrep.docx">
      </mets:FLocat>
    </mets:file>
  </mets:fileGrp>
  <mets:fileGrp ID="filegrp-documentation-other" USE="Documentation">
    <mets:file ID="file-licence-agreement" MIMETYPE="application/pdf" SIZE="21464778" CREATED="2024-08-15T12:08:15.432+01:00" CHECKSUM="0FE9683451D0390BCDEF19CE10CFD287A2D944B6A33D246681FEF27F44FFAF1D" CHECKSUMTYPE="SHA-256" ADMID="digiprov-premis-file1">
      <mets:FLocat LOCTYPE="URL" xlink:type="simple" xlink:href="documentation/other/subagreement.pdf">
      </mets:FLocat>
    </mets:file>
    <mets:file ID="file-electronic-signature-validation" MIMETYPE="application/pdf" SIZE="3162826" CREATED="2024-08-15T14:44:45.432+01:00" CHECKSUM="160D71F56C2CE685CE7FBD679076FD76B3C67EE9AB5062F5EF5C99AE39C1F43B" CHECKSUMTYPE="SHA-256" ADMID="digiprov-premis-file1">
      <mets:FLocat LOCTYPE="URL" xlink:type="simple" xlink:href="documentation/other/signaturevalidation.pdf">
      </mets:FLocat>
    </mets:file>
  </mets:fileGrp>
  <mets:fileGrp ID="filegrp-original-product-model" USE="Representations" csip:CONTENTINFORMATIONTYPE="cits3dpm_v1_0" ADMD="digiprov-premis-file3">
    <mets:file ID="file-original-product-model" MIMETYPE="dwg" SIZE="10338744" CREATED="2024-04-24T14:33:23.617+01:00" CHECKSUM="B1CF59678A21C2805370536AB1097735D7E9F3FDDDCAE3757426ED85F6350A48" CHECKSUMTYPE="SHA-256">
      <mets:FLocat LOCTYPE="URL" xlink:type="simple" xlink:href="data/product1.dwg">
      </mets:FLocat>
    </mets:file>
  </mets:fileGrp>
</mets:fileSec>

3.2.5.15. Representation METS structural map (element structMap)

The METS structural map element is the only mandatory element in the METS specification and is hence mandatory within the Representation METS. There must be one structural map present in each Representation METS file following the requirements of the CSIP. As Authentication documentation SHOULD be included in each Representation within 3D PM CITS, there is also a mandatory requirement for a structMap division for the documentation/authentication folder. The specific requirements for elements, sub-elements and attributes for 3D PM CITS, which differ from the CSIP, are listed in the table.

Example: METS representation example of the mandatory structural map including representations for eHealth1

<mets:structMap ID="struct-map-example" TYPE="PHYSICAL" LABEL="CSIP">
  <mets:div ID="struct-map-example-div" LABEL="cits-3dpm-example">
    <mets:div ID="struct-map-metadata-div" LABEL="Metadata" ADMD="digiprovpremis-file-1 digiprov-premis-file-2">
    </mets:div>
    <mets:div ID="struct-map-documentation-div" LABEL="Documentation">
      <mets:div ID="structmap-documentation-authentication-div" LABEL="Authentication Documentation">
        <mets:fileptr FILEID="filegrp-documentation-authentication">
        </mets:fileptr>
      </mets:div>
      <mets:div ID="structmap-documentation-other-div" LABEL="Other Documentation">
        <mets:fileptr FILEID="filegrp-documentation-other">
        </mets:fileptr>
      </mets:div>
    </mets:div>
    <mets:div ID="struct-map-schemas-div" LABEL="Schemas">
      <mets:fptr FILEID="filegrp-schemas">
      </mets:fptr>
    </mets:div>
    <mets:div ID="struct-map-data-div" LABEL="Representations">
      <mets:mptr FILEID="filegrp-original-product-model">
      </mets:mptr>
    </mets:div>
  </mets:div>
</mets:structMap>

3.2.6. PREMIS

3.2.6.1. Use of PREMIS in CITS 3D PM

The use of PREMIS within the 3D PM CITS must follow the requirements of the CITS PREMIS which can be found at: (https://dilcis.eu/content-types/cits-premis).

Some PREMIS semantic units take the form of containers which comprise multiple sub (or even sub-sub) semantic units. Sub or sub-sub semantic units are not detailed in this specification if the container above has a level of MAY. Use of semantic units not listed should follow the requirements of the PREMIS data dictionary including the level (obligation).

For 3D PM CITS the use of PREMIS follows an interpretation of LOTAR as described in 3D PM10 and 3D PM11 above as follows:

3D PM10: there SHOULD be a PREMIS file produced according to CITS PREMIS and adjusted to the requirements of this CITS in the metadata/preservation folder of the Information Package.

3D PM11: there SHOULD be a PREMIS file produced according to CITS PREMIS and conforming to the adjusted requirements of this CITS in each Representation of the Information Package in the representation/metadata/preservation folder.

Following CITS PREMIS the CITS 3D PM follows the requirements and recommendation of the PREMIS Data Dictionary which can be found at: (https://www.loc.gov/standards/premis/v3/premis-3-0-final.pdf).

3.2.6.2. Attribute values and controlled vocabularies

Use of controlled vocabularies for the values of semantic units is encouraged within the PREMIS Data Dictionary and through best practice. Specific controlled vocabularies for semantic units are not provided by the CITS but their use is encouraged, particularly the use of any vocabularies provided by the LOTAR standard. If local vocabularies are used within the repository then these should be included within each package.

3.2.6.3. Use of PREMIS at package level

PREMIS can be used in addition to METS to support compliance with LOTAR in recording specific rights information at package level. Note that if PREMIS is used then the requirements of the CITS Preservation apply and those provided by the CITS 3D PM are in addition to these.

3.2.6.4. Preservation information

3D PM52: Preservation information for the entire package (e.g. provenance, preservation actions) MAY be recorded within the PREMIS file located in the metadata/preservation folder and must follow guidelines set out in CITS PREMIS.

3.2.6.5. Rights Information

3D PM53: Rights for the entire package (e.g. copyright, license, statute, other, rights grants) MAY be recorded within the PREMIS file located in the metadata/preservation folder using the PREMIS Rights entity and must follow the guidelines set out in CITS PREMIS. Each individual rights statement (copyright, licence, statute, other, rights granted) must be held in a separate rightsStatement semantic unit. Designation of the basis for the right or permission can be taken from the vocabulary available at: http://id.loc.gov/vocabulary/preservation/rightsBasis.html which are: license, copyright, statute, other. Information on rights associated with the rights basis can be included within the otherRightsInformation PREMIS semantic unit container using values from available controlled vocabularies.

3.2.6.6. Use of PREMIS at Representation level

PREMIS can be used in addition to METS to support compliance with LOTAR in recording specific Validation and Verification events information at representation level. Note that if PREMIS is used then the requirements of the CITS Preservation apply and those provided by the CITS 3D PM are in addition to these.

3.2.6.7. Preservation information

3D PM54: Preservation information for each Representation (e.g. provenance, preservation actions) MAY be recorded within the PREMIS file located in the representation/metadata/preservation folder and must follow guidelines set out in CITS PREMIS.

3.2.6.8. Validation and Verification information

3D PM55: Product Data Model Validation and Verification events MAY be recorded within the PREMIS file located in each representation/metadata/preservation folder, using the PREMIS Event entity and should follow guidelines set out in CITS PREMIS. Values for eventTypes, eventDetailInformation and eventOutcomeInfoirmation should take values from a controlled vocabulary and events should be linked to their respective objects using a linking object identifier.

3.2.6.9. Digital Signatures for Product Information Models

From 3D PM7: AIPs MAY contain Digital Signatures associated with Product Model Representations that are encoded within a Representation PREMIS file at object level using the signatureInformation semantic unit and signature events recorded as PREMIS Event entities.

3D PM56: If a Digital Signature is provided for an object then the operations to be performed to validate the object SHOULD be detailed. This could be a canonicalized method used before calculating the message digest or a pointer to a document in the representation/documentation/authentication folder.

3D PM57: If a Digital Signature is provided then further properties of the signature SHOULD be provided within the signatureProperties element to at least include a date and time of the signature. The granular structure of signaturePropertiesis not defined by PREMIS but an example of a possible date record within the signatureProperties element is shown below.

3D PM58: If a Digital Signature is provided, then information about the signer’s public key SHOULD be provided within the keyInformation element. Different types of keys have different structures and parameters and so PREMIS does not define the structure of this container element and recommends practice from “KeyInfo” in the W3C’s XML-Signature Syntax and Processing (http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/) to represent key values.

4. Glossary

5. Appendices

5.1. Appendix A: CITS3D Information Package METS Examples

5.1.1. Example 1: Example of a whole METS document describing a submission information package following CITS 3D PM (cits-3dpm_v1_0).

<mets:mets xmlns:mets="http://www.loc.gov/METS/" xmlns:csip="https://DILCIS.eu/XML/METS/CSIPExtensionMETS" xmlns:sip="https://DILCIS.eu/XML/METS/SIPExtensionMETS" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xlink="http://www.w3.org/1999/xlink" xsi:schemaLocation="http://www.loc.gov/METS/ http://www.loc.gov/standards/mets/mets.xsd             http://www.w3.org/1999/xlink http://www.loc.gov/standards/mets/xlink.xsd             https://DILCIS.eu/XML/METS/CSIPExtensionMETS              https://earkcsip.dilcis.eu/schema/DILCISExtensionMETS.xsd              https://DILCIS.eu/XML/METS/SIPExtensionMETS              https://earksip.dilcis.eu/schema/DILCISExtensionSIPMETS.xsd" OBJID="Product_Model_Package" TYPE="OTHER" csip:OTHERTYPE="Product Model Data" csip:CONTENTINFORMATIONTYPE="cits3dpm_v1_0" LABEL="Product Model Data from Landivisiau Engineering SARL" PROFILE="https://cits3dpm.dilcis.eu/profile/E-ARK-3DPM-ROOT-v1-0-0.xml">
  <mets:metsHdr CREATEDATE="2024-04-24T14:37:49.602+01:00" LASTMODDATE="2024-04-24T14:37:49.602+01:00" RECORDSTATUS="NEW" csip:OAISPACKAGETYPE="SIP">
    <mets:altRecordID TYPE="SUBMISSIONAGREEMENT">
      http://submissionagreement.le.fr/dnr331-1144-2011/20120711/
    </mets:altRecordID>
    <mets:altRecordID TYPE="PREVIOUSSUBMISSIONAGREEMENT">
      http://submissionagreement.le.fr/dnr330-1122-2009/20110613/
    </mets:altRecordID>
    <mets:altRecordID TYPE="REFERENCECODE">
      SE/RA/123456/24/P
    </mets:altRecordID>
    <mets:altRecordID TYPE="PREVIOUSREFERENCECODE">
      SE/FM/122684/22/H
    </mets:altRecordID>
    <mets:agent ROLE="CREATOR" TYPE="OTHER" OTHERTYPE="SOFTWARE">
      <mets:name>
        product model sip software
      </mets:name>
      <mets:note csip:NOTETYPE="SOFTWARE VERSION">
        version 1.1
      </mets:note>
    </mets:agent>
    <mets:agent ROLE="CREATOR" TYPE="ORGANIZATION">
      <mets:name>
        Lanivisiau Engineering
      </mets:name>
      <mets:note csip:NOTETYPE="IDENTIFICATIONCODE">
        ID:89101112
      </mets:note>
    </mets:agent>
    <mets:agent ROLE="CREATOR" TYPE="INDIVIDUAL">
      <mets:name>
        Tanguy Mesguen
      </mets:name>
      <mets:note>
        Phone: 33 6 12 34 56, Email: tanguy.mesguen@landi.mail
      </mets:note>
    </mets:agent>
    <mets:agent ROLE="PRESERVATION" TYPE="ORGANIZATION">
      <mets:name>
        Landivisiau Engineering
      </mets:name>
      <mets:note csip:NOTETYPE="IDENTIFICATIONCODE">
        ID:1234567
      </mets:note>
    </mets:agent>
  </mets:metsHdr>
  <mets:dmdSec ID="dmd-ead-file1" CREATED="2024-04-24T15:27:45.702+01:00" STATUS="CURRENT">
    <mets:mdRef LOCTYPE="URL" xlink:href="metadata/descriptive/ead1.xml" xlink:type="simple" MDTYPE="EAD" MIMETYPE="application/xml" SIZE="643" CREATED="2024-04-24T14:11:29.309+01:00" CHECKSUM="66EEDDF0A22EF57078694B67CA45DF301034556D6CB493531356C4FFE92AB6B1" CHECKSUMTYPE="SHA-256">
    </mets:mdRef>
  </mets:dmdSec>
  <mets:amdSec>
    <mets:digiprovMD ID="digiprov-premis-file1" CREATED="2024-04-24T15:27:45.702+01:00" STATUS="CURRENT">
      <mets:mdRef LOCTYPE="URL" xlink:href="metadata/preservation/premis1.xml" xlink:type="simple" MDTYPE="PREMIS" MIMETYPE="application/xml" SIZE="1211" CREATED="2024-04-24T14:11:29.309+01:00" CHECKSUM="8aa278038dbad54bbf142e7d72b493e2598a94946ea1304dc82a79c6b4bac3d5
" CHECKSUMTYPE="SHA-256">
      </mets:mdRef>
    </mets:digiprovMD>
    <mets:digiprovMD ID="rights-premis-file2" CREATED="2024-04-24T15:27:45.702+01:00" STATUS="CURRENT">
      <mets:mdRef LOCTYPE="URL" xlink:href="metadata/preservation/premis2.xml" xlink:type="simple" MDTYPE="PREMIS" MIMETYPE="application/xml" SIZE="563" CREATED="2024-04-24T14:11:29.309+01:00" CHECKSUM="66EEDDF0A22EF57078694B67CA45DF301034556D6CB493531356C4FFE92AB6B1" CHECKSUMTYPE="SHA-256">
      </mets:mdRef>
    </mets:digiprovMD>
  </mets:amdSec>
  <mets:fileSec ID="filesec-product-model-root">
    <mets:fileGrp ID="filegrp-documentation-authentication" USE="Documentation">
      <mets:file ID="file-data-quality-rules" MIMETYPE="application/vnd.openxmlformats-officedocument.wordprocessing.document" SIZE="43445212" CREATED="2023-08-15T12:08:15.432+01:00" CHECKSUM="160D71F56C2CE685CE7FBD679076FD76B3C67EE9AB5062F5EF5C99AE39C1F43B" CHECKSUMTYPE="SHA-256" ADMID="digiprov-premis-file1">
        <mets:FLocat LOCTYPE="URL" xlink:type="simple" xlink:href="documentation/authentication/dataquality1.docx">
        </mets:FLocat>
      </mets:file>
      <mets:file ID="file-documentation-validation-properties-rules-data" MIMETYPE="application/vnd.openxmlformats-officedocument.wordprocessingml.document" SIZE="31462826" CREATED="2023-08-15T14:44:45.432+01:00" CHECKSUM="0FE9683451D0390BCDEF19CE10CFD287A2D944B6A33D246681FEF27F44FFAF1D" CHECKSUMTYPE="SHA-256" ADMID="digiprov-premis-file1">
        <mets:FLocat LOCTYPE="URL" xlink:type="simple" xlink:href="documentation/authentication/valpropsrulesdata1.docx">
        </mets:FLocat>
      </mets:file>
    </mets:fileGrp>
    <mets:fileGrp ID="filegrp-documentation-other" USE="Documentation">
      <mets:file ID="file-submission-agreement" MIMETYPE="application/pdf" SIZE="21464778" CREATED="2024-08-15T12:08:15.432+01:00" CHECKSUM="0FE9683451D0390BCDEF19CE10CFD287A2D944B6A33D246681FEF27F44FFAF1D" CHECKSUMTYPE="SHA-256" ADMID="digiprov-premis-file1">
        <mets:FLocat LOCTYPE="URL" xlink:type="simple" xlink:href="documentation/other/subagreement.pdf">
        </mets:FLocat>
      </mets:file>
      <mets:file ID="file-electronic-signature-validation" MIMETYPE="application/pdf" SIZE="3162826" CREATED="2024-08-15T14:44:45.432+01:00" CHECKSUM="160D71F56C2CE685CE7FBD679076FD76B3C67EE9AB5062F5EF5C99AE39C1F43B" CHECKSUMTYPE="SHA-256" ADMID="digiprov-premis-file1">
        <mets:FLocat LOCTYPE="URL" xlink:type="simple" xlink:href="documentation/other/signaturevalidation.pdf">
        </mets:FLocat>
      </mets:file>
    </mets:fileGrp>
    <mets:fileGrp ID="filegrp-schemas" USE="Schemas">
      <mets:file ID="file-ptr-schema1" MIMETYPE="text/xsd" SIZE="123917" CREATED="2021-04-24T14:37:49.617+01:00" CHECKSUM="4073D09CA1BAE023D5A7E2010819BF0E8A8EB3C015444D0673733630DE08461C" CHECKSUMTYPE="SHA-256" ADMID="digiprov-premis-file1">
        <mets:FLocat LOCTYPE="URL" xlink:type="simple" xlink:href="schemas/ead.xsd">
        </mets:FLocat>
      </mets:file>
      <mets:file ID="file-ptr-schema2" MIMETYPE="application/xml" SIZE="6814" CREATED="2015-12-04T09:59:45" CHECKSUM="B565CA93CD86950503F233A7906E4DB709088BA42B9D109D4A8D6F183799603F" CHECKSUMTYPE="SHA-256" ADMID="digiprov-premis-file1">
        <mets:FLocat xlink:href="schemas/METS.xsd" xlink:type="simple" LOCTYPE="URL">
        </mets:FLocat>
      </mets:file>
    </mets:fileGrp>
    <mets:fileGrp ID="filegrp-rep-original-product-model" USE="representations/original-product-model" ADMD="digiprov-pm-file1 rights-pm-file1" DMDID="dmd-ead-file" csip:CONTENTINFORMATIONTYPE="cits3dpm_v1_0">
      <mets:file ID="file-ptr-repmets1" MIMETYPE="xml" SIZE="1338744" CREATED="2024-04-24T14:33:23.617+01:00" CHECKSUM="B1CF59678A21C2805370536AB1097735D7E9F3FDDDCAE3757426ED85F6350A48" CHECKSUMTYPE="SHA-256">
        <mets:FLocat LOCTYPE="URL" xlink:type="simple" xlink:href="representations/original-product-model/mets.xml">
        </mets:FLocat>
      </mets:file>
    </mets:fileGrp>
    <mets:fileGrp ID="filegrp-rep-derived-product-model" USE="representations/step-product-model" ADMD="digiprov-pm-file1 rights-pm-file2" DMDID="dmd-ead-file" csip:CONTENTINFORMATIONTYPE="cits3dpm_v1_0">
      <mets:file ID="file-ptr-repmets2" MIMETYPE="xml" SIZE="1338744" CREATED="2018-04-24T14:33:23.617+01:00" CHECKSUM="B1CF59678A21C2805370536AB1097735D7E9F3FDDDCAE3757426ED85F6350A48" CHECKSUMTYPE="SHA-256">
        <mets:FLocat LOCTYPE="URL" xlink:type="simple" xlink:href="representations/step-product-model/mets.xml">
        </mets:FLocat>
      </mets:file>
    </mets:fileGrp>
  </mets:fileSec>
  <mets:structMap ID="struct-map-product-model-root" TYPE="PHYSICAL" LABEL="CSIP">
    <mets:div ID="struct-map-example-div" LABEL="cits-3dpm-example">
      <mets:div ID="struct-map-metadata-div" LABEL="Metadata" DMDID="dmd-ead-file" ADMD="digiprov-premis-file1 rights-premis-file1 rights-premis-file1">
      </mets:div>
      <mets:div ID="struct-map-documentation-div" LABEL="Documentation">
        <mets:div ID="structmap-documentation-authentication-div" LABEL="Documentation">
          <mets:fileptr FILEID="filegrp-documentation-authentication">
          </mets:fileptr>
        </mets:div>
        <mets:div ID="structmap-documentation-other-div" LABEL="Documentation">
          <mets:fileptr FILEID="filegrp-documentation-other">
          </mets:fileptr>
        </mets:div>
      </mets:div>
      <mets:div ID="struct-map-schemas-div" LABEL="Schemas">
        <mets:fptr FILEID="filegrp-schemas">
        </mets:fptr>
      </mets:div>
      <mets:div ID="struct-map-rep1-div" LABEL="representations/original-product-model">
        <mets:mptr LOCTYPE="URL" xlink:type="simple" xlink:href="representations/original-product-model/METS.xml" xlink:title="file-grp-rep-original-product-model">
        </mets:mptr>
      </mets:div>
      <mets:div ID="struct-map-rep2-div" LABEL="representations/step-product-model">
        <mets:mptr LOCTYPE="URL" xlink:type="simple" xlink:href="representations/step-product-model/METS.xml" xlink:title="file-grp-rep-derived-product-model">
        </mets:mptr>
      </mets:div>
    </mets:div>
  </mets:structMap>
</mets:mets>

5.1.2. Example 2: Example of a whole METS document describing a representation following CITS 3DPM (cits3dpm_v1_0).

<mets:mets xmlns:mets="http://www.loc.gov/METS/" xmlns:csip="https://DILCIS.eu/XML/METS/CSIPExtensionMETS" xmlns:sip="https://DILCIS.eu/XML/METS/SIPExtensionMETS" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xlink="http://www.w3.org/1999/xlink" xsi:schemaLocation="http://www.loc.gov/METS/ http://www.loc.gov/standards/mets/mets.xsd http://www.w3.org/1999/xlink http://www.loc.gov/standards/mets/xlink.xsd https://DILCIS.eu/XML/METS/CSIPExtensionMETS https://earkcsip.dilcis.eu/schema/DILCISExtensionMETS.xsd https://DILCIS.eu/XML/METS/SIPExtensionMETS https://earksip.dilcis.eu/schema/DILCISExtensionSIPMETS.xsd" OBJID="original-product-model" TYPE="OTHER" csip:OTHERTYPE="Product Model Data" csip:CONTENTINFORMATIONTYPE="cits3dpm_v1_0" PROFILE="https://cits3dpm.dilcis.eu/profile/E-ARK-3DOM-REPRESENTATION-v1-0-0.xml">
  <mets:metsHdr CREATEDATE="2024-04-24T14:37:49.602+01:00" LASTMODDATE="2024-04-24T14:37:49.602+01:00" RECORDSTATUS="NEW" csip:OAISPACKAGETYPE="SIP">
    <mets:agent ROLE="CREATOR" TYPE="OTHER" OTHERTYPE="SOFTWARE">
      <mets:name>
        product model sip software
      </mets:name>
      <mets:note csip:NOTETYPE="SOFTWARE VERSION">
        version 1.1
      </mets:note>
    </mets:agent>
    <mets:agent ROLE="CREATOR" TYPE="ORGANIZATION">
      <mets:name>
        Lanivisiau Engineering
      </mets:name>
      <mets:note csip:NOTETYPE="IDENTIFICATIONCODE">
        ID:89101112
      </mets:note>
    </mets:agent>
    <mets:agent ROLE="INDIVIDUAL" TYPE="SUBMITTER">
      <mets:name>
        Tanguy Mesguen
      </mets:name>
      <mets:note>
        Phone: 33 6 12 34 56, Email: tanguy.mesguen@landi.mail
      </mets:note>
    </mets:agent>
    <mets:agent ROLE="PRESERVATION" TYPE="ORGANIZATION">
      <mets:name>
        Landivisiau Engineering
      </mets:name>
      <mets:note csip:NOTETYPE="IDENTIFICATIONCODE">
        ID:1234567
      </mets:note>
    </mets:agent>
  </mets:metsHdr>
  <mets:dmdSec ID="dmd-ead-file2" CREATED="2024-04-24T15:27:45.702+01:00" STATUS="CURRENT">
    <mets:mdRef LOCTYPE="URL" xlink:href="metadata/descriptive/ead2.xml" xlink:type="simple" MDTYPE="EAD" MIMETYPE="application/xml" SIZE="643" CREATED="2024-04-24T14:11:29.309+01:00" CHECKSUM="66EEDDF0A22EF57078694B67CA45DF301034556D6CB493531356C4FFE92AB6B1" CHECKSUMTYPE="SHA-256">
    </mets:mdRef>
  </mets:dmdSec>
  <mets:amdSec>
    <mets:digiprovMD ID="preservation-premis-file3" CREATED="2024-04-24T15:27:45.702+01:00" STATUS="CURRENT">
      <mets:mdRef LOCTYPE="URL" xlink:href="metadata/preservation/premis2.xml" xlink:type="simple" MDTYPE="PREMIS" MIMETYPE="application/xml" SIZE="1211" CREATED="2024-04-24T14:11:29.309+01:00" CHECKSUM="8aa278038dbad54bbf142e7d72b493e2598a94946ea1304dc82a79c6b4bac3d5 " CHECKSUMTYPE="SHA-256">
      </mets:mdRef>
    </mets:digiprovMD>
  </mets:amdSec>
  <mets:fileSec ID="filesec-product-model-original-product-model">
    <mets:fileGrp ID="filegrp-documentation-authentication" USE="Documentation">
      <mets:file ID="file-validation-properties-file1" MIMETYPE="application/vnd.openxmlformats-officedocument.wordprocessing.document" SIZE="43445212" CREATED="2023-08-15T12:08:15.432+01:00" CHECKSUM="160D71F56C2CE685CE7FBD679076FD76B3C67EE9AB5062F5EF5C99AE39C1F43B" CHECKSUMTYPE="SHA-256">
        <mets:FLocat LOCTYPE="URL" xlink:type="simple" xlink:href="documentation/authentication/validationprops1.docx">
        </mets:FLocat>
      </mets:file>
      <mets:file ID="file-documentation-verification-report1" MIMETYPE="application/vnd.openxmlformats-officedocument.wordprocessingml.document" SIZE="31462826" CREATED="2023-08-15T14:44:45.432+01:00" CHECKSUM="0FE9683451D0390BCDEF19CE10CFD287A2D944B6A33D246681FEF27F44FFAF1D" CHECKSUMTYPE="SHA-256">
        <mets:FLocat LOCTYPE="URL" xlink:type="simple" xlink:href="documentation/authentication/verificationrep1.docx">
        </mets:FLocat>
      </mets:file>
    </mets:fileGrp>
    <mets:fileGrp ID="filegrp-documentation-other" USE="Documentation">
      <mets:file ID="file-licence-agreement" MIMETYPE="application/pdf" SIZE="21464778" CREATED="2024-08-15T12:08:15.432+01:00" CHECKSUM="0FE9683451D0390BCDEF19CE10CFD287A2D944B6A33D246681FEF27F44FFAF1D" CHECKSUMTYPE="SHA-256" ADMID="digiprov-premis-file1">
        <mets:FLocat LOCTYPE="URL" xlink:type="simple" xlink:href="documentation/other/subagreement.pdf">
        </mets:FLocat>
      </mets:file>
      <mets:file ID="file-electronic-signature-validation" MIMETYPE="application/pdf" SIZE="3162826" CREATED="2024-08-15T14:44:45.432+01:00" CHECKSUM="160D71F56C2CE685CE7FBD679076FD76B3C67EE9AB5062F5EF5C99AE39C1F43B" CHECKSUMTYPE="SHA-256" ADMID="digiprov-premis-file1">
        <mets:FLocat LOCTYPE="URL" xlink:type="simple" xlink:href="documentation/other/signaturevalidation.pdf">
        </mets:FLocat>
      </mets:file>
    </mets:fileGrp>
    <mets:fileGrp ID="filegrp-original-product-model" USE="Representations" csip:CONTENTINFORMATIONTYPE="cits3dpm_v1_0" ADMD="preservation-premis-file3" DMDID="dmd-ead-file2">
      <mets:file ID="file-original-product-model" MIMETYPE="dwg" SIZE="10338744" CREATED="2018-04-24T14:33:23.617+01:00" CHECKSUM="B1CF59678A21C2805370536AB1097735D7E9F3FDDDCAE3757426ED85F6350A48" CHECKSUMTYPE="SHA-256">
        <mets:FLocat LOCTYPE="URL" xlink:type="simple" xlink:href="data/product1.dwg">
        </mets:FLocat>
      </mets:file>
    </mets:fileGrp>
  </mets:fileSec>
  <mets:structMap ID="struct-map-original-product-model-rep" TYPE="PHYSICAL" LABEL="CSIP">
    <mets:div ID="struct-map-data-div" LABEL="Representations">
      <mets:mptr FILEID="filegrp-original-product-model">
      </mets:mptr>
    </mets:div>
    <mets:div ID="struct-map-documentation-div" LABEL="Documentation">
      <mets:div ID="structmap-documentation-authentication-div" LABEL="Documentation">
        <mets:fileptr FILEID="filegrp-documentation-authentication">
        </mets:fileptr>
      </mets:div>
      <mets:div ID="structmap-documentation-other-div" LABEL="Documentation">
        <mets:fileptr FILEID="filegrp-documentation-other">
        </mets:fileptr>
      </mets:div>
    </mets:div>
    <mets:div ID="struct-map-metadata-div" LABEL="Metadata" DMDID="dmd-ead-file2" ADMD="digiprov-premis-file2">
    </mets:div>
  </mets:structMap>
</mets:mets>

5.2. Appendix B: External Schema

5.2.1. E-ARK SIP METS Extension

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

Context: XML-schema for the attributes added by SIP

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

5.2.2. E-ARK CSIP METS Extension

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

Context: XML-schema for the attributes added by CSIP

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

5.3. Appendix C: External Vocabularies

5.3.1. Content information type specification

Maintained By: DILCIS Board

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

Context: Values for @csip:CONTENTINFORMATIONTYPE

Note: Lists the names of specific E-ARK content information type specifications supported or maintained in this METS profile.

5.3.2. Content category and folder definitions in 3DPM

Maintained By: DILCIS Board

Location: https://citsehealth1.dilcis.eu/schema/Vocabulary3DPM.xml

Context: Predefined values for content category and documentation types

Note: Describes the extra terms supported by this profile. Own names should be placed in an own extending vocabulary.

5.4. Appendix E: E-ARK CITS3D Metadata Requirements

5.4.1. E-ARK 3D PM root METS Profile 1.0 Requirements

5.4.2. E-ARK 3DPM representation METS Profile 1.0 Requirements

Postface

I. Authors

II. Revision History

III. Contact & Feedback

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