**Guidance for using PREMIS with METS**

**March 5, 2008**

This document offers guidance for common practices when using PREMIS
schemas as METS extensions. Some judgment is needed in considering the
uses for the METS document. Providing a METS document as an exchange
object for display and delivery may require different decisions than as
an object of preservation. When using METS as a submission information
package (SIP) a more liberal approach may be warranted, since systems
may generate needed data elements, while using it as a dissemination
package may require a more restrictive approach and more authoritative
metadata.

**Background: PREMIS and METS schemas**

PREMIS is implemented in XML schema as 5 separate schemas that reflect
the PREMIS data model.

*Object.xsd* includes data elements contained in the PREMIS Data
Dictionary under the Object entity. Object aggregates information about
a digital object held by a preservation repository and describes those
characteristics relevant to preservation management. Those
characteristics are properties of the object, which can be at the level
of a representation (set of files needed to provide a complete and
accurate rendition of an intellectual entity), file, or bitstream.

*Event.xsd* includes data elements contained in the PREMIS Data
Dictionary under the Event entity. Event aggregates information about an
action that involves one or more Objects.

*Agent.xsd* includes data elements contained in the PREMIS Data
Dictionary under the Agent entity. Agent aggregates information about
attributes or characteristics of agents (persons, organizations,
software) associated with rights management and preservation events in
the life of an data object.

*Rights.xsd* includes data elements that are related to statements of
rights and permissions. Rights are entitlements allowed to agents by
copyright or intellectual property law. Permissions are powers or
privileges granted by copyright between a rightsholder and another party
or parties.

*PREMIS.xsd* is a container that may be used to keep all PREMIS metadata
together, and references each of the 4 separate schemas described above.

The METS schema specifies an administrative metadata section (*amdSec*)
with the following subelements:

techMD

rightsMD

sourceMD

digiProvMD

# Guidelines for using PREMIS with METS

**1. Using PREMIS in METS sections**

If not keeping all PREMIS metadata together, information from each
schema should be used in the METS sections as follows.

*Object.xsd* under techMD or digiProvMD

Object schema metadata for file and bitstream levels should be in techMD
if separating between METS sections. Implementations may wish to include
information about representations in the object schema under digiProvMD,
but this is a local decision which may depend on the processing model
used. Number range CHAPTERThe important consideration is that the
structMap and fileSec allow the user to understand what files are being
referenced and what metadata apply to them. (see also below under
linking).

*Event.xsd* under digiProvMD

*Rights.xsd* under rightsMD

*Agent.xsd* under either digiProvMD (if given in the context of an
event) or rightsMD (if given in the context of a rights statement).

If using all PREMIS units together (with the premis root element) the
entire package goes in digiProvMD.

**2. Number of sections to use**

Use of one Number range CHAPTERamdSec with repeating subelements
(techMD, etc.) or repeating amdSec for each METS subelement is an
implementer's preference. These are semantically equivalent provided
that the sections are referenced appropriately within the METS document
from the fileSec. If referencing the amdSec, you are also referencing
the children (i.e. it is a shortcut to referencing all the children).
Thus, it is not mandated whether or not to repeat amdSec.

If using Agent.xsd in conjunction with an event or right, it should be
given in its own digiProv or rightsMD section because that minimizes the
redundancy (since the same agent may be involved in various events and
rights statements). Technical metadata from different schemas (one of
which is from PREMIS) should be given in separate techMD sections,
although in version 2.0 of PREMIS the format specific metadata may be
included as part of the PREMIS metadata under
additionalTechnicalCharacteristics in the premis:object schema.

**3. Use of PREMIS container**

If separating PREMIS metadata between METS administrative sections with
subelements, do not use the PREMIS container. If an implementation wants
to keep all PREMIS metadata together the PREMIS container is used and
the PREMIS package is in digiProvMD.

**4. Redundancies between PREMIS and METS**

