Workbook on Digital Private Papers > Administrative and preservation metadata > Using METS for the preservation and dissemination of digital archives

Using METS for the preservation and dissemination of digital archives

Structure of a METS file

While the METS schema is very flexible, it is also tightly structured. A METS document is comprised of seven principal sections:

  1. METS Header <metsHdr> Contains brief descriptive information about the METS document itself, including date of creation and last modification, current status, names of the agents who have played some role in relation to the document, and the nature of that role.
  2. Descriptive Metadata Section <dmdSec> Contains descriptive metadata, supplying information on the intellectual content of an object which is necessary for users to find an item and assess its value for their research. It may contain the metadata itself, or point to metadata held outside the METS document. Multiple instances of both external and internal descriptive metadata may be included. For external metadata the <mdRef> element allows the provision of a URI for that metadata.
  3. Administrative Metadata Section <amdSec> Contains technical information about the digital object, rights management information and provenance information. It is divided into four main sections: technical metadata (re. file creation, format and use characteristics); IPR metadata (re. copyright, licensing etc); source metadata (re. the analogue source from which a digital object derives, where relevant); digital provenance metadata (re. source of files, relationships between files, information about any migration or other preservation activities undertaken).
  4. File Section <fileSec> A list of the file(s) that make up the digital object. Each is given an ID and its physical location is indicated. The files can be grouped within FileGrp elements, to provide for subdividing the files by object version or other criteria, e.g. file type, size, structure.
  5. Structural Map <structMap> This is the heart of a METS document and is the only mandatory section. It indicates, by means of a hierarchical structure, how the various components of the digital object (if more than one) relate to each other, and facilitates navigation by the end user. It also includes links to the relevant content files and the metadata relating to each content file.
  6. Structural Link Section <structLink> This section contains only one (repeatable) element, , which facilitates hyperlinks between items within the structural map. This is a useful facility when using METS to present websites or other hypermedia.
  7. Behaviour Section <behaviorSec> Provides information on how particular components of the digital object should be rendered for the user. This may include information on specific software packages to be used, or on particular parameters to be used when rendering a file.

The descriptive and administrative metadata sections, the file section, and the structural map, can all be allocated unique identifiers; by means of the IDREF mechanism, these IDs can be used to link all of these sections together.

This overview will take each section in order, although the METS Primer and Reference Manual recommends starting with the file section, followed by the structural map, when creating a METS document.

In the examples below, a single email is used as an example content file. For the purposes of long-term preservation and packaging, each digital object within the Paradigm testbed (like this email) will have its own METS document, which links to other METS documents describing the preservation agents, events and rights associated with the digital object. The purpose of these METS documents is to facilitate long-term preservation and to create a self-describing Information Package (AIP), rather than to facilitate navigation and user access. In order to facilitate access (via the DIP), Paradigm proposes using a higher level METS document which, by means of its structural map, will be used to organise lower-level METS documents to provide different methods of access for the user. Some examples of alternative ways of using the structural map are also included here. None of these examples reflect definitive Paradigm practice; they are merely offered as possible models of working.