IMS Content Packaging v1.2 Best Practice and Implementation Guide

IMS Content Packaging Best Practice and Implementation Guide

Version 1.2 Public Draft v2.0

Date Issued:	01 March 2007
Latest Version:	http://www.imsglobal.org/content/packaging/index.html
Supersedes:	IMS Content Packaging Best Practice and Implementation Guide v1.2 Internal Draft v2.0
Comments / Feedback:	http://www.imsglobal.org/community/forum/categories.cfm?catid=92

IPR and Distribution Notices Recipients of this document are requested to submit, with their comments, notification of any relevant patent claims or other intellectual property rights of which they may be aware that might be infringed by any implementation of the specification set forth in this document, and to provide supporting documentation. IMS takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on IMS's procedures with respect to rights in IMS specifications can be found at the IMS Intellectual Property Rights web page: http://www.imsglobal.org/ipr/imsipr_policyFinal.pdf. Copyright © 2007 IMS Global Learning Consortium. All Rights Reserved. Permission is granted to all parties to use excerpts from this document as needed in producing requests for proposals. Use of this specification to develop products or services is governed by the license with IMS found on the IMS website: http://www.imsglobal.org/license.html. The limited permissions granted above are perpetual and will not be revoked by IMS or its successors or assigns. THIS SPECIFICATION IS BEING OFFERED WITHOUT ANY WARRANTY WHATSOEVER, AND IN PARTICULAR, ANY WARRANTY OF NONINFRINGEMENT IS EXPRESSLY DISCLAIMED. ANY USE OF THIS SPECIFICATION SHALL BE MADE ENTIRELY AT THE IMPLEMENTER'S OWN RISK, AND NEITHER THE CONSORTIUM, NOR ANY OF ITS MEMBERS OR SUBMITTERS, SHALL HAVE ANY LIABILITY WHATSOEVER TO ANY IMPLEMENTER OR THIRD PARTY FOR ANY DAMAGES OF ANY NATURE WHATSOEVER, DIRECTLY OR INDIRECTLY, ARISING FROM THE USE OF THIS SPECIFICATION.

Intellectual property acknowledgements

“W3C is a trademark (registered in numerous countries) of the World Wide Web Consortium; marks of W3C are registered and held by its host institutions MIT, ERCIM, and Keio.

“SCORM” is a registered trademark of the Advanced Distributed Learning Initiative, Office of the Deputy Under Secretary of Defense (Readiness), Readiness and Training, 1E525, 4000 Defense Pentagon, Washington, D.C. 20301.

Table of contents

Intellectual property acknowledgements 2

1. Introduction 4

1.1 Scope and context 4

1.2 About this document 4

1.3 Structure of this document 4

1.4 Backwards and forwards compatibility 4

1.5 What’s new in CP 1.2? 5

1.6 Referencing external information – the IPointer element 5

2. References 7

3. Stylistic conventions, acronyms, and abbreviations 9

3.1 Stylistic conventions 9

3.2 Acronyms and abbreviations 9

4. Using content packages - use cases and practices 10

4.1 The classic package 10

4.2 Keeping control over resources after a package has been published 10

4.3 Aggregate content at an appropriate level of granularity 11

4.4 Specialized packages 13

4.5 Working with child-manifests and applying sequencing rules using the new IPointer mechanism 14

4.6 Packaging METS and other complex object encodings 16

4.7 Using alternative organization structures, such as topic maps 17

4.8 Working with alternative resources 18

4.9 Avoiding repeated lists of the same assets for different resources 20

4.10 Working with local and global identifiers 21

4.11 Support for multiple languages in titles 22

About this document 24

List of contributors 24

Revision history 25

Index 26

1. Introduction

It is expected that people using this document will already be somewhat familiar with the IMS Content Packaging Specification. For a concise overview of the specification, IMS Content Packaging Specification Primer version 1.2 [CP, 07d]¹ is recommended.

1.1 Scope and context

This document is informative.

The primary focus of this Best Practice and Implementation Guide is on sharing existing best practice and providing suggested practice for implementing the new functionality included in this version of the specification. IMS content packages have been commonly used in the e-Learning domain. It is hoped that the changes in this release can help broaden the use of content packaging into other domains. This guide focuses on the construction of instances of IMS manifest documents and the IMS content packages they define.

Applications that create IMS manifests and produce IMS content packages are referred to generically as IMS package writers in this guide. Similarly, applications that interpret IMS manifests and consume IMS content packages are referred to as IMS package readers. Finally, applications and systems that create and consume IMS content packages referred to as IMS packagers. IMS package writers and readers may be components of learning management systems (LMSs).

1.2 About this document

This guide presents examples of use cases and shows how they are satisfied by the IMS Content Packaging Specification. The use cases were contributed by various implementers and users of the specification and are based on years of practice. Though not exhaustive, the range of use cases presented here illustrate how the most common issues in the creation, management, and playback of learning material can be addressed with the specification.

1.3 Structure of this document

The structure of the rest of this document is:

2. References	Lists references to other standards and requests for comment cited in this document;
3. Stylistic conventions, acronyms, and abbreviations	Explains style conventions and expands acronyms and abbreviations used in this document;
4. Using content packages - use cases and practices	Descriptions of use cases that illustrate key areas of new and existing specification functionality.

1.4 Backwards and forwards compatibility

Given the widespread adoption of IMS Content Packaging and the proliferation of hundreds of thousands of IMS content packages, it is important that existing software components continue to process content packages they were designed to handle, and that new software components conforming to version 1.2 also process the older content packages as designed. Newer systems will need the ability to process the new extension objects introduced in v1.2 that enable linking and referencing behaviors. The functionality of these new extension objects are described in the Section 4 of this document, and normative descriptions are contained within the IMS Content Packaging Information Model [CP, 07a].

