Bill Kehoe, a programmer/analyst specialist in IRIS, will lead a discussion about Metadata Encoding and Transmission Standard (METS), an XML schema for encoding descriptive, administrative, and structural metadata for objects within a digital library.

Bill began by giving a brief history of METS and described how it was created by Jerome McDonough who was a former UC student and is now at New York University. Essentially, METS is an XML container, glorified file cabinet. It was created because metadata for complex digital objects is different than metadata for books that are less complex.

METS is a Container. It bundles complex digital objects into 1 standardized format that can be easily shipped around. It fits in very well with OAIS.

So What does METS look like?

The heart of it is the structural map. The structural Map is only piece of METS that is mandatory

METS pointer -- points to other METS documents

Something can be a pointer or the content itself or a wrapper for content; There is also a metadata wrapper

There are 7 elements under a METS document. Metadata about the object is contained within the six elements:
<structLink>File Section- Xlink encoding

The behavior section is a great idea; added at the request of the folks implementing FEDORA at the University of Virginia; It was added because every kind of object may have different type of behaviors. For example, printing a PDF is different than printing a html document.

Administrative MD section <amdSec>
This section deals with metadata that describes technical, source, digital provenance, rights

Descriptive <dmdSec>
Only wrapper and reference (pointers); more ephemeral; could change over time according to language and purpose

METS Profiles are used to specify limitations and restrictions, To define a document class, To promote documents

Interestingly enough, Herbert von de Sompel is using MPEG21 instead of METS; because they did not want to imbed behaviors within the METS standard; Adam Chandler attended a session about this at DLF and he thinks that one should understand Sompel's decisions before one decides to fully embrace METS.

METS will not be the AIP for FEDORA; but it is acceptable for SIP and DIP; For XML

Because METS is so general, application profiles are becoming more popular. Essentially, restricted set of METS XML tags are defined to describe the object that one is working with. One can define a document class that is specific to a particular type of project; i.e. Euclid or CUGIR. Profiles are XML docs; they contain METS docs as well as others. However, they can be more complicated than the METS document itself. It can have as many as 11 elements. Most are simple text statements: URI, Short Title, Abstract, Creation Date, Contact Information, Related Profiles, extension Schema, structural requirements, technical requirements, tools and applications, sample file (METS document)

What can be done with a METS Object?

Web pages

A website can be dynamically created from the METS file that (see the file that Bill passed out to the audience.) The URL of the page is a stylesheet.

Bill likes the way this done. Although putting the websites in one file is cool, but not necessarily efficient. The XSL file is a significant and not trivial. METS doc, xml file, images, stored in ORACLE or MySQL.

Dave Ruddy commented that a lot of efficiency gained but creating web pages using METS, but the downside is that producers have to create the complex document.

Digital library page turner

Some folks at NYU created a page turner, which was a different style sheet for the Afghanistan Digital Library.

Audiovisual Material Description

Carl Fleischhauer of the Library Congress, used METS to describe audiovisual materials, however the IT support is not done at LC, it is done elsewhere.

Implementations

OCLC digital archive can import file to create the METS object which include batch export and import. Columbia and 2 other institutions are involved in this effort.

There is a high learning curve with METS even after you understand the structure map.

Interoperability with things like Endeavor is a problem, but that is true of many systems. It would be necessary to create crosswalks between digital library objects, CHLA or CUGIR FGCD to METS format

Audience Discussion

METS has the potential of making CUL Websites more interoperable.

One delivery system with one container would be great

Peter Hirtle stated that application profiles could create common metadata which the CUL should be creating regardless of delivery system; Mets are XML documents and most institutions are moving towards XML. The CUL would benefit from implementing a system such as METS if it could integrate it into a common repository delivery system

METS Cons

• Up-front expense
• A significant amount of tools must be made

METS Pros

• METS would be a good match for Dspace
• Problems using METS across the board is directly related to the cons
• NYU, The California Digital Library (Rick Beaubien) are using METS extensively
• METS in and of itself is not going to interoperate anything. Profiling is necessary to meet specific needs of a community. No such thing as a common METS project.
• Everything about METS can be found at the Website
• Currently, there are no plans for more work on METS. Its proponents are encouraging folks to make more profiles and extension schema. At Community development day, it was clear that everyone is willing to share their work.
• Peter Hirtle: Would it be useful for the CUL to develop a schema for its image collections? It would be good to put OAIS in work; place to develop tools. We have to start somewhere; create METS profile and give it to folks at DLIT and DCAPS and when they scan documents. Of course, we would need support for time and money.