All applications of the MODS schema in conforming METS documents follow the MODS User Guidelines published by Library of Congress' Network Development and MARC Standards Office.
mets/fileSec/fileGrp/@USE
mets/fileSec/fileGrp/file/@USE
These are the supported values for <file> and <fileGrp> USE attributes in paged text objects conforming to this profile.
"archive image", "reference image" and "thumbnail image" are appropriate values to describe the USE of image content files. "archive image" designates image masters; "thumbnail image" image thumbnails; and "reference image" any intermediate resolutions intended for reference purposes.
"tei transcription" and "tei translation" are appropriate values to describe associated structured text files encoded according to TEI rules;"tei transcription" designates direct TEI transcriptions of text based materials; "tei translation" designates TEI translations of these materials from their original language.
"ocr" and "ocr dirty" should be used to designate versions of the text produced by ocr technologies. "ocr dirty" would be used to distinguish ocr text that is not suitable for presentation to the user from clean "ocr".
A given segment of the source material could be represented by more than one content file of a particular USE. For example, the page of a manuscript that has been digitized could be represented by an image master (USE="archive image"), a thumbnail image (USE="thumbnail image"), but two jpeg reference images of different resolutions (USE="reference image")
mets/structMap/@TYPE
These are the supported values for the <structMap> TYPE attribute in METS documents conforming to this profile.
"physical" designates a purely physical structure. For example, a book divided into page views.
"logical" designates a purely logical structure. For example, a book divided into chapters; or a diary divided into diary entries.
"mixed" designates a mixed structure. For example, a book divided into chapters, divided into page views.
The root <mets>element must include a LABEL attribute value.
The root <mets> element must include an OBJID attribute value containing a valid ark and that uniquely identifies the object in its owning repository.
Conforming METS documents must contain a metsHdr element.
<metsHdr> element must include the CREATEDATE attribute value. It must also include the LASTMODDATE attribute value if this does not coincide with the CREATEDATE
<metsHdr> element must include a child <agent> element identifying the person or institution responsible for creating the METS object.
Conforming METS documents may, but need not, contain a one or more <dmdSec> elements. Each <dmdSec> may in turn contain a <dmdRef> or a <dmdWrap>
If a <dmdSec> of a conforming document contains a <dmdWrap> with <xmlData>, the <xmlData> must conform to the MODS schema.
Conforming METS documents may but need not contain an <amdSec> element. This <amdSec> may but need not contain one or more <techMD> elements, <sourceMD> elements, <rightsMD> elements and/or <digiprovMD> elements.
A conforming METS document will contain no more than one <amdSec> element. All <techMD>, <sourceMD>, <rightsMD> and <digiprovMD> elements will appear in this single <amdSec> element.
If one or more <techMD> elements pertaining to image content files are present, they must contain <xmlData> of NISOIMG type conforming to the MIX schema.
If one or more <techMD> elements pertaining to text content files are present, they must contain <xmlData> conforming to the textmd schema.
If one or more <rightsMD> elements are present, they must contain <xmlData> conforming to the METSRights schema.
Any <sourceMD> or <digiprovMD> elements should contain <xmlData> conforming to a METS Editorial Board endorsed schema whenever such a schema exists and covers the requisite concepts.
Source metadata pertaining to image content files may be expressed as part of any MIX encoded technical metadata in <techMD> elements rather than in separate <sourceMD> elements. This might occur whenever the available source metadata is minimal and covered by the MIX schema.
The <fileSec> of a conforming METS document must contain a parent <fileGrp> for each file format/use represented by the content files. For example, the <fileSec> of a typical METS document implementing this profile might contain one <fileGrp> representing TIFF master images, one <fileGrp> representing high resolution JPEG reference images , one <fileGrp> representing medium resolution JPEG reference images, one <fileGrp> representing GIF thumbnail images, and one <fileGrp> representing TEI transcriptions. Each of these <fileGrp> elements may or may not contain subsidiary <fileGrp> elements representing subgroups of the content files.
Each <file> represented in the <fileSec> must have an associated USE attribute. The USE attribute may be expressed directly at the <file> element level. Alternately, however, the USE attribute may be expressed in conjunction with the <fileGrp> that is the immediate parent of a <file> element; in this case it is taken to pertain to all <file> elements in the <fileGrp>. Supported <file>/<fileGrp> USE attribute values appear in the <controlled_vocabularies> section of this document.
Any <file> element may reference any number of pertinent top level adminstrative metadata elements within the <amdSec> via its AMDID attribute value. It should only reference ID values at the <techMD>, <rightsMD>, <sourceMD> and/or <digiprovMD> levels of the <amdSec>
A conforming METS document must contain only one <structMap>.
A conforming <structMap> must contain a TYPE attribute. Supported TYPE values appear in the <controlled_vocabularies> section of this document ("logical","physical", or "mixed").
Each <div> must include a LABEL attribute value.
A <div> element at any level may point to one or more pertinent <dmdSec> elements via its DMDID attribute value. However, the DMDID attribute should only reference IDs specified at the <dmdSec> element level, and not IDs at lower levels. For example, a <div> DMDID attribute should not reference an ID value of an element within the <xmlData> section of a <dmdSec>
A <div> element may or may not directly contain <fptr> elements. (In other words, a <div> of the <structMap> may or may not have content files directly associated with it).
An <fptr> element must either 1) directly point to a <file> element via its FILEID attribute; or 2) contain an <area> element that points to a <file> element; or 3) contain a <seq> element comprising multiple <area>a elements that point to the relevant <file> elements. METS documents implementing this profile must not use the <par> element. <structMap>s of "physical" and "mixed" TYPEs must not use either the <par> or <seq> elements.
An <fptr> element could directly contain an <area> element if only a portion of an integral file manifests the parent <div>. This is likely to occur in either of two cases. 1) This would typically be the case when the parent <div> element represented just a segment of the entire document and the <fptr> represented a tei transcription or a tei translation. In this case, the <area> element under the <fptr> would point to the <file> element representing the tei document (via its FILEID attribute) and must at least indicate the starting point of the the relevant section of the referenced tei file via the <area> BEGIN attribute. The BEGIN attribute, in this case, would have a BETYPE of "IDREF". The <area> element might also express the end point of the relevant section of the referenced file via its END attribute, but it need not do so. 2) When a <structMap> represents a logical structure, its individual <div> elements may each be manifested by only a portion of the associated image content files represented by its child <fptr> elements. In this case, an <fptr> element representing an image content file could, but need not, contain a <area> element which specified the shape and coordinates of the relevant section of the image via the <area> element's SHAPE and COORDS attribute values.
An <fptr> element would contain a <seq> element if multiple files needed to be"played" in sequence to manifest a division. This might be the case if the <structMap> expressed a logical structure and a <div> in that structure required several files to manifest it. For example, the <div> elements in the <structMap> for a diary might represent diary entries; and some of these entries might span multiple physical pages, and hence require multiple image content files to manifest them. In this case, the <div> representing the spanned diary entry would contain at least one <fptr>element; this <fptr> element would contain a <seq> element which in turn contained a separate <area> element pointing to each <file> element representing a page the diary entry spans. The <area> elements may include SHAPE and COORDS attribute values to identify the relevant sections of the associated image files, but they need not do so.
Each <fptr> element that does not contain subsidiary <area> or <seq> elements must point directly to a <file> element in the <fileSec> via its FILEID attributes. Similarly, each <area> element appearing under an <fptr> element or a <seq> element must point to directly to a <file> element via its FILEID attribute.
A conforming METS document may contain a <structLink> element. This profile, however, establishes no guidelines or expectations for its use.
A conforming METS document may contain a <behaviorSec> element. This profile, however, establishes no guidelines or expectations for its use.
Only <file> elements will reference <techMD>, <sourceMD> <rightsMD> and/or <digiprovMD> elements. In other words, documents implementing this profile will express administrative metadata in conjunction with content files only rather than in conjunction with <div> elements in the <structMap>.
Only <div> elements will reference <dmdSec> elements. In other words, documents implementing this profile will express descriptive metadata in conjunction with divisions of the <structMap> and not in conjunction with individual content files (<file> elements).
If a METS document conforming to this profile has associated image content files, the master (archive) images must be represented and of TIFF format.
At least one version of any image content must be of JPEG or GIF format. In other words, at least one content file format must be natively supported by typical internet browsers.
All "tei translation" and "tei transcription" files must be encoded according to version 1 of the "TEI Text Encoding in Libraries: Guidelines for Best Encoding Practices" maintained by the Digital Library Federation (http://www.diglib.org/standards/tei.htm).