UserPreferences

RicksBrainDumpDistilled

High Level Comparison

As our simple METS/IMS-CP examples above demonstrate, there is a great similarity between METS and IMS-CP at the highest level. Both provide for:

Both METS and IMS-CP allow the content files comprising a digital object to be assembled in more than one way, thereby allowing the user different possible approaches to and experiences of the same content. Neither defines nor prescribes a particular vocabulary for describing the content of the digital object, nor for expressing associated administrative metadata such as information about how the content files were produced, or what rights restrictions pertain to their use.

Provisions for Content Compared

Despite the high level similarity between the two standards, certain conceptual and practical differences are likely to distinguish documents implementing the two standards. These differences can pose challenges for absorbing METS objects representing library resources into an IMS-CP learning package. Comparing how typical library METS documents and typical "interactive university" IMSCP documents are likely to wrap, organize and describe content will illuminate some potential misalignments between the two standards as applied.

Libraries are likely to use METS to wrap and organize digital versions of their primary source materials. Such materials might include: rare manuscript materials; recorded oral histories with associated transcriptions and supplementary images; or video or film clips of historical theatrical performances. The types of files that would make up the digital versions of these various types of materials would also vary. The files comprising the digital version of a manuscript would be likely to include images of varying formats and resolutions(tiff master, medium resolution jpeg, thumbnail gif). They might also include a structured text transcription (tei/xml) of the manuscript. The digital version of an oral history is likely to include a digital audio file and tei/xml encoded transcription of the oral history. It might also include alternate digital versions (tiff, jpeg, gif) of supplementary images. The digital version of a historical performance film or video would consist of one or more digital video files.

Libraries would use METS not just to wrap such various digital versions of the content but also to organize this content in ways likely to be useful to the end user. For example, a METS version of a manuscript could analyze the manuscript into a sequence of pages, and specify which files or parts of files constituted versions of each page. For example, the METS encoding might link a page of the manuscript with three digital versions of the page: a tiff master, a medium resolution jpeg, and a gif thumbnail. The METS document representing an oral history could analyze the oral history into a sequence of topical divisions, and specify which portion of the associated audio file and the associated transcription file constituted manifestations of each topical division. And METS could analyze a digital video of, say, a dance recital into the segments representing the individual dances comprising the performance.

A METS version of primary library source material, then, can enumerate the files comprising the digital version of the primary source material, and express the structural relationship between these files, or parts of these files. The METS document could also go on to specify how these content files should be presented to the end user--the library patron--by identifying an appropriate presentation program and specifying how this presentation program should be invoked. If the METS document did specify a presentation, however, this presentation would be clearly separated from the content. And as applied by many libraries, METS documents representing primary source materials will probably not address presentation at all. Rather these METS documents will simply point to the raw content, and provide structural clues on which any number of presentations might be based. While presentation of the content to library patrons is of course very important, different uses, audiences, times and available technologies are likely to require different presentations. A library is likely to be less concerned with using METS to pin down a particular presentation of digitized library materials than it is with providing for long-term preservation of the content itself, and insuring its ability to communicate the structure and content of these materials to other times, places and institutions.

Thus, while a web-based presentation of the content represented by a library METS document is very likely, the METS document may do more than provide the structural clues on which such a presentation could be based. In the library at the U.C. Berkeley, for example, a Java servlet based program called GenView disseminates the content of library METS objects to end users; but the METS documents themselves make no reference to "GenView", and they make no attempt to make their content files "GenView" ready (by wrapping the content in html, for example). And GenView is just one of many potential programs that might disseminate the content of a U.C. Berkeley METS document.

Like METS, the IMSCP standard does not dictate a particular presentation of content. However, it is common for IMSCP documents to organize their content files into "webcontent" resources. Such resources presuppose browser presentation and in addition to raw content files (such as image, audio and/or video files), such resources are likely to include an html file that controls the presentation of the content files in the users' browser. And the html file is likely to invoke auxliary program files, with appropriate parameters, to assist with the presentation of the content. When an IMSCP document organizes "webcontent", it in fact does not distinguish strongly between presentation and content, and it considers the html file that manages the presentation to be an integral part of the content.

Absorbing a METS document into a learning object representing "webcontent" and which presupposes browser presentation may involve some challenges. Where the content files specified in the METS document are already web-compatible (as would be the case with jpeg and gif images), there is no problem. These can simply become "webcontent" resources in the learning package. However, where the content files referenced are audio or video files, which the browser cannot present natively, then the METS content must somehow be made browser-ready before it can be absorbed into the learning package. If the METS document analyzes its content into a structure that references just parts of files (a segment of an audio file, for example) or if the METS document makes available multiple versions of the same content (images at different resolutions, for example), then accommodating the METS content to IMS-CP "webcontent" becomes more complex still.

Provisions for Associated Metadata Compared

Neither METS nor IMS-CP itself explicitly prescribes a standard vocabulary for expressing descriptive and administrative metadata. As noted above, however, both allow these metadata to be expressed using external standards. Still, the communities that use METS and IMSCP are likely to favor the use of certain standards for certain purposes. The e-learning community, for example, strongly favors the use of IMSMD (or LOM) in IMS-CP documents. The favored auxiliary metadata schemas in METS are not always so clear-cut. Libraries using METS are likely to favor MODS, Dublin Core (DC) or even MARCXML for describing content; museum communities will probably favor VRA (when an xml version of this standard becomes available). Most METS users will probably favor MIX, based on the NISO data dictionary (Z39.87), for capturing technical metadata about images. The choice for other administrative metadata categories, such as rights, is not so clear.

When absorbing a METS object into a IMSCP package, parsing out, say, MODS and MIX metadata into LOM categories and elements would not be straightforward. For one thing, METS and LOM tend to categorize descriptive and administrative metadata in ways that are not precisely aligned. Furthermore, LOM tends to be descriptive metadata poor from a library cataloging practice standpoint; and technical metadata poor from a preservation standpoint. On the other hand, descriptive and administrative metadata in a library METS object is likely to lack many elements pertinent to courseware and e-learning environments.

While a translation from MODS and MIX to LOM is likely to incur fairly substantial losses, it is not clear that such losses would be especially significant from a practical standpoint insofar as the transformed METS object wouldn't be a replacement for its original--but rather simply a surrogate "rearranged" to perform in another--e-learning--environment. The losses would only be important if they effected the performance of the transformed METS object within this environment. The inability of the METS object to provide certain metadata pertinent to e-learning environments might be the more serious deficiency.

Both IMSCP and LOM accommodate descriptive and administrative metadata elements from other standards; so any elements appearing in a source METS document for which LOM provided no analogue could still be represented in an IMSCP object. Still, the extent to which such "open-hand" policies can be taken advantage is probably limited. Such policies tend to "dismantle" the very standard that provides for them, and make it more difficult to manage the objects implementing the standards in their target environments.