The new extension objects are defined in a separate namespace that leverages the extension points and semantics of IMS Content Packaging without affecting the existing IMS Content Packaging namespace. Version1.2 also separates the lists of vocabulary terms used by certain objects in the information model (and a dedicated new namespace) from the model itself. The details of which are contained the IMS GLC Specification Development Note 11: Vocabulary Definition, Registration, and Maintenance Procedures [SDN11, 06].

By taking this approach we hope that the best of the past is preserved as it provides a strong foundation for future growth without having to alter its structural integrity. (A detailed, normative description of backwards and forwards compatibility is contained in the IMS Content Packaging Information Model.)

1.5 What’s new in CP 1.2?

The new functionality and clarifications incorporated into v1.2 of IMS Content Packaging are:

a) The meanings of terms used within the specification have been clarified.

b) The use of (sub)manifests, now termed child-manifests, has been clarified and enhanced:

i) Interpretation of an item pointing to a child-manifest has been clarified.

ii) New functionality allowing components of child-manifests to be precisely referenced and interpreted has been introduced.

iii) Support for external child-manifests has been added.

d) Support for external referenced meta-data files has been introduced.

e) All internal vocabularies have been removed and they are now maintained through the IMS registration process and contained in the corresponding VDEX file (for the Type in Resource and Structure in Organization) [VDEX, 04c].

f) A new Resource type of “stand-alone” has been added that allows another package to be used as a piece of content.

g) The syntax and usage of the Base, Parameter, IsVisible, and Href Information Model classes has been clarified.

h) Support for variant Resource objects has been added. This includes support for alternative resources for accessible content.

i) Support for Organization and Item titles in multiple languages has been included.

j) Support for interchange packages that contain only content and interchange packages that have no local content files has been clarified.

1.6 Referencing external information – the IPointer element

Several communities of practice find benefit in reusing stored assets and parts of different presentation structures found in various instances of IMS manifest documents, whether they are stored inside of package interchange files (PIFs) or as an Extensible Markup Language (XML) document in a file storage system. With the new IPointer object, IMS Content Packaging v1.2 lets these communities reference information held in other IMS manifest documents in an interoperable way.

An IPointer makes an association between two manifests. An IMS package reader then relates the two manifests as indicated by the location of a linking object in one manifest and the target set of objects in the referenced manifest. The data is recovered from both documents for processing and storage.

For example, to associate a set of Item objects contained in another IMS manifest document with an Organization object in your own manifest, you (or your IMS package writer) would declare an IPointer child extension to Organization that points to the collection of Item objects in the remote or child-manifest. IPointer objects can be either local or remote i.e. contained within the PIF itself or within another package.

An IPointer may be placed only in certain other objects and target certain others. The Information Model defines the normative mechanisms for using IPointer. The following chart lists the valid locations and targets of an IPointer. The source and targets are identified by their object names.


Parent class of the IPointer class	Valid target node set for the IPointer class
Manifest	Manifest
Organizations	Organization
Organization	Item
Item	Item
Resources	Resource
ManifestMetadata	MetadataModel
Metadata	MetadataModel

Section 4 of this document illustrates a number of contextualized examples of how IPointer is used.

2. References

