MetsImsInteropPaper

Achieving the necessary level of interoperability between library and educational/instructional evironments to enable such high level of interactive access to content is a challenge that the library and educational technology communities are only beginning to jointly address. [cite MacLean/Lynch white paper] Among the many barriers impeding interoperability between libraries and educational tools is the difference in specifications commonly used for the exchange of digital objects and metadata. XML interoperability specifications proposed within the library/digital repository community (e.g., METS) and within the educational technology domain (IMS, SCORM) are geared to the exchange of content within that specific community. By themselves, these standards do not address the need for cross-community transmission of data.

METS, which is maintained in the Network Development and MARC Standards Office of the Library of Congress and is being developed as an initiative of the Digital Library Federation, attempts to provide an encoding format for managing digital materials within a digital library, for exchanging materials between digital libraries, and for disseminating the digital content and associated metadata to the end user.

The IMS Content Packaging (IMS-CP) specification, one of several XML based specifications created under the auspices of the IMS to facilitate interoperability among educational environments, plays a parallel role in the educational technology community. "The IMS Content Packaging (CP) Information Model describes data structures that are used to provide interoperability of Internet based content with content creation tools, learning management systems (LMS), and run time environments. The objective of the IMS CP Information Model is to define a standardized set of structures that can be used to exchange content. These structures provide the basis for standardized data bindings that allow software developers and implementers to create instructional materials that interoperate across authoring tools, LMSs, and run time environments that have been developed independently by various software developers." (http://www.imsglobal.org/content/packaging/cpv1p1p3/imscp_infov1p1p3.html#1519896)

Of the range of scenarios that would have be to accounted for in full interoperability between library and educational tools, we consider, in this paper, the case study of absorbing METS objects representing library resources into an IMS-CP learning package. The adoption of METS by a significant number of libraries, musuems, and archives -- not an unlikely prospect -- to mark up their content would result in many thousands of interesting, high quality corpus of METS objects ready for incorporation into learning tools. IMS-CP is the leading contender for a standard file format among learning content (if any should completely dominate). [This might be too strong of a claim.]

[I might want to strengthen the introduction through adding concrete scenarios. The collections hosted by libraries are a silo of sort; how about if we want to grab some material and use it elsewhere? Journal articles already paid for by the libraries that ed tech people might end up paying again.... Image collections for the looking -- but what if I want to comment it for my students....Resources List Interop....]

In this paper, we describe how METS-encoded library content, can be converted into digital objects for IMS-compliant systems through XSLT-based crosswalks. We compare the conceptual models behind METS and IMS-CP. We document the design and limitations of an XSLT-based translation, and relate the crosswalks to other techniques to enhance interoperability.

Once we have introduced the key features of METS, we will look at a potential IMSCP encoding of this same object. What might this object look like if we wanted to absorb it into an e-learning content package so that it could become e-learning course material? This IMS-CP encoding will introduce the key elements and features of the IMS-CP standard.

The simple METS and IMSCP documents thus introduced and representing the same digital content will provide the departure point for a more in depth analysis of the similarities and differences of the two standards. This analysis will describe the high level similarities between the two standards as demonstrated by the sample encodings; but will then go on beyond the simple examples to explore how the standards diverge, particularly as they are likely to be applied by the research library (METS) and e-learning communities (IMSCP). This analysis will look at both structural and conceptual differences between the two standards as applied.

Finally, we will propose a xslt crosswalk intended to serve as a preliminary tool for incorporating library METS objects into learning packages. (MetsToImsCrossWalk)

Readers should note that METS and IMSCP are both fairly flexible standards, and this paper doesn't attempt to deal with all possibilities either for a METS encoding or and IMS-CP encoding. On the METS side we start with encoding options a research library is likely to use when representing digital versions of their primary source materials in METS. However, there is no standard "library" METS encoding or profile, at least at this point, and even within this relatively small community, practices are likely to vary fairly widely. Nor is there a standard encoding for learning packages, although various groups are exploring more narrowly defined profiles and implementations of IMSCP. When and if profiles emerge that narrow the range of METS and IMSCP options and practices for certain applications, we would expect it to be possible to write profile specific transformations between METS and IMSCP objects that have fewer ambiguities. In the meantime, this paper does not attempt to suggest a definitive encoding for library METS objects nor for IMSCP objects. And at best it can suggest a preliminary, provisional and highly contingent means for absorbing library METS objects into IMSCP packages.

The assumption that METS and IMSCP are not competing standards underlies this article, and our purpose is not to appraise their relative merits. Rather, we assume that they are standards that attempt to meet the needs of different communities. Our main purpose is to surface the concepts and begin to establish a vocabulary that can facilitate communication and collaboration between the e-learning and library communities, which after all, share many common goals.

The simple document is the Saunders METS document (link?) boiled down to simple form : 2 jpgs, simple DM, one piece of image techMD (accurate description?)

The XML for the simple METS document

• http://sunsite.berkeley.edu/xmlrepos/metstest/SimpleMETS.xml

• (local copy)

[SimpleMetsDocument/LocalSimpleMetsXml]

The rendition of the document through the METS viewer: http://sunsite.berkeley.edu/xdlib/servlet/archobj?DOCCHOICE=http%3A%2F%2Fsunsite.berkeley.edu%2Fxmlrepos%2Fmetstest%2FSimpleMETS.xml&submit1=Submit+Query

How to learn about METS?

• METS: An Overview & Tutorial

• other articles in this journal

• studying the METS schema

Below are the top level elements that can comprise a METS document.

mets

• metsHdr

• dmdSec

• amdSec

• fileSec

• structMap

• structLink

• behaviorSec

structure and content in METS

Of these top level elements, we'll ignore the metsHdr, behaviorSec and structLink for now. (These have important functions for some applications; but are not germane to our simple example.) Instead, we'll look first at the structMap and fileSec--the structural heart of the METS document.

The structMap is, in fact, the only required element of a METS document. The structMap analyzes the structure of the digital object into a hierarchically arranged sequence of divisions (or div elements). In the case of the simple example above, the structMap simply analyzes the digital object represented--a dictation from the Hubert Howe Bancroft collection--into a sequence of two physical pages. [A div element could in fact represent a logical division (a chapter of a book for example) instead of a physical division, as in our example. Thus, a structMap could represent a logical structure, a physical structure, or some combination of the two. It could for example divide a book into chapters (logical) and a chapter into pages (physical)]

The structMap goes on to link the structural divisions of the digital object--in this case the two individual pages--to the file(s) that manifest the content of these divisions. It does this by means of one or more file pointers (fptr elements), which are subsidiary to the division to which they pertain. Each fptr element points to a file element in the fileSec that represents a resource that manifests the division. In the case of our simple example, only one manifestation of each page is available; so each page division contains a single fptr element that points to the single file that manifests its content. It does so by means of an FILEID attribute that identifies the pertinent file element.

The fileSec, then, mainly provides an inventory of the files that comprise the content of the digital object represented. Each file element in the fileSec can point to the external resource it represents via a URI. The fileSec organizes the file elements into groups governed by fileGrp elements which can be nested. The above example organizes all of the file elements into a single fileGrp because all files share the same format and purpose. They are medium resolution jpegs intended for "reference" use. Thumbnail images (i.e, gifs) and tiff master images, had they also been present, would have appeared in separate fileGrp elements. But in fact METS does not provide firm guidelines on how METS implementors should group files.

administrative and descriptive metadata elements in METS

Quotes from which document?

Two important components of our simple METS object remain to be described: descriptive metadata and administrative metadata.

The optional dmdSec or descriptive metadata section of a METS document records descriptive metadata pertinent to the digital object. METS does not itself define a descriptive metadata element set; and our example records descriptive metadata using elements defined in an external schema called MODS devised and maintained by the Library of Congress. (citations). The root division of the structMap points to this dmdSec via a DMDID attribute. A METS document can contain more than one dmdSec, and divisions of the structMap at any level can reference any pertinent dmdSec elements.

The amdSec or administrative metadata section of a METS document records administrative metadata pertinent to the digital object. METS provides for four distinct types of administrative metadata, but our example demonstrates just one of these: techMD, or technical metadata about the digital content files. As is the case with descriptive metadata, METS does not itself define an administrative metadata element set. Thus our example records the image technical metadata using elements defined in the MIX schema maintained by the Library of Congress. (citations). Each file in the fileSec of our example points to the techMd section that pertains to it via an ADMID attribute. Divisions of the structMap can also point to administrative metadata, such as rights metadata, as appropriate.

raw xml version

[SimpleImscpDocumentXml]

This document is calculated via XSLT (by use of a METS to IMS-CP (no metadata) XSLT)

Schematic structure of the imsmanifest

imsmanifest

• organizations

• organization

• resources

• resource

This is a simple version -- where the imsmanifest is the complete learning package itself. Resource files can accompany the document and the entire package zipped up together.

Notes:

1. there can be more than one organization

2. metadata can be attached to any tag

Structural comparison

There is a representation of hierarchy in both systems. There are folders that hold other stuff and the items themselves.

We need to work the materials from BrainDumpRickBeaubien into this narrative. That is, we need to go through point-by-point RB's analysis and make sure that we are on the same page. We might need to make reference to the relevant source documents:

• METS schema (current schema -- 1.2 for now, 1.2 Documentation, METS Overview and Tutorial, Proposed 1.3 schema)

• IMS-CP schema (v 1.1.3 schema 1.1.3 or other location of schema 1.1.3? Information Model, XML Binding, Best Practices, IMS-CP FAQs )

Rough mappings:

From what I can understand, neither IMS-CP nor METS mandate a particular visual representation (after all, they are XML content formats), there probably are implicit visual representations. (I think that this is where the whole notion of profiling comes in -- a possibly huge and messy topic).

IMS-CP supports the notion of a content package, in which the imsmanifest.xml is a table of contents. One can ship the package of materials around. In METS, one can also embed content via the FContent tag (Actually, I think in METS, one can embed content.) (oh -- so that means to do a full METS to IMS-CP translation, we have to unpack FContent tags....I might just say that's out of the scope of this piece of work.)

I should mention SCORM here, which builds upon IMS-CP, IMS-MD + AICC extensions to give some run-time behavior (http://www.adlnet.org/index.cfm?fuseaction=scorm12) METS has behaviors to give some run time behavior [I need to write more about this here) My high level analysis of similarities and differences (A full comparison of the run-time models of METS and SCORM -- do we want to tackle that?)

How these comparisons are expressed in XSLT?

More info at MetsToImsCrossWalk. Let's look at a specific crosswalk and document it:

[

[MetsToImsCrossWalkV1]

Areas of improvement for this crosswalk -- see post on Raymond's blog.

• ims:manifest/@identifier is currently hardcoded to MANIFEST01 -- is it appropriate instead to map mets:mets/@id to ims:manifest/@identifier?

• V1 does not account for the fact that mets:structMap is repeatable -- assumes only one mets:structMap

• V1 does not currently map mets:fileSec to imscp:organization

• V1 does not handle the following

• mets:structLink

• mets:behaviorSec

• mets:FContent

Issues of metadata

There are no metadata standards mandated in either IMS or METS. The best practices for both do recommend metadata frameworks that are appropriate for their respective communities -- and these standards are different. (IEEE-LOM for IMS). (MODS and MIX for METS?)

METS supports more of the idea of different type of metadata: administrative vs descriptive vs structural. The concepts of different type of metadata are different in IMS. LOM has sections in its metadata -- that probably have rough equivalences to the admin/descriptive/structual concept.

METS supports the embedding of non-XML data and metadata (including binaries, encoded in Base64. non-XML data can definitely be part of an IMS-CP content package. I don't think that non-XML metadata is supported in IMS.

If the goal is to support complete to-and-fro lossless translation, I think one will be disappointed. ( It might be possible in that one might be able to wrap an object of one standard in the structure of another but one would not be able to meaningfully use the materials. If one wants to move the content structure from one system into another, the content-packaging ideas are roughly consonant.

How do we write the XSLT crosswalks so that they can be easily interpreted, consumed, and generalized by projects such as the SimileProject?

Where are some concrete places to plugin these crosswalks so that we can get some practical feedback on their usefulness and also insight into how to revise the crosswalks for future use?