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

Root element for a METS Profile

A unique URI for this profile to be assigned by the creating institution. A URI must not duplicate the URI of any registered profile.

A short title to describe the class of object being profiled.

A one paragraph description of the profile's nature and purpose.

The date and time the profile was created.

Contact information for those seeking further information regarding the profile and its use.

The name of an individual who may be contacted regarding the profile.

The name of an institution which may be contacted regarding the profile.

The address for the individual and/or institution which may be contacted regarding the profile.

A phone number which people may call for information regarding the profile.

An e-mail address which people may contact for information regarding the profile.

The date the profile was registered with the Library of Congress Network and MARC Standards office, and the URI for obtaining the profile from the Library. This information in this element will be supplied by Library of Congress and should not be completed by those creating a profile for registration.

This element may be used to indicate the relationship of this profile to any other registered profile. The URI of the related profile and the nature of the relationship of this profile to the related profile must be recorded in the supplied attributes. If this element is used to indicate that the current profile supersedes a previously registered profile it should specify a RELATIONSHIP of 'supersedes' and provide the URI of the superceded profile. If there are no related profiles, this element should contain statement to that effect and leave the URI and RELATIONSHIP attributes blank.

A profile which will be registered with the Network Development and MARC Standards Office must identify all extension schema which may be used in constructing a METS document conformant with the profile. Extension 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 extension schema which may be used to retrieve that schema from any Internet workstation and to include the full text of all identified extension schema as an appendix to their profile registration.
Registered schema should also use the context subelement to name the elements within a conforming METS instance where the extension schema may be used. If a profile does not dictate the use of any extension schema, it should contain a single <extension_schema> element with subelement of <note> stating that no extension schema are specified in this profile.

An institution may choose to employ particular rules of description when encoding text within elements and attributes of a METS document (e.g., AACR2 for a MARCXML document in a descMD section of a METS document. This element should be used to specify all rules of description to be employed in preparing content for a compliant METS document, and where those rules of description should be employed. If a profile specifies no rules of description, it should still contain a <description_rules> element with a single <p> subelement stating that the profile specifies no rules of description for conforming documents.

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. A profile for that institution's METS objects should unambiguously identify any controlled vocabularies which are to be used in preparing a METS document conformant with that profile, as well as indicating the specific elements and/or attributes where those controlled vocabularies should be used, including any use in portions of a METS document encoded using an extension schema. If no controlled vocabularies are specified by the profile, it should still contain a <controlled_vocabularies> element with a single <p> subelement stating that no controlled vocabularies are specified by this profile.

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. Possible issues to address in this section include:
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 set forth in 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? If a profile specifies no structural requirements, it should still contain this element with a single <p> subelement stating that this profile dictates no structural requirements for conforming METS documents.
There are several subelements within the structural_requirements element, one
for the root <mets> element, one
for each major division within the METS document format, and a final subelement
called multiSection. Structural requirements should be listed within the subelement
identifying the portion of the METS format to which they pertain (e.g., a specification
that documents must use Flocat and not FContent to identify data files should
appear in the fileSec subelement within structural_requirements). Requirements
which span METS documents sections should appear in the multiSection
subelement.
Every subelement within the structural_requirements section is composed
of a sequence of individual requirement elements. The requirement element
has two attributes: 1. an XML ID attribute, and 2. an IDREFS attributed 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.

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). Institutions may wish to place restrictions on the types of files which may be referenced, 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 conformant METS document. It should be subdivided into sections for restrictions on content files, restrictions on behavior files, and restrictions on external 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. If a profile specifies no technical requirements, it should still contain a <technical_requirements> section and the three major subsections, each specifying that the profile imposes no requirements on conforming documents.

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, description, and URI for each tool. If there are no associated tools, the profile should still contain a single <tool> element with a single <note> subelement stating there are no associated tools for conforming documents.

A METS profile may contain one or more appendices. Every profile must contain at least one appendix containing an example METS document which conforms to the profile, and this example document should always be contained in the first appendix to the profile.