Writing in the Sand Metadata Encoding and Transmission Standard (METS) in Digital Libraries

The Metadata Encoding and Transmission Standard (METS) was initially developed for the Digital Library Federation by Jerome McDonough. Complicated digital objects such as books require structural metadata in order to relate the pages and chapters to one another, as well as to the whole. Technical metadata is needed to inform scholars of how accurate a representation the digital object is, and also to enable the library to periodically refresh and migrate the data to ensure durability. In addition, a standardized schema that encompassed all the preservation and use needs of the digital object was desirable for sharability, particularly within the proposed Open Archival Information System (OAIS) Reference Model.

A METS document consists of seven major sections: [1]

  1. The METS Header contains metadata describing the METS document itself, including such information as creator, editor, etc.

  2. The Descriptive Metadata section may point to descriptive metadata external to the METS document (e.g., a MARC record in an OPAC or an EAD finding aid maintained on a WWW server), or contain internally embedded descriptive metadata, or both. Multiple instances of both external and internal descriptive metadata may be included in the descriptive metadata section.

  3. The Administrative Metadata section provides information regarding how the files were created and stored, intellectual property rights, metadata regarding the original source object from which the digital library object derives, and information regarding the provenance of the files comprising the digital library object (i.e., master/derivative file relationships, and migration/transformation information). As with descriptive metadata, administrative metadata may be either external to the METS document, or encoded internally.

  4. The File Section lists all files containing content which comprise the electronic versions of the digital object. <file> elements may be grouped within <fileGrp> elements, to provide for subdividing the files by object version.

  5. The Structural Map is the heart of a METS document. It outlines a hierarchical structure for the digital library object, and links the elements of that structure to content files and metadata that pertain to each element.

  6. Structural Links section of METS allows METS creators to record the existence of hyperlinks between nodes in the hierarchy outlined in the Structural Map. This is of particular value in using METS to archive Websites.

  7. The Behavior section can be used to associate executable behaviors with content in the METS object. Each behavior within a behavior section has an interface definition element that represents an abstract definition of the set of behaviors represented by a particular behavior section. Each behavior also has a mechanism element which identifies a module of executable code that implements and runs the behaviors defined abstractly by the interface definition.

Here is a sample METS file, developed by Melanie Feltner-Reichert, the extended version of which can be viewed in display software here. As you can see, this small sample file has 3 levels of hierarchy; beneath the top level (title) are the pages, and within those pages sometimes there are separate images displayed. It is possible with METS to have separate metadata for each child object, and linking between the different levels. Display of METS in any software normally includes a navigation bar such as this on the left side, to assist the user in comprehending where they are in the book (or other object). And most such software enables page-turning, as this one does.

If you look through the metadata file itself, you will see that the METS Header (mets:metsHdr) section contains Melanie's name, as the creator. The Descriptive Metadata section (mets:dmdSec) contains several Dublin Core records; any form of descriptive metadata can be enclosed here, though the approved ones currently include Dublin Core, MODS, and MARC XML. The separate metadata for each child object (or the object as a whole) is delineated by using the ID attribute to relate the enclosed metadata record to the reference number for that object. For example, the metadata record within <mets:dmdSec ID="rms04v01"> applies to page 4 verso, image 1.

The File Section (mets:fileSec) contains file groups (mets:fileGrp) to indicate the usage for the enclosed file reference; in this case, we have thumbnail and reference uses. Information about each file is here, such as its sequence of use, its MIME (Multipurpose Internet Mail Extension) type, the DMDID used to link it to its descriptive metadata, and its physical location (using mets:FLocat xlink values).

The Structural Map is within the mets:structMap section, where the ordering for display is located, including the hierarchical structure. You will see, for example, that the 6th item for display at the level below title is page 4v (verso), and that it contains two images, with order of display 1 and 2:

<mets:div ORDER="6" TYPE="entry" LABEL="Page 4v">
<mets:fptr FILEID="FID6a"/>
<mets:fptr FILEID="FID6b"/>
<mets:div ORDER="1" TYPE="entry" LABEL="Page 4v | Image 1">
<mets:fptr FILEID="FID7a"/>
<mets:fptr FILEID="FID7b"/>
<mets:div>
<mets:div ORDER="2" TYPE="entry" LABEL="Page 4v | Image 2">
<mets:fptr FILEID="FID8a"/>
<mets:fptr FILEID="FID8b"/>
</mets:div>
</mets:div>

If you look back at the File Section, you will see the FILEID FID7a listed as within the filegroup thumbnail, and FID7b listed as within the filegroup "reference". These are the thumbnail and large sized images. The Structural Links and Behavior sections were not used in this sample, and are indeed optional. METS records can be incredibly complex. In order to provide standardization for interoperability, each METS implementer is urged to register the profile of METS that they are using.

METS is also designed for transmission of digital objects, though it is rarely used this way currently due to the size of the objects and network bandwidth restrictions. To enclose the digital object, it is Base64 encoded and wrapped in <binData> elements. Transmission of the metadata within the <mdWrap> section in this manner is also supported.

Important links from above:

Recommended listserv: METS.

Display software used is modified DLXS (Digital Library Extension Service).

Girl writing in the sand

This information is provided without guarantees as to validity or completeness, particularly in light of the fact that the world of metadata in digital libraries is a world of shifting sands, constantly changing.