UserPreferences

BrainDumpRickBeaubien

Rick's brain dump on the relationship between METS and IMS-CP. Distilled into 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:

Identifying and structuring the content

At lower levels the standards still overlap considerably, but also diverge in significant ways. While both METS and IMS-CP provide for inventorying the files comprising the content, the structure of these inventories and the underlying concept of a resource differ to some degree.

Both METS and IMS-CP define file elements that can reference external content files by means of a URI. METS provides for arranging these file elements into groups of files via a fileGrp element. For example, all of the thumbnail images might appear in one fileGrp, the medium resolution jpegs in another fileGrp, and the tiff masters in another fileGrp. METS, however does not specify how files should be grouped, and different implementors are likely to use different conventions.

In an IMS-CP file inventory, resource elements aggregate file elements. However, file elements thus aggregated must together comprise a single presentation resource, and the resource element is thus not analogous to the METS fileGrp despite the superficial resemblance. (The fileGrp could possibly be used in a manner analogous to the IMSCP resource, but library METS objects would probably tend not to use it that way. And an equivalence can certainly not be assumed when translating a library METS object into a learning package). [Furthermore, if a resource consists of a single file, a resource element may point to this directly, and not contain any file elements. (This is the case in our simple example above).] In its ability to aggregate multiple files that together comprise a resource the IMS-CP resource element more closely resembles the METS fptr element. This also may aggregate references to files or parts of files that must be played together, either in parallel or in sequence, to manifest a division of the object's structure. However, the fptr element, which is described in more detail below, occurs in the context of the METS structMap as a child of a div element.

The IMS-CP resource element does not explicitly define the relationship between the subsidiary files which comprise the presentation resource it represents. One of the file elements comprising the resource, however, may "know" the relationship between these files and be able "play" them in an appropriate manner. An IMS-CP resource representing "webcontent", for example, might consist of an html file, some image files and a video clip file. The html file knows about the other files comprising the resource, and their relationships and is used to "bootstrap" a coordinated presentation of the other files comprising the resource. It would know, for example, what images needed to be displayed, and where to display them; it would define, start up and stop an auxiliary application capable of playing the video. In this respect, an IMS-CP resource may include both "behaviors" and content. The "IMS Content Packaging Best Practice Guide" [web reference] notes that an IMS-CP resource "may be a collection of files that support the presentation of the associated presentation structure(<item> element)." The operative word here, repeated twice, is "presentation". IMS-CP focuses first and foremost on "presentation" to the end user--the student--rather than on the preservation and exchange of raw digital content. It is not so much interested in content per se as in a particular presentation of the content to achieve a particular goal--the education of the user. In the end, IMS-CP as applied tends not to distinguish strongly between "presentation" and "content". Indeed one could say that in a learning object presentation is content and the two cannot and should not be separated.

While an html page that played a video could constitute the content, or part of the content, of a METS object, METS as applied by research libraries to digital versions of their primary source materials, would tend to segregate presentation (or behavior) from content. In a METS document representing a digital version of a an oral history held by the library, for example, the file inventory would undoubtedly include a file that pointed to the raw digital audio file; but would probably not include a reference to an html file capable of launching this sound recording in an appropriate auxiliary application. If the METS object specified any presentation or presentations of the raw digital content, it would do so through the behaviorSec. But the behaviorSec is optional, and often a METS object representing primary library source materials would not specify a presentation at all. Rather it would simply provide the raw content and structural clues on which any number of presentations might be based. METS' focus on structured content as opposed to structured presentation reflects the goals and needs of the library community from which METS originates. While disseminations of its digital materials to library patrons is important, different uses, audiences and times are likely to require different disseminations. More important, then, than pinning down the presentation of the library digital material is its long-term preservation (including information about how the digital versions were created); and the ability to communicate the structure and content of its digital material to other times, places and institutions.

