METS – Metadata Encoding and Transmission Standard

Last updated
Save as PDF
Share
1. Share
2. Tweet
3. Share

Rosetta uses METS as a container for the IE as an AIP. Further information related to the METS reference model can be found at: http://www.loc.gov/standards/mets/.

For the use of METS as a container for collections, see below.

The METS schema contains three types of metadata: Descriptive, Administrative, and Structural Map.

The following table illustrates which metadata type is applicable to each object type:

	Descriptive	Administrative	Structural Map
IE	√	√
Representation		√	√
File	√	√
Bitstream		√

Descriptive – Information relating to the intellectual contents of the object, akin to much of the content of a standard catalogue record. This enables the user of a digital library to find the object and assess its relevance. Rosetta supports Dublin Core (DC) as the standard for descriptive metadata. The descriptive metadata can be viewed any time the IE is edited or accessed. It can be published or exported to external systems and viewed by external users – as a whole or in parts only, based on the configuration. (Configuration is performed in the Rosetta Administration module.)

The descriptive metadata can be viewed any time the IE is edited or accessed. It can be published or exported to external systems and viewed by external users – as a whole or in parts only, based on the configuration. (Configuration is performed in the Rosetta Administration module.)

The descriptive metadata can be edited by a staff user who uses the Rosetta Web Editor. The edited metadata is written in a new version of the METS file.
Administrative – Information is necessary for the manager of the electronic collection to administer the object, including information on intellectual property rights and technical information on the object and the files or other objects (structural IE relationships) that comprise it.

The administrative metadata is mostly generated by Rosetta throughout the SIP processing, and some of it can be edited by the staff user. (See Rosetta DNX Profile for which metadata can be edited.)
Structural Map – Information on how the individual components that make up the object relate to each other, including the order in which they should be presented to the user – for example, how should still image files that comprise a digitized version of a print volume be ordered. The structural map can be edited in the Web Editor by the staff user, or outside of Rosetta, if the IE is loaded through the submission application.
Note that once the IE is in the permanent repository, it can be edited only in the Web Editor.

METS Sections

A METS file consists of seven major sections, each describing a different facet of the digital object:

Header (metsHdr)

The header section is not in use in Rosetta and is not included in the Rosetta data model.

Descriptive Metadata (dmdSec)

The attributes of the descriptive metadata are:

IE and File level – the descriptive metadata is stored only on the IE and File level
Dublin Core schema – Rosetta uses Dublin Core (DC) and Qualified DC standards, or other schemas that are not hierarchical (such as MODS).
METS section <dmdSec> – Descriptive metadata is held within sections of the METS file named <dmdSec> . Although METS allows this metadata either to be held in external files that are referenced from within the METS file, or to be embedded directly with it, Rosetta requires it to be embedded directly with it for preservation reasons.

The descriptive metadata in Rosetta is embedded directly in the METS file, using an <mdWrap> element to contain it, as illustrated below:

descriptive metadata .png

Administrative Metadata

Administrative metadata includes all the information that is not descriptive for each object that is part of the intellectual entity. It includes technical attributes of the stream files (image resolution, file size, and so forth), access rights for delivery, important events that are relevant for preservation (provenance events), the relationships structure of a structural IE and metadata that arrived with the IE and should be kept in its original structure (not normalized, such as MIX technical metadata for image files).

The administrative elements, each identified by an ID, are used to record this metadata, which may be held in external files or embedded within the METS file using the element. Rosetta uses the DNX format for holding all the technical information, events, and access rights.

Rosetta uses the following sections of METS within the <amdSec>:

technical (mets:techMD) – Holds the technical information of the object, within the <mdWrap>, in DNX format.
rights (mets:rightsMD) – Holds the access rights within the <mdWrap>, in DNX format.
events (mets:digiprovMD) – Holds the provenance events, within the <mdWrap>, in DNX format.
source (mets:sourceMD) – Within the <mdWrap>, there could be any type of source metadata as specified in the Rosetta METS Profile and defined in the Other Source Metadata Subtype code table. Currently, this section holds the details of the DB record of the <amdSec>, such as the record ID, date of creation, and modification date.

