METS version 1 Profile Components

A METS profile consists of the following elements:

• A URI which is assigned to the profile document either by the creating institution or by the METS Editorial Board once a profile has been accepted for registration. Either of these URIs can then be referenced in the PROFILE attribute of the root element of any METS instance document that conforms to the profile.
• A short title for the class of profiled METS documents (e.g., NYU Monograph, Video with Closed Captioning, etc.);
• An abstract, providing a one-paragraph description of the profile's nature and purpose;
• A date and time specifying when the profile was created;
• Contact information for those responsible for creating and maintaining the profile;
• An indication of any other profiles which may be related to the current profile, and the nature of that relationship (e.g., this profile supersedes a previously submitted profile). The profile should provide URIs for any related profiles mentioned;
• A description of the context in which the profile is intended to operate, including the resource model it is intended to address an any relevant use cases;
• An enumeration of all external schema which may be used in METS objects conforming to the profile, with a description of where they may be used;
• An enumeration of any rules of descriptions to be used in any sections of the METS objects conforming with the profile, along with details of where those rules of description apply;
• An enumeration of any controlled vocabularies to be used in any sections of the METS document (beyond those contained within the METS schema itself) conforming to the profile, along with details regarding where those vocabularies will be used;
• A description of any structural requirements regarding the construction of the METS object itself, including requirements for the presence/absence of any elements or attributes described within the METS schema, the presence/absence of any elements or attributes described within any extension schema used within METS documents conforming to the profile, and any rules regarding arrangement of elements within the METS document;
• A detailed description of the allowable technical characteristics of content files or executable behaviors contained within or referenced by the METS document, as well as metadata files external to the METS document;
• A description of affiliated tools, including validators, stylesheets, authoring tools, rendering applications, which can or should be used with this profile. The description should provide a name, description, and URI for each tool, as well as the agency responsible for its production;
• Snippets of XML serving as examples that illustrate desired features of the profile; and
• An example METS document which conforms to the profile, included as an appendix.

A METS profile MUST contain all of the above elements, and the first five elements must contain the information indicated. The remaining elements (with the exception of the Appendix), however, may be left empty to indicate that the profile imposes no restrictions on the creation of a conforming METS document within that area. However, as the purpose of profiling a METS object class is to constrain the domain of potential METS objects which might conform to the profile, it is anticipated that at least one of the major sections of a METS profile will contain a restriction on creation of conforming METS documents.

In addition to these subelements, the root METS_Profile element contains two attributes: STATUS and REGISTRATION. STATUS indicates whether the profile is in a final or provisional form, and REGISTRATION indicates whether or not the profile has been formally registered with the Library of Congress.

An XML Schema for METS Profiles is included as Appendix 1. ALL METS profiles submitted to Library of Congress for registration must be written in XML and validate against this schema. An example of a completed METS profile document is included as Appendix 2.

URI

Every METS profile must be assigned a unique URI RFC 2396 by the institution responsible for its creation. This URI must have the attribute ASSIGNEDBY="local". If the profile is to be publicly registered at the Library of Congress Network and MARC Standards Office, the URI must not duplicate any URI assigned to any currently registered profile. A second URI element will be added if and when a profile is registered at the Library of Congress. This URI will have the attribute ASSIGNEDBY="metsboard" and a REGDATE attribute indicating the date on which the profile was registered.

Short Title

The profile must contain a short, human readable string describing the class of METS objects being profiled (e.g., "NYU Monograph", "Stereographic Image", "SCORM object", etc.). This title must not exceed 256 characters. Titles in multiple languages may appear, using the xml:lang attribute to distinguish them. Do not repeat the <title> element for any purpose other than to provide the title in multiple languages.

Abstract

The profile must contain a one-paragraph description of the profile's nature and purpose. This abstract must not exceed 2048 characters in length. Abstracts in multiple languages may appear, using the xml:lang attribute to distinguish them. Do not repeat the <abstract> element for any purpose other than to provide the abstract in multiple languages.

