Content Information Type Specification for Digital Geospatial Data Records Archiving

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 Geospatial

Content Information Type Specification for Digital Geospatial Data Records Archiving

Version: 3.0.0

Date: 2024-12-13

1. Context
1.1. Purpose
1.2. Scope
1.3. Information Package Layered data model
2. CITS Geospatial requirements structure
2.1. Folder structure requirements
2.2. METS Requirements
2.2.1. Package and Representation METS
2.2.2. Package METS requirements
2.2.3. Representation METS requirements
2.3. Data requirements (Geospatial data)
2.3.1. Geodata general - requirements
2.3.2. Vector Geodata - requirements
2.3.3. Raster Geodata - requirements
2.3.4. Non-spatial data - requirements
2.3.5. Long Term Preservation Format Profiles
2.3.6. Other Geospatial data
2.4. Documentation requirements
2.4.1. Structure of geospatial records
2.4.2. Rendering and visualisation
2.4.3. Behaviour - Software and algorithms
2.4.4. Coordinate reference system information- requirements
2.4.5. Other - Contextual Documentation requirements
2.5. Geospatial Metadata requirements
3. Glossary
4. Appendices
4.1. Appendix A: E-ARK Information Package METS Examples
4.1.1. Example 1: Example of a whole METS document describing an representation following CITS Geospatial.
4.1.2. Example 1: Example of a whole METS document describing an submission information package following CITS Geospatial.
4.2. Appendix B: External Schema
4.2.1. E-ARK SIP METS Extension
4.2.2. E-ARK CSIP METS Extension
4.3. Appendix C: External Vocabularies
4.3.1. IANA media types
4.3.2. Content information type specification
4.3.3. File group names
4.3.4. Structural map label
4.3.5. Structural map typing
4.3.6. Note type
4.3.7. Content Category
4.3.8. ISO language codes
4.3.9. Alternative record ID's
4.3.10. dmdSec status
4.4. Appendix E: E-ARK CITS-Geospatial Metadata Requirements
4.4.1. E-ARK GEospatial representation METS Profile 1.0 (citsgeospatial_v3_0) Requirements
4.4.2. E-ARK Geospatial root METS Profile 1.0 (citsgeospatial_v3_0) Requirements

1. Context

1.1. Purpose

The purpose of this document is to describe the Content Information Type Specification for Geospatial records (CITS Geospatial). This specification describes how to package files containing geospatial records in a CSIP package(s) and the extension of the E-ARK SIP. It is designed to be used for the transfer of different types of Geospatial records and resources to and from archives.

NOTE: Throughout this document the acronym CSIP will be used to describe the combination of CSIP and SIP.

1.2. Scope

Geospatial records are any digital records that describe an object in space using coordinates based on a geographic coordinate system and a set of descriptive elements called attributes. They are created in many different proprietary formats but mostly come in two forms, vector data (points, lines, polygons) and raster data (sets of one or multiple arrays of pixels).

The CITS Geospatial specification scope describes how geospatial data files, metadata files, schema files for validation, documentation, and other files should be placed and structured into the CSIP based structure when producing a CITS Geospatial SIP for transfer to long-term preservation.

This specification is general enough to support multiple types of geospatial records (not only vector and raster-based records). Therefore, the specification does not define mandatory long-term preservation formats. Instead, it provides a possibility of extensions, the so-called [Long-term preservation format Profiles]{.underline}, that need to comply with general requirements. Examples of such Profiles for vector data (GML) and raster data (GeoTIFF) are provided in the Guideline that accompanies this document. An example of a Profile for GIS in its own guideline which also accompanies this document. Profiles for other geospatial records formats (like proprietary data, earth observations, point clouds, oblique images, web services, etc.) are not proposed at this stage. They will be added later in cooperation with the geospatial community.

Description of the two accompanying guidelines:

• The first accompanying guideline document (Guideline for the specification for the E-ARK Content Information Type Specification for Geospatial data (CITS Geospatial)) provide a basic introduction to the field of geospatial data and the concepts used in this specification. In the Guideline there is also a description of the Profile for using the INSPIRE directive, with the CITS Geospatial both as the content being transferred and how to map INSPIRE information to an archival finding aid.

• The second guideline document (Guideline for using the specification for the E-ARK Content Information Type Specification for Geospatial data (CITS Geospatial) with GIS) provides the information on how to extend the first accompanying guideline document with content describing preservation of selected elements from Geographical Information Systems (GIS). The guideline aims to extend the scope of preservation beyond the geospatial data records themselves and focus more on GIS elements defining the geospatial information products.

A glossary for archival and geodata terms to facilitate the readability of the specification is present at the beginning of this document.

1.3. Information Package Layered data model

This section introduces the role of the CITS Geospatial and its dependencies on basic structures of the Information package.