For more information regarding the DNX format, see the Rosetta DNX Profile.

Administrative Section for IE, Representation, File, and Bitstream

Each object level (IE, representation, file, and bitstream) has its own <amdSec> that includes the four sub-sections described above (technical, rights, events, and source), even if some of these sections are empty.

As illustrated in the following table, the content of the sections differs between each object level, according to the PREMIS data dictionary:

	techMd	rightsMD	digiProvMd	sourceMD
IE	Identifiers, Control information, Retention policy, Structural IE relationships	Access rights	Provenance events	Source descriptive – MODS, MARC
Representation	Preservation type, usage type, revision no.	Access rights	Provenance events – Add Representation
File	Significant properties, Validation stack outcome	Access rights	Provenance events – Validation Stack	Source technical metadata – MIX, NISO; descriptive – MODS, MARC
Bitstream	Significant properties, Validation stack outcome

The sections that are empty will look like the following:

empty sections according to the PREMIS data dictionary.png

Implementation of PREMIS within METS

As mentioned above, Rosetta implements the PREMIS data model within METS.

In each object level of each METS section, there are DNX sections and fields that match the PREMIS semantic units.

The PREMIS entities are located in the METS sections in the following way:

Objects – As explained above, each object has its own <amdSec> section in which its administrative metadata is specified.
Events – In Rosetta, the events are related to objects. Each object has its relevant events specified in the <amd-digiProv> section, within its <amdSec>.
Agents – In Rosetta, the agents’ elements are represented as attributes of the entity of which they are agents. For example, each event has its agents that are linked to it – user, software, or hardware.
Rights – The Rosetta AIP stored in the METS contains the access rights of the IE, representation, and file. The access rights are stored in the <amd-rights> section within the <amdSec> section on the IE/REP level and these rights are relevant for the delivery of any part of the IE. This is currently an Ex Libris proprietary format. For more information, see Access Rights Within DNX.

For more information about PREMIS implementation in Rosetta DNX format, see Rosetta DNX Profile.

The classification type of an IE, content or structural, is not kept in the METS, but in the database tables. When submitting an IE with the submission application, it is inferred from the existence or nonexistence of representations and files.

File Groups

The <mets:fileSec> section and <mets:fileGrp> sections are applicable only for content IEs. The <mets:fileSec> section includes the <mets:fileGrp> sections in which each section holds the content of a representation (the list of files that are grouped in the representation).

This METS section holds the information about all the files, and some information about the representation.

Representation information:
- USE – The usage of this representation. In Rosetta, it will be View even though METS allows more values, such as Thumbnail or ALTO.
- ID – The unique ID of the representation.
- ADMID – The ID of the administrative section that describes the representation..

File information:
- File ID – The unique ID of the file.
- ADMID – The ID of the administrative section that describes the file.
- GROUPID – Attribute to determine relationship between files within separate Representations.
- MIMETYPE Currently not in use. MIME type is inferred from the file itself and kept in the fileFormat DNX section.
- <mets:FLocat> - The file location element, <FLocat>, provides a pointer to the location of a content file. It uses the XLink reference syntax to provide linking information indicating the actual location of the content file, along with other attributes specifying additional linking information. Only local references are currently supported.

<FLocat> is an empty element. The location of the resource pointed to must be stored in the xlin:href attribute.

The following is an example of a <mets:fileGrp> section within the <mets:fileSec> section:

an example of a mets fileGrp section .png

Structural Map

The Structural Map section <mets:structMap> is applicable only for content IEs. This part of a METS file is a description of the structure of each representation and contains information on how the files relate to each other hierarchically. For example, if the IE is a digitized book, one of its representations will be 150 scanned images of the book’s pages. To show how the pages are structured in chapters, this section will show the divisions by chapters, and for each division there is a label that describes the chapter’s name.