IMS-CP's focus on presentation, and tendency to combine (in METS terms) presentation with content might create some challenges in incorporating or transforming a METS object into an IMS-CP object. Where the content of the METS object, as in our simple example above, consists of files such a jpeg images that the browser can present natively, and where the desired target resource type is "webcontent", there is no problem. The METS content file can simply become a IMSCP resource. If the content were an audio or video file that the browser could not present natively, however, then the transformation would need to include the generation of an html page that would invoke, with the appropriate parameters, an application capable of playing the this audio file.

A closer look at the way that METS and IMS-CP link structure with content will help summarize and extend the issues under discussion here. As noted above, both METS and IMS-CP provide for specifying a hierarchical structure or structures for a digital object. (METS structMap element; IMS-CP organization element). As demonstrated in our simple example, the METS structMap consists of a hierarchically structured sequence of div or division elements. In addition to containing a subsidiary div element, a METS div element may govern one or more fptr elements that identify the files or parts of files that can manifest the content of the division, and as has already been noted above, it is really the fptr element in METS that provides the closest analogue to the IMS-CP resource element even though it occurs in the METS analogue to the IMSCP organization. An fptr element can directly point to a single file in the fileSec; to part of a single file (via a subsidiary area element); to multiple files or parts of multiple files that must be played in parallel (via a subsidiary par element); to multiple files or parts of files that must be played in sequence (via a subsidiary seq elements); or to multiple sequences of files that must be played in parallel (via a subsidiary par element that contains seq elements.) It should also be noted that a division of the structMap may contain multiple fptr elements that are immediate children. When it does so, these are taken to represent alternative manifestations of the division--or alternative resources in IMS-CP terms. For example, a METS div element representing the page of a diary might contain three fptr elements: one pointing to the master tiff image of the page; one pointing to a medium resolution jpeg image of the page; and one pointing to a thumbnail gif of the page. Each of these represents an alternative manifestation of the page.

IMS-CP, of course, provides for linking structure with content as well. However, in IMS-CP a division of the organization (the item element) can only point to a single resource in the resources section by means of an identifierref attribute. There is no direct provision in the IMS-CP item element for referencing for multiple, alternative manifestions of the item. As noted above, however, the resource element referenced by an item may itself comprise multiple files and resources. These files, however, would together comprise a single manifestation or presentation of the item.

The differences in the ways that METS and IMS-CP link structure with content also poses some potential challenges to incorporating library METS objects into learning objects. Where a single file manifests the content of a METS div, as in our simple example, the transformation is straightforward. The METS fptr simply becomes an IMSCP resource. (As described above, of course, the type of content file represented may pose problems if a browser cannot present this natively). If a METS fptr references multiple content files that must be played in parallel or in sequence, then it could still be mapped to an IMS-CP resource; but the problem of presentation must also be addressed. This might involve generating and adding to the list of resource files an html file that can "play" the content files in an appropriate manner, assuming that this can be determined. Where a METS div contains multiple fptr elements that represent alternative manifestations of the div element two transformation options present themselves. The transformation could create a separate IMS-CP item element to govern each of the available manifestations. In this case, each fptr would become a separate resource in the IMSCP output. Alternatively, the fptr elements representing alternative manifestations could be combined into a single resource, and an html file could be generated that would offer these as alternatives to the user.

[Raymond: Could xslt even accomplish such sophisticated transformations?]

A more obscure difference between METS' and IMS-CP's provisions for structure lies in the METS structLink element, which was mentioned above but not covered in our simple example. The structLink element allows for alternative, horizontal arrangements of the divisions of the structMap. Through it, any division at any level can be linked with any other division in the manner of hyperlinks. IMS-CP, at least at this point, makes no similar provision.

Linking Content with Descriptive and Administrative Metadata

