straightforward manifest to account for the files in the package, and another
approach to listing the content from various organizational or structural
points of view.
to attach relevant metadata.
providing for recursive package structures.
pointing to information found in files external to the manifest.
|More emphasis on
file as file, independent of its use in any given component or resource.
(typically) captured per file.
|Various kinds of
metadata captured to own metadata area of manifest; connected to relevant
content via @ID/@IDREFs
is maintained in slightly more abstract manner; subsequent users of the METS
file may well author new softwares to read and render this content, in new
|More emphasis on
resource components, "playable" pieces that cohere, have purpose,
organized, manifest-wise, within the resource listing.
|Metadata can be
placed off of several different elements in the manifest; more open to
interpretation of its meaning, relevance.
of the IMS content package more likely to use in some mode as intended when
packaged (using those organized resources).
Not to say complete disaggregation couldn't occur, but less frequent
|Here shown some
initial thoughts on mapping from METS onto IMS-CP. This was devised for the current working
group in updating the IMS-CP specification to version 1.2 (along with current
work on Common Cartridge, a subset of the IMS CP for use between publishing
houses and university CLEs)
|NEXT SLIDE SEGUE
|We elected to go
with IMS-CP, as that really would better serve OCW's needs with various
audiences other than the DSpace archive: faculty, other CLEs, other OCW
institutions, education partners, translation partners. Also a
simple downloadable course .ZIP was yet another benefit of this (for
general site visitors).