There can be multiple structural maps for each representation if the same files are structured differently (that is, one for chapters and one for content). The example below shows two structural maps for the same representation of three files: One is physical, and the other is logical (where the files are divided in chapters):

strucural map.png

This structural map shows that the representation is referred in the structMap ID (rep1), and each structMap of the same representation has its own identifier (rep1-1, rep1-2). Within these sections are pointers to the files that hold the images of the pages; these are referenced by the FILEID attribute within the <fptr> (file pointer) element.

Each file pointer is wrapped inside a section <mets:div> that contains a label. This label is created when the METS is generated (by Rosetta or by the Rosetta SDK), and it holds the file label that was entered by the Producer Agent when depositing the file. If there is no file label, this label holds the file name.

The structural map provides a logical layout for the structure of the whole object, and one that is easy to navigate using any XML-compatible software. In the Delivery module of Rosetta, the viewer displays the files’ labels according to their order:

labels of files according to their order in the delivery module.png

The following structural map elements are searchable:

Div Element Attributes
Search Index Label	Div Element Attribute
StructMap Div Label	LABEL
StructMap Div ContentIDs	CONTENTIDS
StructMap Div Type	TYPE
StructMap Div Order	ORDER
StructMap Div Order Label	ORDERLABEL
StructMap Div ID	ID
StructMap Div DMD ID	DMDID
StructMap Div ADM ID	ADMID

StructMap Element Attributes
Search Index Label	StructMap Element Attribute
StructMap Label	LABEL
StructMap ID	ID
StructMap Type	TYPE

Structural Links

This section of the METS is not in use in the Rosetta AIP data model.

Behavior

This section of the METS is not in use in the Rosetta AIP data model.

Events

The events metadata holds the information about actions that affect the object. Each object level has different types of actions that should be captured. In Rosetta, the events that are recorded in the AIP are provenance events, while many other events are captured in the system but do not become part of the AIP metadata.

The following types of events are considered provenance events:

New version of the IE – a result of adding a new representation or metadata (descriptive, access rights)
Validation checks – validity and integrity checks on files

Each such event will be written in the events (mets:digiprovMD) section belonging to the relevant object level (IE, representation, or file).

Each event will be written in the DNX format and will include the following:

Agent – The agent that triggered this event. An agent is not necessarily a person. An agent may also refer to a process, plug-in tool, and so forth.
Event details – Such as the creation date, a description, the parameters, and so forth.

The following is an example of an event that is stored in the digiProvMD section of a file. This section holds the events in DNX format:

holding events ins DNX format.png

In addition to events, the digiprovMD section on the IE level stores the details of the Producer and the Producer Agent who deposited the IE.

digiprovMD section.png

Access rights

The Rosetta METS XML can hold two types of access rights information: PREMIS and non-PREMIS:

PREMIS rights – Information regarding an external system that manages the IE’s rights:
- linkingRightsStatementIdentifierType – A designation of the domain within which the linkingRightsStatementIdentifier is unique
- linkingRightsStatementIdentifierValue – The value of the linkingRightsStatementIdentifier
Non PREMIS rights – Information regarding the access rights policy managed by Rosetta:
PolicyID – The unique ID of the different access rights managed by Rosetta. For example: AR_EMBARGOED_FOR_5_YEARS, AR_5_CONCURRENT_USERS
Policy parameters – If the policy requires any parameters
Policy description – Description of the policyID. For example: AR_EMBARGOED_FOR_5_YEARS – Embargoed for 5 years, AR_5_CONCURRENT_USERS – Limited access according to copyright law

METS XML Sections

Declaration	<?xml ... ?>
Attributes	version	"1.0"
Attributes	encoding	"utf-8"
Obligation	Mandatory
Repeatable	No

