The document discusses the Metadata Encoding and Transmission Standard (METS), which is an XML schema for encoding metadata to manage and exchange digital objects between repositories. It provides an overview of the history and development of METS. The key components of a METS document include a header, descriptive and administrative metadata, a file section, and a required structural map which outlines the hierarchical structure and links files and metadata.

1. Manu Kumar K M
IInd MLISc
DOS in LIS
Manasagangotri, Mys
ore.

2. Content
Introduction
History
Characteristics of METS.
Sections of a METS document
METS header
Descriptive Metadata
Administrative Metadata
File Section
Structural Map
Structural Links
Behavioral
Conclusion

3. The Metadata Encoding and Transmission Standard (METS) is a
data encoding and transmission specification, expressed in XML, that
provides the means to convey the metadata necessary for both the
management of digital objects within a repository and the exchange
of such objects between repositories. This common object format was
designed to allow the sharing of efforts to develop information
management tools/services and to facilitate the interoperable
exchange of digital materials among institutions. The METS XML
schema was created in 2001 under the sponsorship of the Digital
Library Federation (DLF), is supported by the Library of Congress as its
maintenance agency, and is governed by the METS Editorial Board.

4. History
As early as 1996 the University of California, Berkeley began
working toward the development of a system that combined encoding for
an outline of a digital object's structure with metadata for that object. In
1998 this work was expanded upon by the Making of America II project
(MoAII). An important objective of this project was the creation of a
standard for digital objects that would include defined metadata for the
descriptive, administrative, and structural aspects of a digital object. A
type of structural and metadata encoding system using an XML Document
Type Definition (DTD) was the result of these efforts. In 2001, a new
version of the DTD was developed that used namespaces separate from
the system rather than the vocabulary of the previous DTD. This revision
was the foundation for the current METS schema, officially named in April
of that year.

5. Characteristics of METS.
An open standard
Non-proprietary
Developed by the library community
Relatively simple
Extensible
Modular

6. Sections of a METS document
• METS header
• Descriptive Metadata
• Administrative Metadata
• File Section
• Structural Map
• Structural Links
• Behavioral

7. Sections of a METS document
METS header metsHdr: Contains metadata
describing the METS document itself, such as its
creator, editor, etc.
Ex:- <metsHdr CREATEDATE="2006-05-09T15:00:00“ LASTMODDATE=”2006-05-
09T21:00:00>
<mets:agent ROLE="CREATOR" TYPE="INDIVIDUAL">
<mets:name>Rick Beaubien</mets:name>
</mets:agent>
<mets:altRecordID TYPE=”LCCN”>20022838</mets:altRecordID>
</metsHdr>

8. Descriptive Metadata dmdSec: May contain
internally embedded metadata or point to metadata
external to the METS document. Multiple instances of
both internal and external descriptive metadata may be
included.
Ex: <mets:mets>
<mets:dmdSec ID="DMD1">
<mets:mdRef MIMETYPE="application/MODS"
MDTYPE="MODS"/>
<mets:binData>[base 64 encoded data goes
here]</mets:binData>
</mets:dmdSec>
</mets:mets>

9. Administrative Metadata amdSec: Provides
information regarding how files were created and
stored, intellectual property rights, metadata
regarding the original source object from which the
digital library object derives, and information
regarding the provenance of files comprising the
digital library object (such as master/derivative
relationships, migrations, and transformations). As
with descriptive metadata, administrative metadata
may be internally encoded or external to the METS
document.

10. File Section fileSec: Lists all files containing content
which comprise the electronic versions of the digital
object. file elements may be grouped
within fileGrp elements to subdivide files by object version.
Although this section is not required, it is typically included
in most METS documents as it adds a level of functionality
to the structure of the document.
<mets:fileSec>
<mets:fileGrp USE="archive image"></mets:fileGrp>
<mets:fileGrp USE="reference image"></mets:fileGrp>
<mets:fileGrp USE="thumbnail image"></mets:fileGrp>
</mets:fileSec>

11. Structural Map structMap: Outlines a hierarchical
structure for the digital library object, and links the
elements of that structure to associated content files
and metadata. The Structural Map is the only section
required for all METS documents.

12. Structural Links structLink: Allows METS creators to
record the existence of hyperlinks between nodes in
the Structural Map. This is of particular value in using
METS to archive Websites.
Ex:- <mets:structLink>
<mets:smLink xlink:from="IMG1" xlink:to="P2" xlink:title="Hyperlink
from JPEG Image on
Page 1 to Page 2" xlink:show="new" xlink:actuate="onRequest"/>
</structLink>

13. Behavioral behaviorSec: Used to associate executable
behaviors with content in the METS object. Each behavior
has a mechanism element identifying a module of
executable code that implements behaviors defined
abstractly by its interface definition.
Ex:- <mets:behaviorSec>
<mets:behavior ID="disp1" STRUCTID="top" BTYPE="display" LABEL=
"Display Behavior">
<mets:interfaceDef LABEL="EAD Display Definition" LOCTYPE="URL"
xlink:href=”http://texts.cdlib.org/dynaxml/profiles/display/oacDisplayDe
f.txt”/>

14. Conclusion
The METS schema provides a flexible mechanism for
encoding descriptive, administrative, and structural metadata
for a digital library object, and for expressing the complex links
between these various forms of metadata.� It can therefore
provide a useful standard for the exchange of digital library
objects between repositories. In addition, METS provides the
ability to associate a digital object with behaviors or services.
The above discussion highlights the major features of the
schema, but a thorough examination of the schema and its
included documentation is necessary to understand the full
range of its capabilities.