Schema Documentation {http://www.loc.gov/METS/}

METS: Metadata Encoding and Transmission Standard.
METS is intended to provide a standardized XML format for transmission of complex digital library objects between systems. As such, it can be seen as filling a role similar to that defined for the Submission Information Package (SIP), Archival Information Package (AIP) and Dissemination Information Package (DIP) in the Reference Model for an Open Archival Information System.

metsHdr: METS Header.
Like a TEI Header, the METS Header element records metadata about the METS document itself (not the digital library object that the METS document encodes). It has two possible subsidiary elements, agent (document agent) and altRecordID (alternative Record ID)..

agent: METS agent.
The agent element allows for various parties and their roles with respect to the METS document to be recorded.

name:The full name of the METS document agent.

note: Any additional information regarding the agent's activities with respect to the METS document.

altRecordID: Alternative Record ID.
This element allows for documentation of alternative ID values for the METS document in addition to the primary ID stored in the OBJID attribute in the root METS element.

dmdSec: Description Metadata Section.
This section records all of the descriptive metadata for all items in the METS object (including both structural map divs and descriptive metadata for data files). Metadata can be either included in the METS hub document (mdWrap) or referenced via an identifier/locator (mdRef), a la Warwick Framework. Multiple dmdSec elements are allowed so that descriptive metadata can be recorded for each separate item within the METS object.

amdSec: Administrative Metadata Section.
This section records all of the administrative metadata for all items in the METS object (including structural map divs, data files, descriptive metadata sections and adminstrative metadata sections themselves), and is divided into four subsections: techMD (technical metadata), rightsMD (intellectual property rights metadata), sourceMD (analog/digital source metadata), and digiprovMD (digital provenance metadata). Each of these subsections follows the mdSecType model, so that they can either include metadata within the METS hub document (mdWrap) or reference it via an identifier/locator (mdRef). Multiple techMD, rightsMD, sourceMD and digiprovMD elements are allowed so that administrative metadata can be recorded for each separate item within the METS object.

fileSec: Content File Section.
The content file section records information regarding all of the data files which comprise the digital library object.

fileGrp: File Group
This element allows for the grouping of content files into sets (all of the master images for a work, all of the images for a particular page, etc.).

structMap: Structural Map.
The structural map is the heart of a METS document, defining the hierarchical arrangement of a primary source document which has been digitized. This hierarchy is encoded as a tree of 'div' elements. Any given 'div' can point to another METS document via the 'mptr' element, or to a single file, to a group of files, or to segments of individual files or groups of files through the 'fptr' and subsidiary elements.

structLink: Structural Map Linking.
The Structural Map Linking section allows for the specification of hyperlinks between different components of a METS structure delineated in a structural map.

behaviorSec: Behavior Section. This section records executable behaviors that are associated with content in the METS object.

techMD: technical metadata.
The techMD element provides a wrapper around a generic metadata section, which should contain technical metadata regarding a file or files.

rightsMD: intellectual property rights metadata.
The rightsMD element provides a wrapper around a generic metadata section, which should contain IP rights metadata.

sourceMD: source metadata.
The sourceMD element provides a wrapper around a generic metadata section which should contain descriptive or administrative metadata regarding the original source materials used to create the METS object.

digiprovMD: digital provenance metadata.
The digiprovMD element provides a wrapper around a generic metadata section, which should contain information regarding the ultimate origin of a digital object and the derivation of its current elements. This includes recording master/derivative relationships between various files which currently represent the object, as well recording any transformations or migrations undergone by files composing the digital object subsequent to the initial digitization of an item or, in the case of born digital materials, the files' creation. In short, digiprovMD should be used to record information to allow both archival/library staff and scholars to understand what modifications have been performed to a digital object during its life cycle in order to judge how those processes might have altered or corrupted the object's ability to accurately represent the original item.

div: Division.
The METS standard represents a document structurally as a series of nested div elements, that is, as a hierarchy (e.g., a book, which is composed of chapters, which are composed of subchapters, which are composed of text). Every div node in the structural map hierarchy may be connected (via subsidiary mptr or fptr elements) to content files which represent that div's portion of the whole document.

mptr: METS Pointer.
The mptr element allows a div to be associated with a separate METS document containing the content corresponding with that div, rather than pointing to an internal file or file group. A typical instance of this would be the case of a METS document for a journal run, with a div elements for each individual journal issue. The div elements for the issues might point to separate METS documents for each issue, rather than having files and file groups for every issue encoded in one document.
NOTE: mptr is an empty element. The location of the resource pointed to MUST be stored in the xlink:href attribute.

fptr: File Pointer.
The fptr element associates a div element with content files that represent that div. It can either point to a file directly itself, via the FILEID attribute, or it can do more complex links to content via the subsidiary area, par and seq elements.

par: Parallel files.
The par element should used to link a div to a set of content files when those files should be played/displayed in unison to deliver the content to the user (e.g., displaying a text transcript simultaneously with playing an audio file). A par element has two possible subsidiary elements, which should be used in different cases. In cases where each bytestream to be played in parallel can fit in a single file, you should use subsidiary <area> elements within the par element to point to those files. However, in some cases, bytestreams which should be played in parallel are too large to fit in a single file (high quality multi-track audio, or video). In those cases, you should use subsidiary <seq> elements, where each <seq> contains the files comprising a particular bytestream in the order they should be played back. So, for example, in the case where you had an audio recording which had to be split into three different, sequential files, and a text transcription of the recording in a single file, you would use a par element containing two seq elements. The first seq element would contain three area elements, one for each audio file; the second seq element would contain a single area element, for the text transcription file.

seq: Sequence of files.
The seq element should be used to link a div to a set of content files when those files should be played/displayed sequentially to deliver content to a user. See the seqType documentation for more details.

area: file area
The area element provides for more sophisticated linking between a div element and content files representing that div, be they text, image, audio, or video files. An area element can link a div to a point within a file, to a one-dimension segment of a file (e.g., text screen, image line, audio/video clip), or a two-dimensional section of a file (e.g, subsection of an image, or a subsection of the video display of a video file. See the areaType documentation for more details.

smLink: structural map Link
An element linking two elements in the structural map, used to indicate that a hyperlink exists between the two METS components represented by the two structural map nodes. You would use smLink, for example, to record the existence of hypertext links between web pages, if you wish to record those links' existence inside of METS.

interfaceDef: interface definition object.
The interface definition element contains a pointer an abstract definition of a set of related behaviors. These abstract behaviors can be associated with the content of a METS object. The interface definition element will be a pointer to another object (an interface definition object). An interface definition object could be another METS object, or some other entity (e.g., a WSDL file). Ideally, an interface definition object should contain metadata that describes a set of behaviors or methods. It may also contain files that describe the intended usage of the behaviors, and possibly files that represent different expressions of the interface definition. The interfaceDef element is optional to allow for cases where an interface definition can be obtained from a behavior mechanism object (see the mechanism element of the behaviorSec).

mechanism: executable mechanism.
A mechanism element contains a pointer to an executable code module that implements a set of behaviors defined by an interface definition. The mechanism element will be a pointer to another object (a mechanism object). A mechanism object could be another METS object, or some other entity (e.g., a WSDL file). A mechanism object should contain executable code, pointers to executable code, or specifications for binding to network services (e.g., web services).

mdRef: metadata reference.
The mdRef element is a generic element used throughout the METS schema to provide a pointer to metadata which resides outside the METS document. NB: mdRef is an empty element. The location of the metadata must be recorded in the xlink:href attribute, supplemented by the XPTR attribute as needed.

mdWrap: metadata wrapper.
The mdWrap element is a generic element used throughout the METS schema to allow the encoder to place arbitrary metadata conforming to other standards/schema within a METS document. The included metadata can either be encoded in XML, in which case it may be placed directly within the mdWrap element, or it can be Base64 encoded, and placed within a subsidiary binData element.

binData:
A wrapper element to contain Base64 encoded metadata.

xmlData:
A wrapper element to contain XML encoded metadata.

FLocat: File Location.
The FLocat element provides a pointer to the location of a content file. It uses the XLink syntax to provide linking information indicating the actual location of the content file, along with a few additional attributes specifying additional linking information.
NOTE: FLocat is an empty element. The location of the resource pointed to MUST be stored in the xlink:href element.

FContent: file content.
The FContent element is used to deliver a content file for a METS document within the METS file itself. The content file must be either Base 64 encoded, and contained within the subsidiary binData wrapper element, or consist of XML information and be contained within the subsidiary xmlData wrapper element.

binData: A wrapper element used to contain a Base64 encoded file.

xmlData: A wrapper element used to contain an XML encoded file.

stream: component byte stream
A file may be composed of one or more subsidiary streams. An MPEG4 file, for example, might contain separate audio and video streams, each of which has its own technical metadata associated with it.