Elements	<mets>
Attributes	xmlns	"http://www.loc.gov/METS/"
Content	<dmdSec ID="ie-dmd"> <amdSec ID="ie-amd"> <amdSec ID="REP1…n"> <amdSec ID="FL1…n"> <fileSec> <structMap ID=REP1…n TYPE=”[PHYSICAL\|LOGICAL]”>
Obligation	Mandatory
Repeatable	No

Element	<dmdSec>
Description	Descriptive metadata (author, title, and so forth) describing the intellectual entity
Attributes	ID	"ie-dmd"
Content	<mdWrap MDTYPE="DC">
Obligation	Mandatory
Repeatable	No

Element	<mdWrap>>
Description	Container element for DC (Dublin Core) descriptive metadata
Attributes	MDTYPE	"DC"
Content	<xmlData>
Obligation	Mandatory
Repeatable	No

Element	<xmlData>
Content	< dc:record>
Obligation	Mandatory
Repeatable	No

Elements	< dc:record>
Attributes	xmlns:dc	"http://purl.org/dc/elements/1.1/"
Content	All valid DC elements
Obligation	Mandatory
Repeatable	No

Element	<amdSec>
Description	Information is necessary for the manager of the electronic collection to administer the object, including information on intellectual property rights and technical information on the object and the files that comprise it. The administrative metadata is mostly generated by Rosetta throughout the SIP processing, and some of it can be edited by the staff user.
Attributes	ID	"REP1…n-amd"
Content	<techMD>
Obligation	Mandatory
Repeatable	No

Element	<techMD>
Description	Holds the technical information of the object, within the <mdWrap>, in DNX format
Attributes	ID	"REP1…n-amd-tech"
Content	<mdWrap>
Obligation	Mandatory
Repeatable	No

Element	<mdWrap>
Description	Container element for the representation DNX
Attributes	MDTYPE	"OTHER"
Attributes	OTHERMDTYPE	"dnx"
Content	<xmlData>
Obligation	Mandatory
Repeatable	No

Element	<xmlData>
Content	<dnx>
Obligation	Mandatory
Repeatable	No

Element	<dnx>
Attributes	xmlns	"http://www.exlibrisgroup.com/dps/dnx"
Content	DNX Sections (See Appendix B – DNX Profile)
Obligation	Mandatory
Repeatable	No

Element	<rightsMD>
Description	Holds the technical information of the object, within the <mdWrap>, in DNX format
Attributes	ID	"REP1…n-amd-rights"
Content	<mdWrap>
Obligation	Mandatory
Repeatable	No

Element	<mdWrap>
Description	Container element for the representation DNX
Attributes	MDTYPE	"OTHER"
Attributes	OTHERMDTYPE	"dnx"
Content	<xmlData>
Obligation	Mandatory
Repeatable	No

Element	<xmlData>
Content	<dnx>
Obligation	Mandatory
Repeatable	No

Element	<dnx>
Attributes	xmlns	"http://www.exlibrisgroup.com/dps/dnx"
Obligation	Mandatory
Repeatable	No
Note	If there are no access rights on the representation level, the DNX is empty.

Element	<sourceMD>
Description	Holds the source metadata of the object, within the <mdWrap>, in DNX format
Attributes	ID	"REP1…n-amd-source"
Content	<mdWrap>
Obligation	Mandatory if applicable (source MD has been provided with the object)
Repeatable	Yes

Element	<mdWrap>
Description	Container element for the representation DNX
Attributes	MDTYPE	"OTHER"
Attributes	OTHERMDTYPE	"dnx"
Content	<xmlData>
Obligation	Mandatory
Repeatable	No

Element	<xmlData>
Content	<dnx>
Obligation	Mandatory
Repeatable	No

Element	<dnx>
Attributes	xmlns	"http://www.exlibrisgroup.com/dps/dnx"
Content	DNX Sections (See Appendix B - DNX Profile)
Obligation	Mandatory
Repeatable	No