[ACCMD, 04a]	IMS AccessForAll Meta-data Information Model Version 1.0 Final Specification, J.Treviranus, A.Roberts, IMS GLC, Jul 2004. http://www.imsglobal.org/accessibility/accmdv1p0/imsaccmd_infov1p0.html
[CP, 07a]	IMS Content Packaging Information Model version 1.2 Public Draft v2.0, B.Nielsen, W.Kraan, N.Ward, IMS GLC, 2007. http://www.imsglobal.org/content/packaging/index.html
[CP, 07b]	IMS Content Packaging XML Binding version 1.2 Public Draft v2.0, B.Nielsen, W.Kraan, N.Ward, IMS GLC, 2007. http://www.imsglobal.org/content/packaging/index.html
[CP, 07d]	IMS Content Packaging Primer version 1.2 Public Draft v2.0, B.Nielsen, W.Kraan, N.Ward, IMS GLC, 2007. http://www.imsglobal.org/content/packaging/index.html
[EP, 05b]	IMS ePortfolio XML Binding version 1.0 Final Specification, C. Smythe, D.Cambridge, M.McKell, IMS GLC, 2005. http://www.imsglobal.org/ep/epv1p0/imsep_bindv1p0.html
[IEEE_LOM, 2002]	“1484.12.1-2002 IEEE Standard for Learning Object Metadata,” The Institute of Electrical and Electronics Engineers, Inc., 2002. ISBN:0-7381-3297-7.
[ISO/IEC 13250, 06]	ISO/IEC 13250–2:2006, “Information technology—Topic Maps—Part 2: Data Model.”
[ISO/IEC FDIS 21000, 05]	ISO/IEC FDIS 21000–2:2005, “Information Technology—Multimedia Framework—Part 2: Digital Item Declaration.”
[LD, 03a]	IMS Learning Design Information Model version 1.0 Final Specification, R.Koper, B.Olivier, T.Anderson, IMS GLC, 2003. http://www.imsglobal.org/learningdesign/ldv1p0/imsld_infov1p0.html
[LD, 03c]	IMS Learning Design Best Practice and Implementation Guide version 1.0 Final Specification, R. Koper, B. Olivier, T. Anderson, IMS GLC, 2003. http://www.imsglobal.org/learningdesign/ldv1p0/imsld_infov1p0.html
[LIP, 01a]	IMS Learner Information Packaging Information Model version 1.0 Final Specification, C.Smythe, F.Tansey, R.Robson, IMS GLC, 2001. http://www.imsglobal.org/profiles/lipinfo01.html
[METS]	“Metatdata Encoding & Transmission Standard” v. 1.6. http://www.loc.gov/standards/mets/
[QTI, 05a]	IMS Question and Test Interoperability Information Model – Version 2.0 Final Specification,” S.Lay, IMS GLC, 2005. http://www.imsglobal.org/question/qti_v2p0/imsqti_infov2p0.html
[QTI, 05b]	IMS Question and Test Interoperability XML Binding – Version 2.0 Final Specification, S.Lay, IMS GLC, 2005. http://www.imsglobal.org/question/qti_v2p0/imsqti_bindv2p0.html
[QTI, 05c]	IMS Question and Test Interoperability Integration Guide – Version 2.0 Final Specification, S.Lay, IMS GLC, 2005. http://www.imsglobal.org/question/qti_v2p0/imsqti_intgv2p0.html
[QTI, 05d]	IMS Question and Test Interoperability Meta-data and Usage Data – Version 2.0 Final Specification,” S.Lay, IMS GLC, 2005. http://www.imsglobal.org/question/qti_v2p0/imsqti_mdudv2p0.html
[RDF, 04]	“RDF/XML Syntax Specification (Revised),” W3C Recommendation 10 February 2004. http://www.w3.org/TR/rdf-syntax-grammar/
[RFC3986, 05]	“Uniform Resource Identifier (URI): Generic Syntax”. T. Berners-Lee, M. Suignard, Internet Engineering Task Force, Network Working Group, Request for Comments: 3986, January 2005. http://www.ietf.org/rfc/rfc3986.txt
[Schema, 04]	“XML Schema Part 2: Datatypes Second Edition,” W3C recommendation 28 October 2004. http://www.w3.org/TR/xmlschema-2/
[SDN11, 06]	IMS GLC Specification Development Note 11: Vocabulary Definition, Registration, and Maintenance Procedures, C.Smythe, v1.0, IMS GLC, July 2006.
[SS, 03c]	IMS Simple Sequencing Best Practice and Implementation Guide – Version 1.0 Final Specification,” M.Norton, C.Ostyn, A.Panar, B.Towle, IMS GLC, 2003. http://www.imsglobal.org/simplesequencing/ssv1p0/imsss_bestv1p0.html
[VDEX, 04c]	IMS Vocabulary Definition Exchange Best Practice and Implementation Guide, Version 1.0 Final Specification,” A.Cooper, IMS GLC, 2005. http://www.imsglobal.org/vdex/vdexv1p0/imsvdex_bestv1p0.html

3. Stylistic conventions, acronyms, and abbreviations

3.1 Stylistic conventions

The names of information model components and the tag names and their attribute names in the XML Schema binding are signified by a bold face font and capitalization. Whenever a common term occurs in body text that uses the same spelling, if the term is in bold face and capitalized, the reader should use the definition of the XML Binding [CP, 07b] of the Information Model component; if not, the reader should use the meaning or meanings typically specified in any standard dictionary of the English language or in common use in the e-Learning domain.

Example:

• “File” refers to the IMS Content Packaging object File.

• “file” may refer to a digital object identified by a Uniform Resource Identifier (URI) [RFC3986, 05], a physical object to hold papers, a physical object used to ablate a surface, etc.

3.2 Acronyms and abbreviations

LMS	learning management system
LOM	Learning Object Metadata
METS	Metadata Encoding and Transport Schema
PIF	package interchange file
SCO	sharable content object
SCORM	Sharable Content Object Reference Model
URI	Uniform Resource Identifier
XML	Extensible Markup Language
XSD	XML Schema Definition

4. Using content packages - use cases and practices

The use cases in this section illustrate key areas of the new and existing functionality of the IMS Content Packaging Specification by focussing on particular goals that users of the specification may have and then outlining how such goals can be achieved. The section is not exhaustive either in illustrating all features of the specification or in outlining all uses of a specific feature.

4.1 The classic package

A classic package typically includes all its resources in the PIF and uses a ZIP archive for its interchange format. It has only one level of manifest; no child-manifests are included. All Item objects are either declared or assumed to be visible. When material needs to be presented in more than one language or accessibility modality, two Organization objects tend to be included to separate them.

Content packages that comply with the most popular content-packaging profile, the Sharable Content Object Reference Model (SCORM), also typically follow this simple pattern. Where they differ from packages that follow other profiles is in the inclusion of meta-data: SCORM packages have package-level meta-data in a separate file that is referenced by the manifest. Other profiles typically include package-level meta-data inline in the manifest itself. Other differences include the support SCORM packages have for learner-to-content interaction tracking and, in SCORM 2004, IMS Simple Sequencing [SS, 03c].

Content packages of this type are likely to be most widely supported in various LMSs, and therefore, the most robust in interoperability


Level:	Primary use case
Actors:	Primary: Content authors Secondary: Content repositories
Stakeholders:	Content developers
Interest:	Content-development tool developers
Basic flow of events:	• The content author creates required learning content. • A PIF (usually a ZIP file) is created that includes an IMS manifest file and Web content resources only using a packaging tool such as RELOAD. • The PIF is deposited into repository and/or LMS.
Alternative flow of events:	• A content author creates SCORM compliant content. • A PIF is created including all SCORM compliant files, such as meta-data. • The PIF is deposited into a repository and/or LMS.
Success factors:	• All resources are contained within the PIF. • Packages are easily ingested by (legacy) compliant LMS systems.