This specification is created based on the requirements of the Common Specification for Information Packages (CSIP) and the Specification for Submission Information Packages (E-ARK SIP). To fully understand its requirements, we highly recommend that users learn and understand the requirements and the terminology of the initial 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 submission, archiving and dissemination information to the CSIP specification.

The third layer of the model represents specific Content Information Type Specifications (CITS), such as this CITS Geospatial 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 1: 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 very specific local needs. Extension points can be implemented by:

• Embedding foreign extension schemas (in the same way as supported by METS http://www.loc.gov/standards/mets/ and PREMIS http://www.loc.gov/standards/premis/. These support both 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.

2. CITS Geospatial requirements structure

The Content Information Type Specification for Geospatial data aims to define the necessary elements required to preserve the accessibility and authenticity of geospatial records over time and across changing technical environments. To achieve this, this specification defines the categories of significant properties [Source: https://significantproperties.kdl.kcl.ac.uk/ ] for geospatial records to allow the digital geospatial information products to remain accessible and meaningful. For every geospatial record or a set of records, we need to preserve information that suits the following categories:

• Content: Information contained within the Information Object. For example, location information (coordinates, orientation, pixel size), geometry, related feature attributes, etc. This is stored within the Data folder within a Representation.

• Context: Any information that describes the environment in which the content was created or that affects its intended meaning. Examples: Creator name, date of creation, spatial accuracy, source data, sensor information, etc. This type of information can be provided using the Other folder within the main Documentation folder or by providing various Geospatial Metadata located within the Representation Metadata/Descriptive folder.

• Structure: Information that describes the extrinsic or intrinsic relationship between two or more types of content, as required to reconstruct the performance. For example, a Raster object and its connection to the world file, or a vector dataset combined with a table, a GIS project, defining the structure of geodata layers used to create a map, configuration of web services, defining a mash-up WMS, etc. This information should preferably be provided using standardised machine-readable files or at least in written documentation.

• Rendering: Any information that contributes to the recreation of the performance of the Information Object. Example: Colour map of pixel values of a raster; Styled Description layer for web services, documentation describing a cartographic map project, Report designs, etc.

• Behaviour: Properties that indicate the method in which content interacts with other stimuli. Example –rendering algorithms, analysis functionalities, standard transformation processes, documentation of original system functionality, user manuals, training materials, system usage videos, etc.

Figure 2: CITS Geospatial extension folders for Information Packages

2.1. Folder structure requirements

The CITS Geospatial information structure inherited its package structure from the E-ARK Common Specification for Information Packages (CSIP) (blue elements), and it is an extension of it (green elements).

A visualisation of a valid CITS Geospatial Information Package is illustrated in Figure 3. This Figure shows an example of a simple valid Information Package with one representation of a single vector dataset in a GML file format.

Figure 3: Example Information Package folder structure

The folder structure in CSIP described in section https://earkcsip.dilcis.eu/#folderstructureofthecsip is extended with the following geo specific requirements on the folder structure:

GEOSTR1: XML schema documents for any structured descriptive geospatial metadata within package MUST be placed in a sub-folder called schemas within the Information Package root folder and/or the representation folder. This requirement is an extension of CSIPSTR15.

GEOSTR2: A documentation folder on package or representation level SHOULD include a subfolder named structure. This requirement is an extension of CSIPSTR16.

GEOSTR3: A documentation folder on package or representation level SHOULD include a subfolder named rendering. This requirement is an extension of CSIPSTR16.

GEOSTR4: A documentation folder on package or representation level SHOULD include a subfolder named behaviour. This requirement is an extension of CSIPSTR16.

GEOSTR5: A documentation folder on package or representation level SHOULD include a subfolder named CRS. This requirement is an extension of CSIPSTR16.

GEOSTR6: A documentation folder on package or representation level SHOULD include a subfolder named other. This requirement is an extension of CSIPSTR16.

2.2. METS Requirements

2.2.1. Package and Representation METS

Generally, CSIP can consist of zero to many representations, and this is an important feature that needs to be considered when packing geodata files within CSIPs.

There can easily be different representations of the same geospatial content located within one CSIP. For example, one package could consist of:

• one representation with geodata in original format;
• one representation with geodata in a long-term preservation format;
• one representation with geodata in dissemination formats;

There can be several representations of dissemination formats. There can also be many different types of geodata records and databases within the same package.

As for the CITS Geospatial specification, there always needs to be a minimum of one representation and therefore a minimum of two METS.xml. The Package METS.xml must be a general METS.xml stating if the package mainly contains Geospatial Records. Then, the Representation METS.xml describes the specific main data types in the representation.

A CITS Geospatial builds upon the general CSIP requirements, which are presupposed but not explicitly mentioned here. Those requirements should be met before applying the requirements listed below:

2.2.2. Package METS requirements

Requirements pertaining to the information package.

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

<mets:structMap ID="struct-map-example-1" TYPE="PHYSICAL" LABEL="CSIP">
  <mets:div ID="struct-map-example-div" LABEL="csip-mets-example">
    <mets:div ID="struct-map-metadata-div" LABEL="Metadata" ADMID="digiprov-premis-file-1 digiprov-premis-file-2 digiprov-premis-file-3 digiprov-premis-file-4" DMDID="dmd-ead-file">
    </mets:div>
    <mets:div ID="struct-map-schema-div" LABEL="Schemas">
      <mets:fptr FILEID="file-ptr-schema">
      </mets:fptr>
    </mets:div>
    <mets:div ID="struct-map-reps-preing-div" LABEL="Representations/originalformat">
      <mets:mptr LOCTYPE="URL" xlink:type="simple" xlink:href="representations/originalformat/METS.xml" xlink:title="file-grp-rep-ori">
      </mets:mptr>
    </mets:div>
    <mets:div ID="struct-map-reps-sub-div" LABEL="Representations/preservationformat">
      <mets:mptr LOCTYPE="URL" xlink:type="simple" xlink:href="representations/preservationformat/METS.xml" xlink:title="file-grp-rep-pf">
      </mets:mptr>
    </mets:div>
    <mets:div ID="struct-map-reps-ing-div" LABEL="Representations/disseminationformat">
      <mets:mptr LOCTYPE="URL" xlink:type="simple" xlink:href="representations/disseminationformat/METS.xml" xlink:title="file-grp-rep-df">
      </mets:mptr>
    </mets:div>
  </mets:div>
</mets:structMap>

Example: METS root example for Geospatial with file information together with the info from CS IP.

<mets:fileSec ID="filesec-docx-file-1">
  <mets:fileGrp ID="filegrp-representation" USE="Representations" csip:CONTENTINFORMATIONTYPE="citsgeospatial_v3_0">
    <mets:file ID="file-ptr-representation-mets" 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/originalformat/mets.xml">
      </mets:FLocat>
    </mets:file>
  </mets:fileGrp>
</mets:fileSec>

Example: METS example of root METS element for an IP following the CITS Geospatial

<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="geospatial-root-mets-example" TYPE="Geospatial Data" csip:CONTENTINFORMATIONTYPE="citsgeospatial_v3_0" PROFILE="https://citsgeospatial.dilcis.eu/profile/E-ARK-GEOSPATIAL-ROOT.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>

2.2.3. Representation METS requirements

Requirements pertaining to the representation package.

Example: METS example of representation METS element for an IP following the CITS Geospatial

<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="geospatial-root-mets-example" TYPE="Geospatial Data" csip:CONTENTINFORMATIONTYPE="citsgeospatial_v3_0" PROFILE="https://citsgeospatial.dilcis.eu/profile/E-ARK-GEOSPATIAL-REPRESENTATION.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>

2.3. Data requirements (Geospatial data)

This chapter states the requirements for the content data object or objects that form the geospatial record contained in the Information package.

The sections 3.3 – 3.5 of this document do not discuss optimisations with respect to packaging and storage. The requirements for data, metadata and documentation only suggest what information is needed and the appropriate placement of it, not how it is packaged, stored and optimised for automatic handling.

2.3.1. Geodata general - requirements

The general requirements for the content data object or objects are stated in the following table.

2.3.2. Vector Geodata - requirements

Additional to the Geodata general requirements, the following requirements are intended for all vector geodata in the Information package:

2.3.3. Raster Geodata - requirements

Additional to the Geodata general requirements, the following requirements are intended for all raster geospatial records in the Information package:

2.3.4. Non-spatial data - requirements

Geodata is often a part of a complex data structure, stored in a database and ordinary tables. To reproduce the information products from a GIS, it is often necessary to store additional tables with the geospatial records. These tables do not have a geospatial component. In this case, it is essential to store the data structure’s relationships and logic to be reconstructed in the future. For long-term preservation of additional tabular information (attribute tables, code lists, etc.) along with geospatial records, formats proposed for RDBMS archiving are used. For example, the standard SIARD, available at https://dilcis.eu/content-types/siard and used in the Content information Type Specification for Relational Databases using SIARD (CITS SIARD), available at https://dilcis.eu/content-types/cs-siard.

2.3.5. Long Term Preservation Format Profiles

A “Long Term Preservation format Profile” contains a set of one or more base or subsets of base standards, and, where applicable, the identification of chosen clauses, classes, options, and parameters of those base standards, that are necessary for geospatial records to comply with the internal Archival Long Term Preservation guidelines for the selection of long-term preservation formats.

A “Long Term Preservation format Profile” would specify a proposed format for long term specification, its justification according to internal Archival guidelines (to ensure long-term preservation and reuse), a list of required auxiliary files and documentation and validation criteria to ensure structural and content suitability.

2.3.6. Other Geospatial data

This specification does not cover any specific requirements for basic or more complex geospatial records (such as networks, structures combining raster and vector data, point clouds, 3D features, oblique Imagery, Satellite Imagery, etc.). However, the specification will be extended with “Long Term Preservation format Profiles” for additional geospatial formats in the future.

2.4. Documentation requirements

Geospatial records are rarely in a form that is sufficiently self-explanatory to be used and interpreted adequately by itself. Consequently, additional information describing context, structure, rendering and behaviour is required to enable the user to understand, interpret and reuse preserved geodata properly. This chapter describes the requirements for Documentation for geospatial datasets (where it is applicable). Ideally, a standardised machine-readable format is preferred. However, any other form of documentation of the System is always welcome. Standardised machine-readable formats should be placed within the representation. Other documentation should be placed within the package level Documentation folder.

2.4.1. Structure of geospatial records

Structure of geospatial records describe the extrinsic or intrinsic relationships between two or more type of content, as required to reconstruct the performance of one or more geospatial records within the information package.

2.4.2. Rendering and visualisation

Rendering and visualisation documentation represents any information that contributes to the recreation of the performance of the Information Object. Example: Colour map of pixel values in raster datasets, Symbology configuration for vector datasets, Map setup; Web service, etc.

To document visualisation, there is a need for GIS documentation and samples of geospatial information products (maps, lists, charts, new geodata derived from existing data, web services, etc.).

2.4.3. Behaviour - Software and algorithms

To facilitate the reproduction of information products in future System (for example: reconstruct common queries for a specific geospatial dataset), there is often a need to run specific database queries or geo-specific processes. However, some information can only be accessed using functionalities of the original System. Therefore, preserving user manuals and system documentation of original systems is also recommended to preserve the behaviour aspect.

2.4.4. Coordinate reference system information- requirements

Coordinate Reference System (CRS) definition is essential for effective reuse of all geospatial records. When the CRS of the geodata in the Information Package is described by only referencing a well-known external database of CRS definitions (such as the EPSG database), the availability of these definitions is dependent upon the long-term existence of that database. Therefore, a CITS Geospatial Information Package must contain these definitions to be self-descriptive.

2.4.5. Other - Contextual Documentation requirements

This part of the IP describes all remaining, more general information about the geospatial record. Included here are links to relevant documentation describing data creation methodology and the spatial data set’s provenance. The Documentation could consist of interviews, legal origin documentation, related practices in the EU and worldwide, methodological rules, scientific articles, related publications, etc.

2.5. Geospatial Metadata requirements

Geospatial data in the IP is documented using a form of geospatial metadata, which contains common descriptions of the data as well as descriptions specific to the geospatial domain (accuracy, lineage, scale, measurement units, CRS info, etc.). In original systems, geospatial metadata can be stored in different ways (databases, standardised xml files, common documentation, etc.).

3. Glossary

4. Appendices

4.1. Appendix A: E-ARK Information Package METS Examples

4.1.1. Example 1: Example of a whole METS document describing an representation following CITS Geospatial.

<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="geospatial-root-mets-example" TYPE="Geospatial Data" csip:CONTENTINFORMATIONTYPE="citsgeospatial_v3_0" PROFILE="https://citsgeospatial.dilcis.eu/profile/E-ARK-GEOSPATIAL-REPRESENTATION.xml" xsi:schemaLocation="http://www.loc.gov/METS/ http://www.loc.gov/standards/mets/mets.xsd             http://www.w3.org/1999/xlink http://www.loc.gov/standards/mets/xlink.xsd             https://DILCIS.eu/XML/METS/CSIPExtensionMETS              https://earkcsip.dilcis.eu/schema/DILCISExtensionMETS.xsd              https://DILCIS.eu/XML/METS/SIPExtensionMETS              https://earksip.dilcis.eu/schema/DILCISExtensionSIPMETS.xsd">
  <mets:metsHdr CREATEDATE="2018-04-24T14:37:49.602+01:00" LASTMODDATE="2018-04-24T14:37:49.602+01:00" RECORDSTATUS="NEW" csip:OAISPACKAGETYPE="SIP">
    <mets:agent ROLE="CREATOR" TYPE="ORGANIZATION">
      <mets:name>
        Creator
      </mets:name>
      <mets:note csip:NOTETYPE="IDENTIFICATIONCODE">
        ID
      </mets:note>
    </mets:agent>
    <mets:agent ROLE="OTHER" TYPE="INDIVIDUAL" OTHERROLE="SUBMITTER">
      <mets:name>
        Creata Creator
      </mets:name>
      <mets:note>
        Phone: 08-123456, Email: creata.creator@mail.mail
      </mets:note>
    </mets:agent>
    <mets:agent ROLE="ARCHIVIST" TYPE="ORGANIZATION">
      <mets:name>
        The Archives
      </mets:name>
      <mets:note csip:NOTETYPE="IDENTIFICATIONCODE">
        ID
      </mets:note>
    </mets:agent>
    <mets:agent ROLE="PRESERVATION" TYPE="ORGANIZATION">
      <mets:name>
        The Archives
      </mets:name>
      <mets:note csip:NOTETYPE="IDENTIFICATIONCODE">
        ID
      </mets:note>
    </mets:agent>
    <mets:altRecordID TYPE="SUBMISSIONAGREEMENT">
      http://submissionagreement.se/dnr331-1144-2011/20120711/
    </mets:altRecordID>
  </mets:metsHdr>
  <mets:dmdSec ID="dmd1-geospatial" CREATED="2018-04-24T15:27:45.702+01:00" STATUS="CURRENT">
    <mets:mdRef LOCTYPE="URL" xlink:type="simple" xlink:href="metadata/descriptive/ead.xml" MDTYPE="EAD" MIMETYPE="application/xml" SIZE="758" CREATED="2018-04-24T14:37:49.609+01:00" CHECKSUM="31C54EC8D5632B262A62CC3D691A8A6A3DD647670865BE8596D2A7F62DBBC6AB" CHECKSUMTYPE="SHA-256">
    </mets:mdRef>
  </mets:dmdSec>
  <mets:amdSec>
    <mets:digiprovMD ID="appdx1.digiprov-premis-file-1" CREATED="2018-04-24T14:37:52.783+01:00">
      <mets:mdRef LOCTYPE="URL" xlink:type="simple" xlink:href="metadata/preservation/premis1.xml" MDTYPE="PREMIS" MDTYPEVERSION="3.0" MIMETYPE="text/xml" SIZE="1211" CREATED="2018-04-24T14:37:52.783+01:00" CHECKSUM="8aa278038dbad54bbf142e7d72b493e2598a94946ea1304dc82a79c6b4bac3d5" CHECKSUMTYPE="SHA-256" LABEL="premis1.xml">
      </mets:mdRef>
    </mets:digiprovMD>
    <mets:digiprovMD ID="appdx1.digiprov-premis-file-2" CREATED="2018-04-24T14:47:52.783+01:00">
      <mets:mdRef LOCTYPE="URL" xlink:type="simple" xlink:href="metadata/preservation/premis2.xml" MDTYPE="PREMIS" MDTYPEVERSION="3.0" MIMETYPE="text/xml" SIZE="2854" CREATED="2018-04-24T14:37:52.783+01:00" CHECKSUM="d1dfa585dcc9d87268069dc58d5e47956434ec3db4087a75a3885d287f15126f" CHECKSUMTYPE="SHA-256" LABEL="premis2.xml">
      </mets:mdRef>
    </mets:digiprovMD>
    <mets:digiprovMD ID="appdx1.digiprov-premis-file-3" CREATED="2018-04-24T14:37:52.783+01:00">
      <mets:mdRef LOCTYPE="URL" xlink:type="simple" xlink:href="metadata/preservation/premis3.xml" MDTYPE="PREMIS" MDTYPEVERSION="3.0" MIMETYPE="text/xml" SIZE="1211" CREATED="2018-04-24T14:37:52.783+01:00" CHECKSUM="8aa278038dbad54bbf142e7d72b493e2598a94946ea1304dc82a79c6b4bac3d5" CHECKSUMTYPE="SHA-256" LABEL="premis3.xml">
      </mets:mdRef>
    </mets:digiprovMD>
    <mets:digiprovMD ID="appdx1.digiprov-premis-file-4" CREATED="2018-04-24T14:47:52.783+01:00">
      <mets:mdRef LOCTYPE="URL" xlink:type="simple" xlink:href="metadata/preservation/premis4.xml" MDTYPE="PREMIS" MDTYPEVERSION="3.0" MIMETYPE="text/xml" SIZE="2854" CREATED="2018-04-24T14:37:52.783+01:00" CHECKSUM="d1dfa585dcc9d87268069dc58d5e47956434ec3db4087a75a3885d287f15126f" CHECKSUMTYPE="SHA-256" LABEL="premis4.xml">
      </mets:mdRef>
    </mets:digiprovMD>
    <mets:digiprovMD ID="appdx1.digiprov-premis-file-5" CREATED="2018-04-24T14:37:52.783+01:00">
      <mets:mdRef LOCTYPE="URL" xlink:type="simple" xlink:href="metadata/preservation/premis5.xml" MDTYPE="PREMIS" MDTYPEVERSION="3.0" MIMETYPE="text/xml" SIZE="1211" CREATED="2018-04-24T14:37:52.783+01:00" CHECKSUM="8aa278038dbad54bbf142e7d72b493e2598a94946ea1304dc82a79c6b4bac3d5" CHECKSUMTYPE="SHA-256" LABEL="premis5.xml">
      </mets:mdRef>
    </mets:digiprovMD>
    <mets:digiprovMD ID="appdx1.digiprov-premis-file-6" CREATED="2018-04-24T14:47:52.783+01:00">
      <mets:mdRef LOCTYPE="URL" xlink:type="simple" xlink:href="metadata/preservation/premis6.xml" MDTYPE="PREMIS" MDTYPEVERSION="3.0" MIMETYPE="text/xml" SIZE="2854" CREATED="2018-04-24T14:37:52.783+01:00" CHECKSUM="d1dfa585dcc9d87268069dc58d5e47956434ec3db4087a75a3885d287f15126f" CHECKSUMTYPE="SHA-256" LABEL="premis6.xml">
      </mets:mdRef>
    </mets:digiprovMD>
  </mets:amdSec>
  <mets:fileSec ID="filesec-docx-file-1">
    <mets:fileGrp ID="filegrp-documentation" USE="Documentation">
      <mets:file ID="file-ptr-documentation-file1" MIMETYPE="application/vnd.openxmlformats-officedocument.wordprocessingml.document" SIZE="2352367" CREATED="2012-08-15T12:08:15.432+01:00" CHECKSUM="D2DF16632617402BF279D61DBC9F73675E033ABA6B94A78D4B9607CE5CAAFA3E" CHECKSUMTYPE="SHA-256">
        <mets:FLocat LOCTYPE="URL" xlink:type="simple" xlink:href="documentation/File.docx">
        </mets:FLocat>
      </mets:file>
      <mets:file ID="file-ptr-documentation-file2" MIMETYPE="application/vnd.openxmlformats-officedocument.wordprocessingml.document" SIZE="1344782" CREATED="2012-08-15T12:08:15.432+01:00" CHECKSUM="FD7EE6C02AC30570BA8C73E0E8CCDDA77C5428F3E6F6BEA7834F9B1AEB4D8F20" CHECKSUMTYPE="SHA-256">
        <mets:FLocat LOCTYPE="URL" xlink:type="simple" xlink:href="documentation/File2.docx">
        </mets:FLocat>
      </mets:file>
    </mets:fileGrp>
    <mets:fileGrp ID="filegrp-representation" USE="/data/" csip:CONTENTINFORMATIONTYPE="citsgeospatial_v3_0">
      <mets:file ID="file-ptr-representation-file1" MIMETYPE="PDF" SIZE="2314264" CREATED="2018-04-24T14:37:49.617+01:00" CHECKSUM="9EC53E81CDEC19FA665BDDB30ECE11067EF536F3599C67713DCE0FF2FCD81CC7" CHECKSUMTYPE="SHA-256" ADMID="appdx1.digiprov-premis-file-1 appdx1.digiprov-premis-file-2">
        <mets:FLocat LOCTYPE="URL" xlink:type="simple" xlink:href="/data/geo1.pdf">
        </mets:FLocat>
      </mets:file>
      <mets:file ID="file-ptr-representation-file2" MIMETYPE="PDF" SIZE="1385742" CREATED="2018-04-24T15:27:39.617+01:00" CHECKSUM="0EA28B91A3B36D1D90E598301E6F1556B073BAE7DA9C2F242D93D2091D10D426" CHECKSUMTYPE="SHA-256" ADMID="appdx1.digiprov-premis-file-3 appdx1.digiprov-premis-file-4">
        <mets:FLocat LOCTYPE="URL" xlink:type="simple" xlink:href="/data/geo2.pdf">
        </mets:FLocat>
      </mets:file>
      <mets:file ID="file-ptr-representation-file3" MIMETYPE="PDF" SIZE="1341744" CREATED="2018-04-24T14:37:49.617+01:00" CHECKSUM="8FE5B1B292B0CD7741C2CD33221AAA80B6B4EB576D129A2CB5C16D7101CB1C1C" CHECKSUMTYPE="SHA-256" ADMID="appdx1.digiprov-premis-file-5 appdx1.digiprov-premis-file-6">
        <mets:FLocat LOCTYPE="URL" xlink:type="simple" xlink:href="/data/geo3.pdf">
        </mets:FLocat>
      </mets:file>
    </mets:fileGrp>
  </mets:fileSec>
  <mets:structMap ID="struct-map-example-1" TYPE="PHYSICAL" LABEL="CSIP">
    <mets:div ID="struct-map-example-div" LABEL="csip-mets-example">
      <mets:div ID="struct-map-metadata-div" LABEL="Metadata" ADMID="appdx1.digiprov-premis-file-1 appdx1.digiprov-premis-file-2 appdx1.digiprov-premis-file-3 appdx1.digiprov-premis-file-4 appdx1.digiprov-premis-file-5 appdx1.digiprov-premis-file-6" DMDID="dmd1-geospatial">
      </mets:div>
      <mets:div ID="struct-map-doc-div" LABEL="Documentation">
        <mets:fptr FILEID="filegrp-documentation">
        </mets:fptr>
      </mets:div>
      <mets:div ID="struct-map-reps-sub-div" LABEL="Representations">
        <mets:fptr FILEID="filegrp-representation">
        </mets:fptr>
      </mets:div>
    </mets:div>
  </mets:structMap>
</mets:mets>

4.1.2. Example 1: Example of a whole METS document describing an submission information package following CITS Geospatial.

<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="geospatial-root-mets-example" TYPE="Geospatial Data" csip:CONTENTINFORMATIONTYPE="citsgeospatial_v3_0" PROFILE="https://citsgeospatial.dilcis.eu/profile/E-ARK-GEOSPATIAL-ROOT.xml" xsi:schemaLocation="http://www.loc.gov/METS/ http://www.loc.gov/standards/mets/mets.xsd             http://www.w3.org/1999/xlink http://www.loc.gov/standards/mets/xlink.xsd             https://dilcis.eu/XML/METS/CSIPExtensionMETS              https://earkcsip.dilcis.eu/schema/DILCISExtensionMETS.xsd              https://dilcis.eu/XML/METS/SIPExtensionMETS              https://earksip.dilcis.eu/schema/DILCISExtensionSIPMETS.xsd">
  <mets:metsHdr CREATEDATE="2018-04-24T14:37:49.602+01:00" LASTMODDATE="2018-04-24T14:37:49.602+01:00" RECORDSTATUS="NEW" csip:OAISPACKAGETYPE="SIP">
    <mets:agent ROLE="CREATOR" TYPE="ORGANIZATION">
      <mets:name>
        Creator
      </mets:name>
      <mets:note csip:NOTETYPE="IDENTIFICATIONCODE">
        ID
      </mets:note>
    </mets:agent>
    <mets:agent ROLE="OTHER" TYPE="INDIVIDUAL" OTHERROLE="SUBMITTER">
      <mets:name>
        Creata Creator
      </mets:name>
      <mets:note>
        Phone: 08-123456, Email: creata.creator@mail.mail
      </mets:note>
    </mets:agent>
    <mets:agent ROLE="ARCHIVIST" TYPE="ORGANIZATION">
      <mets:name>
        The Archives
      </mets:name>
      <mets:note csip:NOTETYPE="IDENTIFICATIONCODE">
        ID
      </mets:note>
    </mets:agent>
    <mets:agent ROLE="PRESERVATION" TYPE="ORGANIZATION">
      <mets:name>
        The Archives
      </mets:name>
      <mets:note csip:NOTETYPE="IDENTIFICATIONCODE">
        ID
      </mets:note>
    </mets:agent>
    <mets:altRecordID TYPE="SUBMISSIONAGREEMENT">
      http://submissionagreement.se/dnr331-1144-2011/20120711/
    </mets:altRecordID>
    <mets:altRecordID TYPE="PREVIOUSSUBMISSIONAGREEMENT">
      FM 12-2387/12726, 2007-09-19
    </mets:altRecordID>
    <mets:altRecordID TYPE="REFERENCECODE">
      SE/RA/123456/24/P
    </mets:altRecordID>
    <mets:altRecordID TYPE="PREVIOUSREFERENCECODE">
      SE/FM/123/123.1/123.1.3
    </mets:altRecordID>
  </mets:metsHdr>
  <mets:dmdSec ID="dmd-geospatial-file" CREATED="2018-04-24T15:27:45.702+01:00" STATUS="CURRENT">
    <mets:mdRef LOCTYPE="URL" xlink:href="metadata/descriptive/ead.xml" xlink:type="simple" MDTYPE="EAD" MIMETYPE="application/xml" SIZE="643" CREATED="2018-04-24T14:11:29.309+01:00" CHECKSUM="66EEDDF0A22EF57078694B67CA45DF301034556D6CB493531356C4FFE92AB6B1" CHECKSUMTYPE="SHA-256">
    </mets:mdRef>
  </mets:dmdSec>
  <mets:fileSec ID="filesec-docx-file-1">
    <mets:fileGrp ID="filegrp-documentation" USE="Documentation">
      <mets:file ID="file-ptr-documentation-file1" MIMETYPE="application/vnd.openxmlformats-officedocument.wordprocessing.document" SIZE="43445212" CREATED="2012-08-15T12:08:15.432+01:00" CHECKSUM="160D71F56C2CE685CE7FBD679076FD76B3C67EE9AB5062F5EF5C99AE39C1F43B" CHECKSUMTYPE="SHA-256">
        <mets:FLocat LOCTYPE="URL" xlink:type="simple" xlink:href="documentation/File1.docx">
        </mets:FLocat>
      </mets:file>
      <mets:file ID="file-ptr-documentation-file2" MIMETYPE="application/vnd.openxmlformats-officedocument.wordprocessingml.document" SIZE="31462826" CREATED="2012-08-15T14:44:45.432+01:00" CHECKSUM="0FE9683451D0390BCDEF19CE10CFD287A2D944B6A33D246681FEF27F44FFAF1D" CHECKSUMTYPE="SHA-256">
        <mets:FLocat LOCTYPE="URL" xlink:type="simple" xlink:href="documentation/File2.docx">
        </mets:FLocat>
      </mets:file>
    </mets:fileGrp>
    <mets:fileGrp ID="filegrp-schemas" USE="Schemas">
      <mets:file MIMETYPE="application/xml" USE="Package METS" CHECKSUMTYPE="SHA-256" CREATED="2015-12-04T09:59:45" CHECKSUM="B565CA93CD86950503F233A7906E4DB709088BA42B9D109D4A8D6F183799603F" ID="file-ptr-schema2" SIZE="6814">
        <mets:FLocat xlink:href="schemas/METS.xsd" xlink:type="simple" LOCTYPE="URL">
        </mets:FLocat>
      </mets:file>
    </mets:fileGrp>
    <mets:fileGrp ID="filegrp-representation" USE="Representations/submission/data" csip:CONTENTINFORMATIONTYPE="eHEALTH1">
      <mets:file ID="file-ptr-representation-mets" 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/originalformat/mets.xml">
        </mets:FLocat>
      </mets:file>
    </mets:fileGrp>
  </mets:fileSec>
  <mets:structMap ID="struct-map-example-1" TYPE="PHYSICAL" LABEL="CSIP">
    <mets:div ID="struct-map-example-div" LABEL="csip-mets-example">
      <mets:div ID="struct-map-metadata-div" LABEL="Metadata" DMDID="dmd-geospatial-file">
      </mets:div>
      <mets:div ID="struct-map-documentation-div" LABEL="Documentation">
        <mets:fptr FILEID="filegrp-documentation">
        </mets:fptr>
      </mets:div>
      <mets:div ID="struct-map-schema-div" LABEL="Schemas">
        <mets:fptr FILEID="filegrp-schemas">
        </mets:fptr>
      </mets:div>
      <mets:div ID="struct-map-reps-sub-div" LABEL="Representations/originalformat">
        <mets:mptr LOCTYPE="URL" xlink:type="simple" xlink:href="representations/originalformat/METS.xml" xlink:title="file-grp-rep-sub">
        </mets:mptr>
      </mets:div>
    </mets:div>
  </mets:structMap>
</mets:mets>

4.2. Appendix B: External Schema

4.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.

4.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.

4.3. Appendix C: External Vocabularies

4.3.1. IANA media types

Maintained By: IANAs

Location: https://www.iana.org/assignments/media-types/media-types.xhtml

Context: Values for @MIMETYPE

Note: Valid values for the mime types of referenced files.

4.3.2. 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.

4.3.3. File group names

Maintained By: DILCIS Board

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

Context: Values for fileGrp/@USE

Note: Describes the uses of the file group <fileGrp> that are supported by the profile. Own names should be placed in an own extending vocabulary.

4.3.4. Structural map label

Maintained By: DILCIS Board

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

Context: Values for structMap/@LABEL

Note: Describes the label of the structural map that is supported by the profile. Own labels should be placed in an own extending vocabulary.

4.3.5. Structural map typing

Maintained By: DILCIS Board

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

Context: Values for structMap/@TYPE

Note: Describes the type of the structural map <structMap> that is supported by the profile. Own types should be placed in an own extending vocabulary.

4.3.6. Note type

Maintained By: DILCIS Board

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

Context: Used in @csip:NOTETYPE

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

4.3.7. Content Category

Maintained By: DILCIS Board

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

Context: Values for mets/@type

Note: Declares the categorical classification of package content.

4.3.8. ISO language codes

Maintained By: International Standard Organization

Location: http://www.iso.ch/

Context: Languages codes used in documetns using the Simple DC XML Schema

Note: All information recorded within the portion of a conforming METS document defined using the Simple DC XML Schema must be employ ISO 639-2 language codes within the ‘language’ element.

4.3.9. Alternative record ID's

Maintained By: DILCIS Board

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

Context: Used in altrecordID/@TYPE

Note: Describes the type of the alternative record ID.

4.3.10. dmdSec status

Maintained By: DILCIS Board

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

Context: Values for dmdSec/@STATUS

Note: Describes the status of the descriptive metadata section (dmdSec) which is supported by the profile.

4.4. Appendix E: E-ARK CITS-Geospatial Metadata Requirements

4.4.1. E-ARK GEospatial representation METS Profile 1.0 (citsgeospatial_v3_0) Requirements

4.4.2. E-ARK Geospatial root METS Profile 1.0 (citsgeospatial_v3_0) Requirements

Postface

Authors

Reviewers

Project co-funded by the European Commission within the ICT Policy Support Programme

REVISION HISTORY AND STATEMENT OF ORIGINALITY

Submitted Revisions History