Element	<digiprovMD>
Description	Holds the provenance events information of the object, within the <mdWrap>, in DNX format
Attributes	ID	"REP1…n-amd-digiprov"
Content	<mdWrap>
Obligation	Mandatory
Repeatable	No

Element	<mdWrap>
Description	Container element for the representation DNX
Attributes	MDTYPE	"OTHER"
Attributes	OTHERMDTYPE	"dnx"
Content	<xmlData>
Obligation	Mandatory
Repeatable	No

Element	<xmlData>
Content	<dnx>
Obligation	Mandatory
Repeatable	No

Element	<dnx>
Attributes	xmlns	"http://www.exlibrisgroup.com/dps/dnx"
Content	DNX Sections (See Appendix B - DNX Profile)
Obligation	Mandatory
Repeatable	No

Element	<dmdSec>
Description	Descriptive metadata (author, title, and so forth) describing the file
Attributes	ID	"FL1…n-dmd"
Content	<mdWrap MDTYPE="DC">
Obligation	Optional
Repeatable	No

Element	<amdSec>
Description	Information is necessary for the manager of the electronic collection to administer the object, including information on intellectual property rights and technical information on the object and the files that comprise it. The administrative metadata is mostly generated by Rosetta throughout the SIP processing, and some of it can be edited by the staff user
Attributes	ID	"FL1…n-amd"
Content	<techMD>
Obligation	Mandatory
Repeatable	No

Element	<techMD>
Description	Holds the technical information of the object, within the <mdWrap>, in DNX format
Attributes	ID	"FL1…n-amd-tech"
Content	<mdWrap>
Obligation	Mandatory
Repeatable	No

Element	<mdWrap>
Description	Container element for the representation DNX
Attributes	MDTYPE	"OTHER"
Attributes	OTHERMDTYPE	"dnx"
Content	<xmlData>
Obligation	Mandatory
Repeatable	No

Element	<xmlData>
Content	<dnx>
Obligation	Mandatory
Repeatable	No

Element	<dnx>
Attributes	xmlns	"http://www.exlibrisgroup.com/dps/dnx"
Content	DNX Sections (See Appendix B - DNX Profile)
Obligation	Mandatory
Repeatable	No

Element	<rightsMD>
Description	Holds the rights information of the object, within the <mdWrap>, in DNX format
Attributes	ID	"FL1…n-amd-rights"
Content	<mdWrap>
Obligation	Mandatory
Repeatable	No

Element	<mdWrap>
Description	Container element for the representation DNX
Attributes	MDTYPE	"OTHER"
Attributes	OTHERMDTYPE	"dnx"
Content	<xmlData>
Obligation	Mandatory
Repeatable	No

Element	<xmlData>
Content	<dnx>
Obligation	Mandatory
Repeatable	No

Element	<dnx>
Attributes	xmlns	"http://www.exlibrisgroup.com/dps/dnx"
Obligation	Mandatory
Repeatable	No
Note	If there are no access rights on the file level, the DNX is empty

Element	<sourceMD>
Description	Holds the rights information of the object, within the <mdWrap>, in DNX format
Attributes	ID	"FL1…n-amd-source"
Content	<mdWrap>
Obligation	Mandatory if applicable (source MD has been provided with the object)
Repeatable	Yes

Element	<mdWrap>
Description	Container element for the representation DNX
Attributes	MDTYPE	"OTHER"
Attributes	OTHERMDTYPE	"dnx"
Content	<xmlData>
Obligation	Mandatory
Repeatable	No

Element	<xmlData>
Content	<dnx>
Obligation	Mandatory
Repeatable	No

Element	<dnx>
Attributes	xmlns	"http://www.exlibrisgroup.com/dps/dnx"
Content	DNX Sections (See Appendix B - DNX Profile)
Obligation	Mandatory
Repeatable	No