Note: The “Simple_Manifest_Core” package in the set of examples that is included with this specification is a typical instance of a classic package. The example packages are available on the IMS website: http://www.imsglobal.org/content/packaging/index.html.

4.2 Keeping control over resources after a package has been published

Originally, a PIF, such as a ZIP archive, was intended to function solely as a means of transporting a course from one delivery environment (e.g., an LMS) to another. In practice, however, often a course is delivered from the archive after the archive has been installed in an LMS, thereby changing the nature and use of the PIF that contains the course from a transport mechanism to a content management device.

Though this does work, there are cases where it is desirable not to copy the content that is aggregated in a PIF, but have it reside on a central server. That way, access to the resources can be controlled more easily; content files can be updated at any point in time and use monitored more accurately by the publisher.


Level:	Primary use case
Actors:	Primary: Content authors Secondary: Content repositories and learners
Stakeholders:	Content managers
Interest:	Content authoring tool developers
Basic flow of events:	1) The content author searches for content files on a variety of repositories. 2) The content author composes a content package manifest that contains absolute references to the files in the repositories. 3) The content package manifest is exchanged to a variety of LMSs. 4) A learner accesses the content package manifest in an LMS. 5) Content files are retrieved from the remote repositories.
Alternative flow of events:	1) The content author creates new content files and deposits them in one or more repositories. 2) The content author composes a content package manifest that contains absolute references to the resources in the repositories. 3) References in the content package manifest are coded to uniquely identify the instances of the manifest that are sent to a specific LMS or organization. 4) An LMS can be granted or denied access to the resources by the repositories, depending on the construction of the references or some other authentication and authorization mechanism determined by the repository.
Success factors:	• The content owner can control access to content files at any point in time. • The content owner can monitor content file usage at any point in time. • Updates to content files are propagated automatically.

4.3 Aggregate content at an appropriate level of granularity

A SCORM sharable content object (SCO) is the lowest level at which a learner’s progress through a course can be tracked in SCORM. Therefore, SCOs often contain multiple pages of content. This makes it difficult to track precisely where a learner is in the material, which may, for example, impede re-opening a session at a later stage.

This issue can be addressed by aggregating SCOs in a level of packaging between the SCO and the course manifest. Such a level would also help with the management of content, because levels of aggregation can be separated more cleanly.

With some clarification, child-manifests can be used for this purpose. A child-manifest is a complete, subordinate manifest used by another manifest. A child-manifest describes a complete logical package that is part of the larger logical package defined by its parent manifest. A manifest may contain one or more child-manifests. Alternatively, from version 1.2 onwards, a manifest may include a reference to one or more child-manifests that are external to the parent manifest.


Level:	Primary use case
Actors:	Primary: Content authors Secondary: Content repositories
Stakeholders:	Stakeholder: Content developers
Interest:	Content development tool developers
Preconditions:	• All basic content files have already been authored. • The desired top-level content package has a comparatively wide scope; it aggregates several lessons' worth of material. • The content development tool supports child-manifests, either inline or referenced.
Basic flow of events:	1) Using a content development tool, a content author gathers basic content assets into independently reuseable collections. 2) The content author turns each of these collections into stand-alone logical packages that consist of single-page SCOs. 3) The content author aggregates the packages into a single logical package in one PIF.
Postconditions:	• The PIF contains one manifest document that contains the manifests of the aggregated packages as inline child-manifests (see examples, below). • Alternatively, the PIF contains a parent manifest that references child-manifests in subdirectories (see examples, below).
Success factors:	• The learner’s progress can be tracked at an appropriate level of granularity. • Content assets can be authored and managed at a level that makes re-use as easy as possible.

Child-manifest examples:

As an example of the use of child-manifests, suppose a content author was developing a lesson on camping based on three existing content packages: “How to construct a tent”, “How to start a fire”, and “How to make Smores”. The content author can either (a) include the manifests for these existing content packages in the new manifest, or (b) reference the existing manifests. Referenced child-manifests may be local to the interchange package or may be hosted separately (for example in a repository).

Figure 4.1 An example of the use of child-manifests.

4.4 Specialized packages

Specialized packages do not conform to a particular common pattern, but are similar in that they are used to convey very specific types of content, often inline, in the manifest. In practice, most of these packages are combinations of packages with other IMS specification content including:

• IMS ePortfolio [EP, 05b]

• IMS Learning Design [LD, 03a, c]

• IMS LIP [LIP, 01a]

• IMS QTI [QTI, 05a, b, c, d]

• IMS Simple Sequencing [SS, 03c]

In each of these cases, a significant part of the content that is described in the manifest is neither an external file, nor does its structure conform to the IMS Content Packaging Specification itself. Instead, at the core of these packages are descriptions of specific data in XML dialects. Content packaging merely provides a convenient way of aggregating such descriptions. Guidance on how each of these specifications uses content packaging is provided in the relevant IMS documentation set.

4.5 Working with child-manifests and applying sequencing rules using the new IPointer mechanism

Some specifications, such as IMS Simple Sequencing, add their own XML attributes to IMS Content Packaging's Item structure. Thought needs to be given as to how the information conveyed by those attributes affect the tree-like structures that can be built with Item objects in an Organization. Specifically, conflicts may exist among several sets of sequencing rules when a parent Manifest declares an association with one or more child Manifest objects and all contain sequencing instructions. This is conceptually no different from cases where sequencing rules exist on a parent Item that contains at least one child Item that also has sequencing rules. When using IPointer objects, a key point to bear in mind is whether an Item becomes a parent to a target Item in the external Manifest to which the IPointer points. This same logic applies to Manifest objects that contain internal references to child Manifest objects.