Creation Date

The profile must include the date and time the profile was created by the responsible institution.

Contact Information

The profile must contain contact information for an individual or entity responsible for the profile's creation and who may be contacted for clarification of the contents of the profile. Contact information must include a mailing address that can be used to contact someone regarding the profile, and may also include the name of a specific individual to contact for information regarding the profile, the name of the institution responsible for creating the schema, a phone number for a contact individual and an e-mail address. The <contact> element may be repeated, with the ROLE attribute providing information on what individual or entity is responsible for which aspects of profile creation and maintenance.

Related Profiles

A profile may indicate its relationship with other METS profiles. METS profiles are not explicitly versioned, as implementations may exist that use older editions of METS profiles. Therefore a new version of a profile must be registered as a new profile. In this case, the RELATIONSHIP attribute should be used to indicate that a profile supersedes a profile already registered with the Library of Congress Network Development and MARC Standards Office. For each related profile, the profile should specify a URI for the related profile and the nature of the relationship between the current profile and the related profile.

Profile Context

A profile may document the context in which it operates through the inclusion of a Resource Model and statement of Use Cases.

Resource Model

This section is made up of simple text describing what the objects are that the Profile deals with, and could include information such as whether the profile is intended for an OAIS SIP, AIP, or DIP. Available are an optional head subelement and some available text formatting elements from the xhtml namespace. Available xhtml elements include p, various list/item elements, text formatting such as b and i, a, and img.

Use Cases

This section is made up of one uses element containing one or more use subelements, each describing a single use case. It is primarily envisioned to describe different requirements for METS documents at different points in their project lifecycle with a single profile, connecting a processing action with a specific feature of a METS document. The use element has an optional REQID attribute, which is an IDREF to the ID of a specific <requirement> element declared in the same profile.

The use element has an optional head subelement and some available text formatting elements from the xhtml namespace. Available xhtml elements include p, various list/item elements, text formatting such as b and i, a, and img. The latter could be used to embed within the profile documentation such as a diagram of a business process that uses a METS document conforming to the profile

External Schema

A profile which will be registered with the Network Development and MARC Standards Office must identify all external schema which may be used in constructing a METS document conforming with the profile. external schema for registered profiles MUST be publicly available. The schema must be identified in sufficient detail to allow a document author previously unfamiliar with the schema to unambiguously identify and retrieve it. Those registering profiles with the Network Development and MARC Standards Office are strongly encouraged to include a URI for each identified external schema which may be used to retrieve that schema from any Internet workstation, and may wish to include the complete text of any required external schema as an appendix to their profile.

A single external_schema element should used for each external schema listed in the profile. Multiple external_schema elements may be used within a single profile. For each external schema described, you may provide a name of the schema, a URL indicating where the schema is located, the target namespace expected by the schema, a repeatable context description indicating where in a conforming METS document the schema may be used, and an additional note. Repeat <URL> within <external_schema> only to indicate more than one version of a single external schema may be used, such as variant incremental version numbers; repeat <external_schema> to reference entirely different external schema. The note element has an optional head subelement and some available text formatting elements from the xhtml namespace. Available xhtml elements include p, various list/item elements, text formatting such as b and i, a, and img.

Rules of Description

An institution may choose to employ particular rules of description when encoding text within elements and attributes of a METS document. For example, a library might decide that descriptive metadata within a <dmdSec><mdWrap> section will be encoded using the Library of Congress' MARC 21 XML Schema MARCXML, and that the content of all elements and attributes within the MARC 21 XML sections must be prepared in accordance with the Anglo-American Cataloguing Rules 2nd Edition AACR2. The Rules of Description portion of a METS profile for that institution's METS objects should indicate that AACR2 must be applied to all content within a MARC 21 XML Schema portion of a METS document conforming to that profile.

The description_rules element has an optional head subelement and some available text formatting elements from the xhtml namespace. Available xhtml elements include p, various list/item elements, text formatting such as b and i, a, and img.