Element	<digiprovMD>
Description	Holds the provenance events information of the object, within the <mdWrap>, in DNX format
Attributes	ID	"FL1…n-amd-digiprov"
Content	<mdWrap>
Obligation	Mandatory
Repeatable	No

Element	<mdWrap>
Description	Container element for the representation DNX
Attributes	MDTYPE	"OTHER"
Attributes	OTHERMDTYPE	"dnx"
Content	<xmlData>
Obligation	Mandatory
Repeatable	No

Element	<xmlData>
Content	<dnx>
Obligation	Mandatory
Repeatable	No

Element	<dnx>
Attributes	xmlns	"http://www.exlibrisgroup.com/dps/dnx"
Content	DNX Sections (See Appendix B - DNX Profile)
Obligation	Mandatory
Repeatable	No

Element	<amdSec>
Description	Information is necessary for the manager of the electronic collection to administer the object, including information on intellectual property rights and technical information on the object and the files that comprise it. The administrative metadata is mostly generated by Rosetta throughout the SIP processing, and some of it can be edited by the staff user.
Attributes	ID	"ie-amd"
Content	<techMD>
Obligation	Mandatory
Repeatable	No

Element	<techMD>
Description	Holds the technical information of the object, within the <mdWrap>, in DNX format
Attributes	ID	"ie-amd-tech"
Content	<mdWrap>
Obligation	Mandatory
Repeatable	No

Element	<mdWrap>
Description	Container element for the representation DNX
Attributes	MDTYPE	"OTHER"
Attributes	OTHERMDTYPE	"dnx"
Content	<xmlData>
Obligation	Mandatory
Repeatable	No

Element	<xmlData>
Content	<dnx>
Obligation	Mandatory
Repeatable	No

Element	<dnx>
Attributes	xmlns	"http://www.exlibrisgroup.com/dps/dnx"
Content	DNX Sections (See Appendix B - DNX Profile)
Obligation	Mandatory
Repeatable	No

Element	<rightsMD>
Description	Holds the technical information of the object, within the <mdWrap>, in DNX format
Attributes	ID	"ie-amd-rights"
Content	<mdWrap>
Obligation	Mandatory
Repeatable	No

Element	<mdWrap>
Description	Container element for the representation DNX
Attributes	MDTYPE	"OTHER"
Attributes	OTHERMDTYPE	"dnx"
Content	<xmlData>
Obligation	Mandatory
Repeatable	No

Element	<xmlData>
Content	<dnx>
Obligation	Mandatory
Repeatable	No

Element	<dnx>
Attributes	xmlns	"http://www.exlibrisgroup.com/dps/dnx"
Content	DNX Sections (See Appendix B - DNX Profile)
Obligation	Mandatory
Repeatable	No

Element	<sourceMD>
Description	Holds the technical information of the object, within the <mdWrap>, in DNX format
Attributes	ID	"ie-amd-source[-source type][-1…n]"
Content	<mdWrap>
Obligation	Mandatory if applicable (source MD has been provided with the object)
Repeatable	Yes
Note	ie-amd-source is reserved for DNX metadata. Other supported sourceMD types (specified in the Rosetta METS Profile) must be identified using the source type, for example, ie-amd-source-mods.

Element	<mdWrap>
Description	Container element for the representation DNX
Attributes	MDTYPE	"OTHER"
Attributes	OTHERMDTYPE	"dnx"
Content	<xmlData>
Obligation	Mandatory
Repeatable	No

Element	<xmlData>
Content	<dnx>
Obligation	Mandatory
Repeatable	No

Element	<dnx>
Attributes	xmlns	"http://www.exlibrisgroup.com/dps/dnx"
Content	DNX Sections (See Appendix B - DNX Profile)
Obligation	Mandatory
Repeatable	No