Level:	Primary use case
Actors:	Primary: Content authors and instructional designers Secondary: Content tool developers
Stakeholders:	Content developers
Preconditions:	• A requirement exists to construct a new content package with remediation. • The remediation should only be presented to the learner if the learner fails a quiz. Conceptually, the new design may look like Figure 4.2, where A represents the new content package, AA contains the quiz and X is the content package to be used for remediation, if the learner does not satisfy AA. Figure 4.2 Conceptual design of a new package. • The remote package (i.e., X, in Figure 4.2) cannot be altered by the content package author. • Conceptually, if an IMS package reader were to process the structure in Figure 4.2, the resulting structure should look like that in Figure 4.3. Figure 4.3 Conceptual design of processed structure.
Basic flow of events:	1) An instructional designer searches a repository and finds a content package that has suitable remediation. The instructional designer needs to apply a sequencing rule to X that says it should be displayed only if AA was not satisfied. 2) However, L1 is a linking object that will be completely replaced and cannot have associated sequencing rules associated, and applying rules to node A would not work either. Instead, the instructional designer adds a new Item that will be the parent of the external structure. 3) The instructional designer applies sequencing rule for X to the new parent (AB). Conceptually, the new content package would look like that in Figure 4.4. In order to make the situation shown in Figure 4.4 work, the instructional designer needs to introduce global variables. For AB to know if AA was satisfied, the satisfaction status of AA would need to be mapped to such a global variable, which can be read by AB. Figure 4.4 Conceptual design of the applied sequencing rule.
Success factors:	• References to external manifests are processed and displayed as the instructional designer originally intended, depending on learner responses. • Sequenced content is easily reused for a variety of instructional purposes.

4.6 Packaging METS and other complex object encodings

Several formats exist for aggregating complex digital objects in addition to IMS Content Packaging. In the library community, for example, Metadata Encoding and Transport Schema (METS) [METS] is widely used, while MPEG–21 DID [ISO/IEC FDIS 21000, 05] is used in many multimedia applications.

Ideally, complex digital objects should be transformable from one such format to another. However, this is not always possible or even desirable. Sometimes, it may be preferable to exchange a complex digital object in one format wrapped inside another. This approach can be used to exchange a complex digital object without affecting its native format, structural integrity, or semantic fidelity.


Level:	Primary use case
Actors:	Primary: Content managers Secondary: Content repositories
Stakeholders:	Copyright holders
Interest:	Content authoring tool developers
Preconditions:	• Repository 1 cannot export objects as IMS content packages. • The authoring tool and repository 2 are not designed to process any other types of complex digital objects other than IMS content packages.
Basic flow of events:	1) A complex digital object in METS format is exported from repository 1. 2) The content manager imports the METS object into an IMS Content Packaging tool as a resource. 3) The content manager checks the IMS resource-type vocabulary for the entry for METS objects and uses the IMS Content Packaging tool to add the correct value in the Type characteristic of the Resource object. 4) The content manager adds appropriate meta-data to a Metadata object to indicate the nature of the METS object. 5) The newly created IMS content package is imported into repository 2.
Alternative flow of events:	1) A complex digital object in format A is exported from repository 1. 2) The content manager imports the format A object into a IMS Content Packaging tool as a resource. 3) The content manager checks whether the IMS resource-type vocabulary has an entry for format A and finds that it does not. 4) Using the “IMS Vocabulary Definition, Registration & Maintenance Procedures” [SDN11, 06], the content manager composes a value and proposes it to the format A community for submission to the IMS resourcetype vocabulary. 5) The content manager uses the IMS Content Packaging tool to add the new value in the Type characteristic of the Resource object. 6) The content manager adds appropriate meta-data to a Metadata object to indicate the nature of the format A object. 7) The newly created IMS content package is imported into repository 2.
Success factors:	• The structural integrity of the non-IMS Content Packaging complex digital object is preserved in the exchange between repository 1 and 2. • Non-IMS Content Packaging complex digital objects are successfully processed by tools that have been designed to process IMS Content Packaging, only.

4.7 Using alternative organization structures, such as topic maps

Traditionally, IMS Content Packaging has provided one default Structure type: “hierarchical”. “Hierarchical” is intended to support table-of-contents type structures to learning resources. However, many implementers have use cases for other means of organizing resources that are not defined by IMS Content Packaging. Typically, these cases are driven by a need to provide richer or more complex learning activities. Examples of alternative organizations are directed graphs, flat lists, and standardized structures, such as ISO 13250-2 Topic Maps [ISO/IEC 13250, 06].


