Descriptive metadata contents should be encoded using MARC, Dublin Core, Dublin Core Terms, or MODS extension schemas, following both the appropriate guidelines recommended by the extension schemas' maintenance agencies and the Ex Libris Guidelines for descriptive metadata. The metadata should be embedded in the METS file as XML, using the mdWrap tag.
mets/fileSec/fileGrp/@USE
thumbnail - A low resolution image
index - A plain text or HTML file which can be used for full text search
archive - Master copy usually from tiff format for image resources
reference - Any type of delivery format - usually a Web transportable file size for image/text/video/audio etc.
reference image - Image manifestation of primary reference usage copy
reference video - Video manifestation of primary reference usage copy
reference audio - Audio manifestation of primary reference usage copy
reference text - Textual manifestation of primary reference usage copy
alto - Index manifestation in the alto XML format (http://www.loc.gov/ndnp/alto_1-1-041.xsd) This index file can be used for full text search and highlighting functions
Images - This is a CCS compliant use type for image based objects
Text - This is a CCS compliant use type for alto objects
PDF - This is a CCS compliant use type for PDF objects
mets/structMap/@TYPE
"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. This <structMap> will be the default view when viewing METS objects that contain it.
"mixed" designates a mixed structure. For example, a book divided into chapters and also divided into page views. This <structMap> will be the default view when viewing METS objects and no "logical" <structMap> exist.
The root <METS> element must include a LABEL attribute value.
The root <METS> element must include a TYPE attribute value.
Conforming METS documents must contain a <metsHdr> element.
Conforming METS documents must contain a <metsHdr/agent/name> element.
Conforming METS documents may, but need not, contain one or more <dmdSec> elements.
Any metadata provided must be embedded in the METS file as XML using the mdWrap tag.
mdRef is not supported.
If a <dmdSec> of a conforming document contains a <mdWrap> with <xmlData>, the <xmlData> must conform to those listed in the extension schemas section above.
Any dmdSec ID may, but need not be, referenced by the DMDID value denoted in either the fileSec section or structMap div section sections.
When referenced using DMDID from the top-level structMap div, the assumption is that the metadata is relevant to the intellectual entity ONLY and not the specific files included in that intellectual entity.
When referenced using DMDID from the non top-level structMap divs, the assumption is that the metadata is relevant to the pages/files referenced from that div-level reference and inherited downward.
When not referenced using DMDID at all, the assumption is that the metadata is relevant to the intellectual entity ONLY and not the specific files included in that intellectual entity.
techMD (technical metadata) - Technical Video (LOC), Technical Audio (LOC), Technical Image, Technical Text.
rightsMD (intellectual property rights metadata) - Access Rights, Copyrights Metadata.
sourceMD (analog/digital source metadata) - Preservation Metadata.
digiprovMD (digital provenance metadata) - Change History Metadata.
A conforming METS document will contain one <amdSec> element per file.
Any defined <history_md>, <rights_md>, <text_md>, <audio_md>, <video_md>, <IMAGENISO> element or elements for the same file will appear in this single <amdSec> element and be designated by the appropriate type (techMD, rightsMD, etc.). Note that if the amdSec includes more than 1 metadata per file the ID reference should be to the specific child element metadata ID and not to the amdSec ID
If a <amdSec> of a conforming document contains a <amdWrap> with <xmlData>, the <xmlData> must conform to those listed in the extension schemas section above.
Any amdSec or child element techMD, rightsMD, sourceMD or digiprovMD ID may, but need not be, referenced by the ADMID value denoted in either the fileSec section or structMap div section sections.
When referenced using ADMID from the fileSec level - the metadata will be associated specifically with that particular file.
When not referenced using ADMID at all, the assumption is that the metadata is relevant to the intellectual entity ONLY and not the specific files included in that intellectual entity.
The <fileGrp> element must have a USE attribute.
Supported USE attribute values appear in the <controlled_vocabularies> section of this document.
The USE attribute should be expressed at the <fileGrp> level and not on the <file> level.
The <fileSec> must contain a <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 OCR full text files.
Each <file> represented in the <fileSec> must have a GROUPID attribute.
This attribute will associate each file with his manifestations (representations) in other <fileSec> sections.
For example a <file> holding a TIFF image will have the same GROUPID as its provided thumbnail manifestation <file>
Each <file> that has an ordered structure - i.e. physical pages and their thumbnails - should make use of the SEQ attribute to numerically indicate the order by which the physical order of pages should be displayed. The SEQ value should be consistent across the manifestation fileGrps for sibling file representations.
For example, the first master Tiff <file> image in a given <fileGrp> may have SEQ="1" and its analagous thumbnail in a different <fileGrp> should also have SEQ="1" within that respective <file> section.
Any <file> element may reference any number of pertinent descriptive metadata elements within the <dmdSec> via its DMDID attribute value. (see dmdSec section above) Best practice dictates that this reference will be made at the structMap div level rather than at the fileSec level.
Any <file> element may reference any number of pertinent adminstrative metadata elements within the <amdSec> via its ADMID attribute value. (see amdSec section above)
A conforming METS document must contain at least one <structMap>; it may, however, contain more than 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 <structMap> must include a LABEL attribute value.
Each <div> must include a LABEL attribute value.
The physical <structMap> represents a flattened structure and must only contain two levels of <div> elements with no further nesting. The top level <div> element required by the METS schema contains one level of child <div> elements to represent the linear sequence of the components of the digital object.
The logical structMap represents the full hierarchical structure of the digital object, and can contain as many levels of nested <div> elements as required to express the object's full structure.
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;
2) contain an <area> element that points to a <file> element;
3) contain a <seq> element comprising multiple <area> elements that point to the relevant <file> elements.
The <par> element can only be used in the PHYSICAL strcutMap.
Any <div> element may reference any number of pertinent descriptive metadata elements within the <dmdSec> via its DMDID attribute value. (see dmdSec section above)
Any <div> element may reference any number of pertinent administrative metadata elements within the <amdSec> via its ADMID attribute value. (see amdSec section above)
Each <div> can contain only one child node <fptr> at that level. In other words, if more than one <fptr> reference is provided at a given div level, ONLY the first <fptr> will be used.
In case more than one node is required the <div> will have a <seq> which holds the required child nodes.
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 ALTO OCR text. In this case, the <area> element under the <fptr> would point to the <file> element representing the ALTO OCR text document (via its FILEID attribute) and must at least indicate the starting point of the the relevant section of the referenced ALTO OCR text 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 an <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.
Note that this functionality is dependent on the support for the display of the area in the relevant viewer.
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.
This profile supports only image, textual, audio and video content files.
No default namespace is allowed in order to extract the text on the article window.
Default measurement unit is mm10, but measurement unit of pixel is also supported