Element	<digiprovMD>
Description	Holds the provenance events information of the object, within the <mdWrap>, in DNX format
Attributes	ID	"ie-amd-digiprov"
Content	<mdWrap>
Obligation	Mandatory
Repeatable	No

Element	<mdWrap>
Description	Container element for the representation DNX
Attributes	MDTYPE	"OTHER"
Attributes	OTHERMDTYPE	"dnx"
Content	<xmlData>
Obligation	Mandatory
Repeatable	No

Element	<xmlData>
Content	<dnx>
Obligation	Mandatory
Repeatable	No

Element	<dnx>
Attributes	xmlns	"http://www.exlibrisgroup.com/dps/dnx"
Content	DNX Sections (See Appendix B - DNX Profile)
Obligation	Mandatory
Repeatable	No

Element	<fileSec>
Description	Inventory of all of the files that make up the digital representation of work.
Content	<fileGrp>
Obligation	Mandatory
Mandatory	No

Element	<fileGrp>
Description	Container for all of the files of a given representation.
Content	<file>
	USE	The usage of this representation. Currently not in use. Rosetta regards all file groups USE as used for viewing.
	ID	“REP1...n”
	ADMID	“REP1...n-amd”
Obligation	Mandatory
Repeatable	Yes
Note	If there is more than one <fileGrp> element, no specific order is required.

Element	<file>
Description	Properties of a file that provides a representation of a single page of work
Attributes	ID	"FL1...n"
	MIMETYPE	Currently not in use. MIME type is inferred from the file itself and kept in the fileFormat DNX section:
	ADMID	“FL1...n-amd”
	GROUPID	String
Content	<FLocat>
Obligation	Mandatory
Repeatable	Yes

Element	<FLocat>
Attributes	LOCTYPE	“URL”
	xlin:href	“file://” + File Name
	xmlns:xlin	"http://www.w3.org/1999/xlink"
Content
Obligation
Repeatable	Yes

Element	<structMap>
Description	Logical/physical organization of the files within the representation
Attributes	ID	"REP1…n-N"
Attributes	TYPE	"PHYSICAL" or "LOGICAL"
Content	e.g. <div LABEL="PRESERVATION_MASTER">
Obligation	Mandatory
Repeatable	Yes

Element	<div>
Attributes	LABEL	PRESERVATION_MASTER;VIEW
Content	<div LABEL="Table of Contents">
Obligation	Mandatory
Mandatory	No

Element	<div>
Description	A logical section of work
Attributes	LABEL	Table Of Content
Content	<div LABEL="Table of Contents">
Obligation	Mandatory
Mandatory	Yes

Element	<div>
Description	A single page of work
Attributes	LABEL	Free text. Label may remain empty
Attributes	TYPE	“FILE”
Content	<fptr>
Obligation	Mandatory
Mandatory	Yes

Element	<fptr>
Description	Pointer to a certain file within the Structural Map
Attributes	FILEIDFILEID	PID of the file
Obligation	Mandatory
Repeatable	No

Collections in METS

Collections are managed in the operational repository in a dedicated table (called Collection). In the permanent repository each Collection record is contained in a METS file that is different than the IE METS.

The METS file includes the following sections:

mets:dmdSec ID=”collection-dmd”	Descriptive metadata in DC
DC	The descriptive metadata in DC format
mets:amdSec ID=”collection-amd”	Administrative metadata section
mets:techMD ID=”collection-amd-tech”	Technical metadata sub-section
collection	DNX section that includes the collection’s identifiers
objectCharacteristics	DNX section that includes the control information of the Collection
objectIdentifier	DNX section that can hold DOI
mets:sourceMD ID="collection-amd-source"	Source matadata of the Collection (repeatable section)
DC/MARC/MODS	Descriptive metadata in any format

An example for a Collection stored in METS is as follows:

An example for a Collection stored in METS.png

An example for a Collection stored in METS (2).png

The METS file is written to the permanent repository every time it is changed in the UI. The UI shows the last version of the METS.