Level:	Primary use case
Actors:	Primary: Content authors Secondary: Learners
Stakeholders:	Content authoring tool developers
Interest:	Content repository tool developers
Preconditions:	• A content author wants to structure learning resources using structures other than the one defined by the IMS CP specification. • The content has to function in an environment where not all software tools will support the desired alternative organization structures.
Basic flow of events:	1) The content author aggregates content files for an IMS content package. 2) Using a specialized authoring tool, the content author creates an alternative organization structure in a separate document. 3) Using a standard IMS Content Packaging authoring tool, the content author defines both the aggregated content files and the alternative organization structure as resources and creates a conventional table-of-contents style organization. 4) The content author makes the IMS content package available in a suitable system, such as a repository.
Alternative flow of events I:	1) The content author aggregates content files for an IMS content package. 2) Using a specialized authoring tool, the content author creates an alternative organization structure in a separate document. The alternative organization has direct references to the content files. 3) Using a standard IMS Content Packaging authoring tool, the content author inserts the alternative organization structure under its own namespace in a separate Organization object within an Organizations object in a Manifest. 4) The content author also creates a conventional table-of-contents style Organization and concurrent Resources objects. The conventional Organization is defined as the default. 5) The content author makes the IMS content package available in a suitable system, such as a repository.
Alternative flow of events II:	1) The content author aggregates content files for an IMS content package. 2) Using an authoring tool that implements both IMS Content Packaging and an alternative organization structure, the content author creations an alternative organization structure with an Organization object in the Manifest. The alternative Organization references resources in the Resources object. 3) Using the same authoring tool, the content author also creates a conventional table-of-contents style Organization and concurrent Resources objects. The conventional Organization is defined as the default. 4) The content author makes the IMD content package available in a suitable system, such as a repository.
Success factors:	• The content packages with alternative organization structures continue to function as conventional IMS content packages for conventional IMS Content Packaging readers and repositories. Systems designed to process alternative organization structures locate those structures and make them available to learners in addition to, or instead of, the conventional organization structures.

4.8 Working with alternative resources

Because the access requirements of different learners vary, the accessibility properties of educational content needs to be described such that a package processing tool can make a good decision about which content to render for a particular learner. Content that is described in this way can reside in more than one place. What this means is that, at or close to run time, a primary media learning resource or component may be replaced or supplemented. The replacement or supplementation may relate to a resource or to a file or to files that form part of the resource. When working with a resource, accessibility meta-data [ACCMD, 04a] about that resource will commonly describe its properties including the location of any replacement or supplementary resources. In IMS AccessForAll Meta-data, each alternative resource that is associated with a primary resource can be found at the end of a URI that can point to a location internal to the system or external to it.

The mechanism provided is that a Resource object can have one or more associated variant Resource objects. Association is via a dedicated Variant object within a Resource that references the alternative Resource within the same Manifest. Where the alternative resource is external, it is referenced indirectly via the internal associated resource. The relationship is logically equivalent to containment of the variant resource within the one for which it is a variant.

The IMS Content Packaging Specification places no constraints on how the mechanism is used to structure resources, and several different ways to do this are possible, some of which are shown in the examples.


Level:	Primary use case
Actors:	Primary: Content authors Secondary: LMSs and learners
Stakeholders:	Content authoring tool developers
Interest:	Content repository and LMS tool developers
Preconditions:	• All distributed resource alternatives have been pulled into the Manifest when the resource set was packaged, so that the package is complete and the content stands alone. • The LMS has access to the learner's accessibility preferences. • The LMS can parse and process accessibility meta-data.
Basic flow of events:	1) The content author gathers course material that is available in multiple languages, in this case English and French as shown in Figure 4.5. 2) Using an authoring tool, the content author describes the English resource illustrated in lines 10 – 31 of Figure 4.5. Because the resource is referenced directly from an Item object, it is the default resource. 3) The content author creates an alternative for this resource in French (described in lines 32 – 53). 4) The content author creates a Variant object to reference the French Resource (lines 23 – 29). 5) The content author creates the required Metadata object that describes the context of use of the alternative resource; in this case it says that the alternative is the French version. 6) On completion, the content author submits the package to a repository. 7) On playback, the LMS compares language accessibility preferences of the learner (i.e. French preferred) to the accessibility meta-data in the package. 8) The LMS presents the variant resource to the Learner.
Alternative flow of events:	1) The content author gathers course material that is available in multiple languages; in this case English and French. 2) Using an authoring tool, the content author describes the English resource in one Manifest of one package. 3) The content author creates an alternative for this resource in French in a Manifest in a different package. 4) The content author creates a Variant object to reference an IPointer object that identifies the French Resource in the external package. 5) The content author creates the required Metadata object for the Variant object that describes the context of use of the alternative; in this case it says that the alternative is the French version. 6) In the package with the French Resource, the content author creates a Variant object to reference an IPointer object that identifies the English Resource in the other package. 7) The content author creates the required Metadata object for the alternative Resource object that describes the context of use of the alternative; in this case it says that the alternative is the English version. 8) On completion, the content author submits both packages to a repository. 9) On playback, the LMS compares language accessibility preferences of the learner (i.e. French preferred) to the accessibility meta-data in the package. 10) The LMS processes the external package indicated by the IPointer object, and presents the desired variant resource to the learner.
Success factors:	• Alternative resources are supported (e.g., a version of a resource with modified display characteristics to support vision-impaired users). • Specific vocabulary terms for accessibility resources are supported for the Type characteristic of the Resource object.

Figure 4.5 A simple example for specifying alternative languages.

Variant references may be from any Resource object to any peer Resource object (child of the same parent). A closer look at this example reveals that in fact the example contains not only the reference shown in Figure 4.5, but also the reverse reference, which may be a useful mechanism in some scenarios.

Any Resource can contain zero or more such references. This enables scenarios, such as

• A Resource has many Variant objects referenced within it.

• A referenced Variant (the alternative resource) has its own Variant objects.

• Variant objects could be hierarchically structured.

• A set of Resource objects, such as might be described with RDF [RDF, 04], could have arbitrarily-structured Variant references.

4.9 Avoiding repeated lists of the same assets for different resources

Many users and content vendors prefer that learning resources have a similar look and feel. This is easily achieved by re-using the same images and styling information for all resources in a content package. However, because Resource objects are required to list all the content files that a resource uses, this approach has the disadvantage that it can lead to a lot of repetition in the Resources section of the Manifest. Therefore, the IMS Content Packaging Specification has a feature that lets content authors list commonly used content files once and reference that list from many different Resource objects.