Redundancies may occur when a format specific technical metadata schema
(such as MIX for digital still images) includes data elements that are
also in PREMIS. In METS the data from the format specific schema is used
in a separate techMD section with the metadata type indicated using the
MDTYPE or OTHERMDTYPE attribute. (Note that format specific metadata may
also occur in PREMIS version 2.0 under additionalObjectCharacteristics,
which can contain data from external technical metadata schemas.) There
are also redundancies when elements are defined both as PREMIS semantic
units and in the METS schema (generally as attributes). Examples are:

SIZE: in PREMIS included in \<size\> under \<objectCharacteristics\>; in
METS as an attribute of \<file\> in the \<fileGrp\>

CHECKSUM and CHECKUMTYPE: in PREMIS included in \<fixity\> under
\<objectCharacteristics\>; in METS as attributes of \<file\>

MIMETYPE: in PREMIS included in \<format\> under
\<objectCharacteristics\> in METS as an attribute of \<file\>.

An application may decide whether it is easier to include the
information redundantly, based on how the data will be used and/or
supplied. Implementers should consider the use of the data (e.g. display
or preservation) and whether the PREMIS or the METS metadata is primary
when deciding which to use and whether to record redundantly. Keeping
metadata in sync when recorded redundantly is an implementation question
and could be addressed in a profile.

**5. METS structMap and PREMIS structural relationship elements**

Hierarchical structural relationships should be detailed as nested div
elements according to the METS schema and rules because it is richer
than that provided as PREMIS semantic units. If the scope of exchange
objects is preservation, implementers are encouraged to also use the
PREMIS relationship elements in the Object schema for structural
relationships. PREMIS relationship elements should always be used for
derivative types of relationships.

**6. METS ID/IDREF and PREMIS identifier elements**

There are several ways to make linkages between elements using PREMIS
and METS. There are separate data elements in PREMIS for identifiers
(objectIdentifier, eventIdentifier, agentIdentifier, and
permissionStatementIdentifier and linking identifiers). In addition,
ID/IDREF constructs have been provided in the PREMIS schemas that
provide linkages between PREMIS related elements (RelObjectXmlID,
LinkEventXmlID, LinkPermissionStatementXmlID, RelEventXmlID,
linkingObjectXmlID, LinkAgentXmlID, GrantAgentXmlID). METS also provides
ID/IDrefs that link between files and their related metadata in the
appropriate sections.

Implementers need to rely on METS ID/IDRefs when referencing a METS
section (e.g. techMD) from a file in the fileSec. Linkages between
metadata in different PREMIS schemas will also use the METS ID/IDref
constructs rather than the PREMIS ID/IDRefs. Implementers are encouraged
to include the explicit PREMIS linking identifier elements in case the
PREMIS metadata is used as a whole outside of the METS document.

When establishing the values of METS IDs, it is important that
implementers create appropriate IDs by assuring that they are unique
within the instance, maintain their persistence, and that everything is
referenced that needs to be.

There should not be any orphaned elements, e.g. a techMD that isn't
referenced in the structMap/fileSec. Any sections with PREMIS elements
should be referenced; orphaned elements will be ignored.

**7. Use of METS profiles**

Implementations are encouraged to establish profiles that specify
options chosen where this document is not prescriptive and, where there
are redundancies, state whether elements in PREMIS or METS are primary.
Profiles may also suggest policy for resolving conflicts between
metadata included redundantly using both PREMIS and METS elements or
PREMIS and format-specific elements.

A generic METS profile incorporating PREMIS schemas as METS extension
schemas is provided and may be used if desired as a basis for particular
applications. (Jenn has agreed to draft this.)

The following individuals participated in the development of these
guidelines:

Rebecca Guenther, Library of Congress (PREMIS Editorial committee chair)

Rob Wolfe, MIT (METS liaison)

Olaf Brandt, Royal Library of the Netherlands

Markus Enders, British Library

Tom Habing, University of Illinois Urbana/Champaign

Francesco Lazzarino, Florida Center for Library Automation

Clay Redding, Library of Congress

Jenn Riley, Indiana University