Neither METS nor IMS-CP itself defines an administrative or descriptive metadata element set. As noted above, however, both allow these metadata to be expressed using elements defined in external standards. While neither IMS-CP nor METS defines nor prescribes descriptive and administrative metadata elements, the communities that use these standards are likely to favor the use of certain external schemas. The e-learning community, for example, strongly favors the use of IMSMD (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 descriptive metadata; museum communities will probably favor VRA (when a VRA schema becomes available). The e-Learning community would, presumably, favor using LOM in the context of METS when and if it had the occasion to create METS objects that represented learning packages. And LOM elements can, of course, be used freely in the context of METS dmdSec and amdSec elements.

Converting descriptive and administrative metadata elements from one metadata schema to another is likely to be somewhat problematic. For one thing, METS itself categorizes auxiliary metadata fairly finely. It not only distinguishes between descriptive metadata and administrative metadata; but further subdivides administrative metadata into technical metadata (shown in the simple example), rights metadata, source metadata and digital provenance metadata. IMS-CP, on the other hand, lumps auxiliary metadata into generic metadata elements that can appear in various contexts in an IMS-CP document. However, the external schemas used to express these metadata in an IMS-CP object may themselves categorize their supported metadata. Such is the case with IMSCP's preferred metadata schema, the IMSMD schema or LOM. It's metadata categories exceed METS' in number, even as they fail precisely to align with them. These metadata categories include: general, lifecycle, metametadata, technical, educational, rights, relation, annotation and classification.

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. The MODS descriptive metadata would probably map to LOM general metadata; however this would likely be fairly lossy, as LOM tends to be descriptive metadata poor by library standards. (The general metadata element does accommodate any element from any external schema, however; and the MODS elements with no analogues in LOM could be incorporated directly.) The MIX metadata would map to technical metadata, but also with pretty large losses. Still, it is not clear that such losses would be especially significant from a practical standpoint. The transformed METS object wouldn't be a replacement for the original, archival object, but 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.

Another major difference beween IMS-CP's and METS' handling of non-structural metadata has to do with the way that these metadata are referenced. In an IMS-CP document, descriptive and administrative metadata appear directly within the element to which they pertain. For example, such metadata can appear directly as part of an organization element, an item element, a resource element, or a file element. METS, on the other hand, segregates descriptive metadata and administrative metadata from both structure and content; these are expressed in their own dedicated, high-level elements in a METS document (the dmdSec and amdSec elements described in our simple example). In METS, divisions of the structMap as well as individual files simply reference the descriptive and administrative metadata sections pertinent to them.

In terms of practical implications, the differences between the way that METS and IMS-CP reference descriptive and administrative metadata probably don't have many practical implications. In incorporating a METS object into a IMSCP package, for example, the relevant descriptive and administrative metadata sections can simply be transferred to the appropriate manifest, item, or file elements.

Other Issues

METS' and IMS-CP's accommodation for external standards in some contexts, brings up another issue that may impact transformations between the two. METS restricts the contexts in which elements from other namespaces can be used to just two: the descriptive metadata section and the administrative metadata section. Nor does it allow attributes from "any" external namespace to be used in any context. IMS-CP, on the other hand is considerably more liberal in this regard, and allows any element and/or any attribute from external namespaces to be used in many contexts. This liberal approach makes transformations from METS to IMS-CP easier--at least on a superficial level--even as it makes IMS-CP to METS transformations potentially more difficult. In the end, the need for e-learning software to know what it is dealing with is likely to limit the extent to which implementers can take advantage of IMS-CP's "open hand". For example, the IMS-CP Best Practice Guidelines clearly state that IMSMD or LOM should be used for metadata whenever possible.

Another area of complexity in moving from METS to LOM has to do with the level or levels at which a METS document might be represented in a learning package. Most of the discussion this far has been based on the tacit assumption that a METS object would translate into an IMS-CP manifest. (Whether to a top level manifest or a sub-manifest would not much matter. This would depend on whether the METS object itself was to become a learning object in its entirety, or was to be incorporated into a larger learning object). Such a straightforward translation works well where the METS object represents a single library resource--a digital version of a manuscript diary, a scrapbook, or an oral history, for example). However, a METS object could also represent an intellectual entity, such as a 15-minute geographic quadrangle which aggregates various map editions, each with its own descriptive metadata. Each map edition, in this case, would be represented by its own div in the structMap. While this entire object could be be mapped to a single manifest, it might be desirable for each of the structMap divisions representing a different map edition to become a sub-manifest, so each could be used as an independent learning object.