Level:	Primary use case
Actors:	Primary: Content authors Secondary: IMS–compliant content-aggregation tools
Stakeholders:	Content authoring tool developers and LMS developers
Preconditions:	• For a significant number of LMSs targeted by the content author, dereferencing internal references and integrating the structures they point to into local Resource structures must be less costly than the storing and parsing repetitive XML.
Basic flow of events:	1) The content author creates Web-page resources for an IMS content package in a single style, making use of a single set of recurring images, CSS style sheets, and JavaScript files. 2) When the content author imports the content files into the content-aggregation tool, the tool recognizes the repetition of the same set of files in multiple resources. 3) The content-aggregation tool groups the repeatedly used set of content files into one Resource object, which is not referenced by any Item object, and references that Resource from any other Resource objects that make use of the set via the Dependency object. 4) The LMS dereferences the Dependency references to the Resource that holds the repeatedly used set of files every time such a Dependency is declared in other Resource objects. 5) The LMS integrates the content files declared by the local Resource and the Resource referred to by the Dependency into a single representation for the learner.
Alternative flow of events:	1) The content author creates Web-page resources in a consistent style in an LMS. 2) On completion, the authoring tool rationalizes the number of content files required to render the resources down to one copy of each. 3) The content-aggregation tool groups those files that are used repeatedly into one Resource object, which is not referenced by any Item object, and references that Resource from any other Resource objects that make use of the set via the Dependency object. 4) The LMS dereferences the Dependency references to the Resource that holds the repeatedly used set of files every time such a Dependency is declared in other resources. 5) The LMS integrates the content files declared by the local Resource and the Resource referred to by the Dependency into a single representation for the learner.
Success factors:	• All content files are declared only once in a single Manifest. • The content files that are aggregated into one Resource are successfully marshalled at rendering time. • Disk space, processing cycles, and processing time are saved compared to declaring content files repeatedly.

4.10 Working with local and global identifiers

IMS Content Packaging uses the Identifier object to identify parts of a manifest. This local-identifier feature is used primarily to associate Item objects with Resources. Because the Identifier attribute is defined by the W3C's XML Schema specification [Schema, 04] as unique within each document, many tools can easily ensure that objects in a Manifest are unique and that references to them are unambiguous. The cost of this useful feature is that the form of the local identifier has a set of constrains. Most notably, these constraints preclude the use of many common forms of global identifiers, such as Uniform Resource Names (URNs). As a consequence, the Identifier object is not a good way to store globally unique identifiers for a logical package or any part thereof.

A much better way to store such global identifiers is in the Metadata object. Unlike the structural role of a local identifier, a globally unique identifier can be seen as a type of meta-data; it conveys information about the content package, but does not play a role in the package itself. In addition, Metadata can easily accommodate the wide variety of globally unique identifier syntaxes, semantics, and data models that different communities use. Moreover, Metadata can contain an unlimited number of globally unique identifier instances in almost any form.


Level:	Primary use case
Actors:	Primary: Content authors Secondary: IMS-compliant content-aggregation tools, content managers, and repositories
Stakeholders:	Content authoring tool, LMS, and content repository tool developers
Preconditions:	• The content author's community has defined a Learning Object Metadata (LOM) [IEEE_LOM, 2002] profile that mandates the use of globally unique identifiers of the “handle” type to all content packages.
Basic flow of events:	1) The content author aggregates a number of content files using a content-aggregation tool. 2) When the content author imports the content files into the content-aggregation tool, the tool assigns locally unique identifiers to the Item and Resource objects, and records those in ID attributes. 3) The content author uses the content-aggregation tool to author a LOM record that describes the new content package. 4) The content author enters a “handle” identifier in the LOM record. 5) While importing, the repository parses the LOM record and exposes the 'handle' identifier in its search and harvesting interfaces.
Success factors:	• Local identifier references are unambiguous and robust. • Any type or multiplicity of globally unique identifiers can be associated with the content package or a part thereof.

4.11 Support for multiple languages in titles

The Title object defined for Organization and Item is just a label. It does not specify a language. Nor can the Title be repeated to accommodate multiple languages. Yet learning material that is intended to be used in multilingual environments or material used in language teaching requires the use of titles in more than one language or at least an indication of what language a title is in.

Language-sensitive titles can be added into a Manifest as extensions from another namespace as children of an Organization or Item object. For example, if one wanted to express representations of the same title in multiple languages, one could use the title element from the LOM standard. No restrictions exist on how many instances of LOM’s title element are included in an Item, Manifest, or Organization, and LOM’s title element also has a means of indicating what language the title is in.


Level:	Primary use case
Actors:	Primary: Content authors and content translators Secondary: Content developers and content repositories
Stakeholders:	LMSs
Interest:	Content tool developers
Preconditions:	• The content package is intended to be used by English, French, and Spanish speaking learners. • LMSs are aware of the language preferences of their users. • LMSs can parse the LOM title element.
Basic flow of events:	1) A content author creates a content package English. 2) The package is passed to a content translator to be translated into French. 3) The translator opens the package, and adds the title in French, and inserts the French title into an IMS Meta-data 'title' tag, with an xml:lang attribute value of “fr-FR”, as shown in Figure 4.6. Figure 4.6 An Item with a default Title in English, and supplementary titles in French and Spanish. 4) The translator declares the IMS Meta-data namespace identifier and namespace name in the Manifest, typically as part of the attributes for the root Manifest object as illustrated in Figure 4.7. Figure 4.7 An IMS Meta-data namespace declaration in the Manifest element. 5) The content package is then translated into Spanish, which repeats steps 3, 4, and 5 above to add titles in Spanish. 6) The LMS compares the language preference of the learner (Spanish) and renders the package’s titles in Spanish.
Success factors:	• Learners see titles in a language that most closely matches their preferences.