Controlled Vocabularies

An institution may choose to employ certain controlled vocabularies, such as the Library of Congress Subject Headings or the Getty Thesaurus of Geographic Names, for the content of elements within portions of a METS document. If use of a particular controlled vocabulary is mandatory in any section of a conforming METS document, that controlled vocabulary must be listed in this section of a profile. For all such controlled vocabularies, you should provide a name for the controlled vocabulary, an agency responsible for the vocabulary's maintenance, and a URI assigned to the vocabulary. If you desire, you may also include the individual values/terms within the controlled vocabulary, although it is anticipated that this will only be done when you wish to publicize the contents of a locally-produced controlled vocabulary to others who wish to produce conforming METS documents; there is no need to itemize the contents of well-known controlled vocabularies such as LCSH. For all controlled vocabularies, you should provide contextual information indicating where within a conforming METS document the vocabulary may be used, and if desired brief description of the vocabulary and its purpose. The description subelement of vocabulary has an optional head subelement and some available text formatting elements from the xhtml namespace. Available xhtml elements include p, various list/item elements, text formatting such as b and i, a, and img.

Structural Requirements

The METS document structure is extraordinarily flexible; that flexibility may be problematic inasmuch as creating software to process any arbitrary METS document in any but the most rudimentary way (XML parsing and validation) is a non-trivial task. This task can be simplified to some degree if those creating software to process METS documents know that there are further constraints on the structure of a METS document beyond those of the METS schema itself.

The structural requirements portion of a METS profile allows an institution to delineate additional restrictions on the structure of a conforming METS document beyond those specified by the METS format itself. It is permissible to specify restrictions on the structure of a conforming METS document which cannot be validated by standard XML validation tools. For example, it would be a permissible restriction to state that master still images within a METS document should be contained within a separate file group from derivative images.

It is impossible to fully delineate the possible additional structural restrictions that institutions may wish to set forth in their profiles, but the following list identifies some major areas of concern that institutions may wish to address in the Structural Requirements portion of a profile:

• Are there any restrictions on the number of occurrences of elements or attributes set forth in the METS schema beyond those specified by the METS schema itself (e.g., there should only be one occurrence of a dmdSec, every conforming document must include a metsHdr element, etc.)?
• Are there any restrictions on the number of occurrences of elements or attributes encoded using extension schema beyond those specified by those schema?
• May extension schema only be used within a particular portion of a METS document (e.g., you may wish to specify that a particular extension schema may be used within a <mdWrap> element within a <techMD> section, but that it should not be used within a <sourceMD> section).
• Should the structural map conform to a particular model? For instance, a profile for monographs might specify that the root <div> element must have a TYPE attribute of "book", that all immediately subsidiary <div>s have a TYPE attribute of "chapter". Alternatively, it might specify that there be a root <div> with a TYPE attribute of "text" with subsidiary <div>s having a TYPE attribute of "page". Structural metadata is the heart of a METS document, and those creating profiles should try to be as explicit and precise as possible in specifying how structural maps should be created, and may wish to include examples within an appendix to the profile.
• Should document authors include metadata within a METS document using mdWrap, or reference it using mdRef? Or are both allowable?
• Should content files be included within a METS document using FContent, or referenced using FLocat? Or are both allowable?

The structural_requirements is subdivided into subelements for each major section of a METS document. Requirements pertaining to a particular section should be listed underneath the section of the METS document to which they pertain. If you need to specify a structural requirement that involves more than one major section of the METS document, list it underneath the multiSection subelement within the structural_requirements element.

Every subelement within the structural_requirements section is composed of a sequence of individual requirement elements. The requirement element has four attributes:

1. an optional XML ID attribute,
2. an optional IDREFS attribute called RELATEDMAT, which you may use to indicate other portions of the profile document where this particular requirement is relevant. Requirement elements are in turn composed of a sequence of paragraph <p> elements,
3. an optional IDREFS attribute called EXAMPLES, which you may use to point to examples in the <Examples> section that demonstrate the requirement, and
4. an optional REQLEVEL attribute with values drawn from RFC 2119 http://www.ietf.org/rfc/rfc2119.txt.
• MUST: This word means that the definition is an absolute requirement.
• SHOULD: This word means that there may exist valid reasons in particular circumstances to ignore the requirement, but the full implications must be understood and carefully weighed before choosing a different course.
• MUST NOT: This phrase means that the prohibition described in the requirement is an absolute prohibition of the profile.
• SHOULD NOT: This phrase means that there may exist valid reasons in particular circumstances when violating the prohibition described in the requirement is acceptable or even useful, but the full implications should be understood and the case carefully weighed before doing so. The requirement text should clarify such circumstances.
• MAY: This word means that an item is not prohibited but fully optional.

The requirement element has two children: description and tests. The required description element has an optional head subelement and some available text formatting elements from the xhtml namespace. Available xhtml elements include p, various list/item elements, text formatting such as b and i, a, and img.

The optional tests subelement of description exists to supplement a textual description of a requirement with one that can be used to eventually provide machine validation. Tests supplied should be as granular as possible, to facilitate machine actionability. The tests element includes one or more test elements, which in turn contain one of testString, testWrap, or testRef elements. The test element contains the following attributes:

1. ID: an optional attribute uniquely identifying this element within the METS Profile document
2. LABEL: an optional textual description of the test being performed
3. TESTLANGUAGE: a required attribute indicating the language in which the test is expressed, such as XPath or XQuery
4. TESTLANGUAGEVERSION: an optional attribute indicating what version of the testing language has been used
5. TESTLANGUAGEURI: an optional attribute indicating an authoritative URI for the testing language used

The same test supplied in alternate languages should be provided through multiple test elements within a single parent tests element. Sibling tests elements should be interpreted as alternatives to one another.

The testString element is used for an XPath expression or other simple string describing the text to be done. It has an an optional CONTEXT attribute used to indicate the context in which a test should be evaluated.

The testWrap element contains one of the following:

1. <testXML> (for embedding full Schematron or other XML languages expressing test criteria)
2. <testBin> (for embedding binary data such as code in a scripting language)

Both textXML and testBin have an optional CONTEXT attribute used to indicate the context in which a test should be evaluated.

The testRef element is intended to point to testing code stored elsewhere. It contains an xlink:href attribute to point to this testing code. When using testing code not easily embedded inside the METS Profile, such as that written in Perl, testRef is preferred over testWrap.

It is assumed each test�s desired outcome is to evaluate to "true." Implementers must ensure that the requirement level indicated and any formal test evaluation pattern are aligned so that the test indicates conformance rather than an error.

Technical Requirements of Content, Behavior and Metadata Files

A METS document may reference a variety of external files, including the content files for the METS object (via <FLocat>elements), executable behaviors (via the <mechanism> element), and external metadata files (via <mdRef> elements). Non-XML content and metadata files may also be embedded within a METS instance, if they have been Base64 encoded. Institutions may wish to place restrictions on the nature of these external and non-XML files, such as insisting that all image files be in the TIFF 6.0 format and have a bit-depth between 16 and 32 bits, or that references to external metadata identified as being of type "MARC" via the MDTYPE attribute will point to MARC records conforming to the MARC 21 standard (or alternatively, to an HTML display of a MARC 21 record).

The Technical Requirements section of a profile allows institutions to set forth the full set of restrictions on the technical nature of files which may be referenced from a conforming METS document. It is subdivided into sections for restrictions on content files, restrictions on behavior files, and restrictions on metadata files. Profile authors should bear in mind that one of the primary purposes of the Technical Requirements section is to allow software developers to anticipate what types of content will be accessible via links from the METS objects, and hence what software is needed to process that content.

Every subelement within the technical_requirements section is composed of a sequence of individual requirement elements. The requirement element has four attributes:

1. an optional XML ID attribute,
2. an optional IDREFS attribute called RELATEDMAT, which you may use to indicate other portions of the profile document where this particular requirement is relevant. Requirement elements are in turn composed of a sequence of paragraph <p> elements,
3. an optional IDREFS attribute called EXAMPLES, which you may use to point to examples in the <Examples> section that demonstrate the requirement, and
4. an optional REQLEVEL attribute with values drawn from RFC 2119 (http://www.ietf.org/rfc/rfc2119.txt)
• MUST: This word means that the definition is an absolute requirement.
• SHOULD: This word means that there may exist valid reasons in particular circumstances to ignore the requirement, but the full implications must be understood and carefully weighed before choosing a different course.
• MUST NOT: This phrase means that the prohibition described in the requirement is an absolute prohibition of the profile.
• SHOULD NOT: This phrase means that there may exist valid reasons in particular circumstances when violating the prohibition described in the requirement is acceptable or even useful, but the full implications should be understood and the case carefully weighed before doing so. The requirement text should clarify such circumstances.
• MAY: This word means that an item is not prohibited but fully optional.

The requirement element has two children: description and tests. The required description element has an optional head subelement and some available text formatting elements from the xhtml namespace. Available xhtml elements include p, various list/item elements, text formatting such as b and i, a, and img.

The optional tests subelement of description exists to supplement a textual description of a requirement with one that can be used to eventually provide machine validation. It includes one or more testGrp elements, which in turn contain testWrap or testRep elements. The testGrp element contains the following attributes:

1. ID: an optional attribute uniquely identifying this element within the METS Profile document
2. LABEL: an optional textual description of the test being performed
3. TESTLANGUAGE: a required attribute indicating the language in which the test is expressed, such as XPath or XQuery
4. TESTLANGUAGEVERSION: an optional attribute indicating what version of the testing language has been used
5. TESTLANGUAGEURI: an optional attribute indicating an authoritative URI for the testing language used

The testWrap element has a test subelement with an optional CONTEXT attribute used to indicate the context in which a test should be evaluated. The value of the text element should be the actual text expression in the selected testing language.

The testRef element is intended to point to testing code stored elsewhere. It contains an xlink:href attribute to point to this testing code. When using testing code not easily embedded inside the METS Profile, such as that written in Perl, testRef is preferred over testWrap.

It is assumed each test�s desired outcome is to evaluate to "true." Implementers must ensure that the requirement level indicated and any formal test evaluation pattern are aligned so that the test result indicates conformance rather than an error.

Tools and Applications

A profile should provide a description of any affiliated tools, including validators, stylesheets, authoring tools, rendering applications, which can or should be used with METS documents conforming to the profile. The description should provide a name for the tool, the agency responsible for its development, a description of the tool, and a URI for obtaining the tool or further information regarding it. The description and note subelments of tool have an optional head subelement and some available text formatting elements from the xhtml namespace. Available xhtml elements include p, various list/item elements, text formatting such as b and i, a, and img.

Examples

A METS profile may contain one or more Example elements. Unlike Appendix elements, which are expected to contain complete METS encodings, an Example element would contain just a code snippet intended to demonstrate some requirement of the profile. The data type of the Examples element allows for partial, well-formed encodings that still might not satisfy all of the requirements for a full METS encoding.

A requirement can link to one or more Example elements by referencing the ID value of the pertinent Example elements in its EXAMPLES attribute.

The Example element has two attributes:

1. ID. This attribute is required, as every Example should be linked to from the requirement of which it is an example.
2. LABEL. This optional attribute allows for the descriptive labeling of an example.

Appendix: Full Example METS Document

A profile must contain an appendix containing an example METS document which conforms to the requirements set out in the profile. Profile authors should note that in order to insure that the completed profile document is valid, any namespace and schemaLocation declarations contained in the root <mets> element should be moved to the root <METS_Profile> element.