About this document

the document properties
Title	IMS Content Packaging Best Practice and Implementation Guide
Editors	Colin Smythe (IMS), Boyd Nielsen (Independent)
Co-chairs	Wilbert Kraan (JISC/CETIS), Jan Poston Day (Blackboard), Nigel Ward (DEST)
Version	v1.2 (Public Draft v2.0)
Version Date	01 March 2007
Status	Public Draft v2.0
Summary	This document describes the IMS Content Packaging v1.2 Information Model objects, their relationships, and purpose. It also defines selected behaviors of software components that create or process IMS content packages and IMS manifest documents.
Revision Information	21 February 2007
Purpose	This document is circulated for public comment. This document should be used to introduce the IMS Content Packaging v1.2 specification. Organizations are encouraged to implement this version of the specification and to provide feedback on their experience.
Document Location	http://www.imsglobal.org/content/packaging/index.html

List of contributors

The following individuals contributed to the development of this document:

Name	Organization	Name	Organization
Martin Bayly	WebCT, Canada	Steve Hirst	Pearson Education, USA
Bill Bilic	WebCT, Canada	Scott Lewis	ADL, USA
Kerry Blinco	DEST, Australia	Wilbert Kraan	CETIS / JISC, UK
Jennifer Brooks	ADL, USA	Sheila MacNeill	CETIS / JISC, UK
Daniel Burgos	UNFOLD / OUNL, NL	Boyd Nielsen	Independent, USA
Adam Cooper	Tribal Technology, UK	Allyn Radford	HarvestRoad, Australia
Jan Poston Day	Blackboard, USA	Colin Smythe	IMS, UK
Philip Dodds	ADL, USA	Schawn Thropp	ADL, USA
Andy Heath	Independent, UK	Nigel Ward	DEST, Australia

Revision history

Version No.	Release Date	Comments
Final 1.0	25 May 2000	The initial release of the CP specification.
Final 1.1	19 April 2001	The first revision of the CP specification.
Final 1.1.1	23 May 2001	The first maintenance release of CP v1.1. There were no functional additions.
Final 1.1.2	08 August 2001	The second maintenance release of CP v1.1. There were no functional additions.
Final 1.1.3	12 June 2003	The third maintenance release of CP v1.1. There were no functional additions. The issues resolved were sourced from the IMS maintenance database.
Final 1.1.4	04 October 2004	The fourth maintenance release of CP v1.1. There were no functional additions. The issues resolved were sourced from the IMS maintenance database.
Public Draft 1.2 v1.0	21 November 2005	The initial v1.2 Public Draft version that was released to solicit initial feedback on the proposed changes in CP v1.2.
Internal Draft 1.2 v2.0	01 March 2007	The final v1.2 Internal Draft version that is issued to promote feedback of experience of implementation.

Index

Accessibility 7, 10, 18, 19, 20

Aggregation 11, 21, 22

Behavior 4, 24

Best Practice Guide 1, 4, 7, 8, 24

Binding 7, 9

child-manifest 5, 6, 10, 11, 12, 13, 14

Content Package 4, 11, 12, 15, 16, 17, 18, 20, 21, 22, 23, 24

CSS 21

Extension 4, 5, 6

IEEE 7, 22

IMS Specifications

AccessForAll Meta-data 7, 18

Content Packaging 1, 4, 5, 7, 9, 10, 14, 16, 17, 18, 19, 21, 24, 25

Learner Information Package 7, 13

Question and Test Interoperability 7, 13

Vocabulary Definition Exchange 5, 8

Information Model 4, 5, 6, 7, 9, 24

interchange package 5, 12

Interoperability 10

IPointer 5, 6, 14, 19

ISO 7, 17

Learning 4, 9, 10, 17, 18, 20, 22

LMS 9, 10, 11, 19, 21, 22, 23

logical package 11, 12, 21

LOM 7, 9, 22

Manifest 4, 5, 6, 10, 11, 12, 13, 14, 21, 24

Meta-data 5, 10, 17, 18, 19, 22

Namespace 5, 18, 22, 23

Normative 4, 5, 6

package interchange file 5, 9

package reader 4, 5, 15

package writer 4, 6

Preferences 19, 22, 23

Profile 10, 22

Records 22

reference 5, 11, 12, 19, 20, 21

Repositories 10, 11, 12, 16, 18, 22

Resource 17, 18, 19, 20

Resources 5, 10, 11, 17, 18, 19, 20, 21

SCORM 2, 9, 10, 11

Sequencing 8, 10, 14

Standards 4

Structure 4, 14, 15, 16, 17, 18, 19

XML 5, 7, 8, 9, 14, 21

XSD 9

Citations in brackets correspond to those in Section 2.

IMS Global Learning Consortium, Inc. (“IMS GLC”) is publishing the information contained in this document (“Specification”) for purposes of scientific, experimental, and scholarly collaboration only.
IMS GLC makes no warranty or representation regarding the accuracy or completeness of the Specification.
This material is provided on an “As Is” and “As Available” basis.
The Specification is at all times subject to change and revision without notice.
It is your sole responsibility to evaluate the usefulness, accuracy, and completeness of the Specification as it relates to you.
IMS GLC would appreciate receiving your comments and suggestions.
Please contact IMS GLC through our website at http://www.imsglobal.org
Please refer to Document Name: IMS Content Packaging v1.2 Best Practice and Implementation Guide Public Draft v2.0
Date: 1 March 2007