Dr. Tom’s Guide to Content Packaging

Thomas D. Wason, Ph.D. (aka Dr. Tom) http://www.tomwason.com [Home] wason@mindspring.com One of the Dr. Tom Guides

Purpose of Document

The purpose of this document is to introduce the concepts in the IMS Content Packaging specification and summarize the technical model. The IMS Content Packaging Specification describes how collections of resources that constitute a learning resource are wrapped up into a single package for transport. The package includes information that instructs a learning management system on how to instantiate the content as a learning resource. NOTE: This document was originally written as a guide to IMS content packaging. As there is a lot of similarlity with the SCORM packaging, it provides guidance for that specification, too.

Document Information

Contents

1. What is an "IMS Content Package"?
2. The IMS Content Packaging Specification
3. How is an IMS Content Package made?
4. Technical Summary
5. Appendix

"What is an IMS Content Package"?

You have created a wonderful instructional module, made up of many bits and pieces.  Now how do you send it to a learning management system?  And even worse, how do you send it to a learning management system through a broker?  How do you move an instructional unit, with all of its parts, from one place to another over the Internet?  You wrap all of parts--the content--up into a single file or package.  At the receiving end, you unwrap the package, restoring all of the individual parts.  The answer to these problem is: Content Packaging. 

Defining the package is the purpose of the IMS Content Packaging specification.  You can find the exact specification on the IMS website at:

An IMS content package is a collection of files that have been stored together in a single ZIP, JAR, CAB or TAR file.  Content is a collection of material that comprises a unit of instruction.  Let us use the architectural analogy of building a house.

The house will be built of materials, e.g., bricks, lumber, windows, doors, HVAC (heating, ventilating and air-conditioning) unit and so forth.  Some of these materials are raw materials (i.e., bricks, lumber); some are assemblies of raw materials that have been arranged in a useful manner (i.e., HVAC unit, windows).  Blueprints are the plans that builders will follow for using the materials and assemblies to build the house.  There is also a procedure for actually creating the house, the project plan.

The process of bundling involves putting all of the contents into a single compressed file, such as a ZIP, JAR, CAB or TAR file.  Using the package in a learning management system (LMS) is analogous to the process of creating the house by using the resources in the manner prescribed by the blueprints according to the project plan.  A learning management system (LMS) provides a learning experience by unwrapping the content package and delivering it according to the manifest.  The manifest details the resources available, their organization, and provides extra information (meta-data) on the package and its constituents.

A builder may create a subdevelopment that constitutes a packet that includes some master plan and its resources, and a collection of individual houses.  When making several houses at one time to create a subdevelopment, the builder can collect all of the materials into one storage yard for convenience.  The IMS Content Packaging specifications uses this concept to collect all of the resources used within a package into one place in the manifest file. 

The IMS Content Packaging Specification

An IMS Content Package is a collection of files that have been bound together into a single file that is usually compressed. The IMS Content Packaging specification defines the details of the manifest file that is contained in the collection file.  The manifest file explains how to unwrap the package for use.  The manifest may also include meta-data to provide a detailed description of the entire package.   The IMS meta-data specification is used in the Content Packaging specification for this purpose. 

The IMS Content Packing specification consists of three documents:

1. Information Model
2. XML Binding
3. Best Practices Guide

Information Model

The Information Model describes the logical structure of a content package.  It defines the components, and what is required and what is optional.  The manifest is a required part of a content package, as it provides the key to unwrapping the package. 

The use of the IMS Meta-Data specification is referenced as the descriptive meta-data for the package and for resources.  A component of the package includes information about the organization of the resources such as a table of contents.  More than one organization may be included.  The organization may be used as a default sequence for use of the contents.

XML Binding

The Information Model describes in detail the components and organization of a Content Package in logical terms.  A binding is a well-defined way of writing down the information that defines a package. 

By analogy, an architect uses standard symbols and conventions when making a house plan.  The IMS specification reduces this to practice in a technical language, in this case, W3C's XML 1.0 that is a “textual zed serialization of structured information”. [A lot of fancy words that says you can take something apart, send it through a narrow pipe, and put it back together again at the other end.] The key to the IMS Content Packaging is the manifest file.  Each content package must contain a manifest file with a specified name, imsmanifest.xml.  The structure and content of the manifest file are detailed in the IMS Content Packaging Specification.  User the XML binding to create a manifest file that must be included in the zipped content package file so that it can be transported over the Internet or other network.  Only the manifest file needs to be in XML.  A learning Management System "unwraps" or unzips the content package and organizes the content according to the manifest. A DTD, XDR or XML-Schema control file may guide the creation and validation of the manifest file. 

Best Practices Guide

The Best Practices guide provides information about the use of content packages in a learning management system, creation of content packages and examples of manifests.  It also describes various levels of conformance to the specification.  The Best Practices Guide is a good place to go when you are considering creating content packages. 

How is an IMS Content Package made?

To make an IMS Content Package:

• Design and produce the instructional materials. This is the business of instructional designers, and is outside the scope of the specification.
• Organize the materials for use, usually in a table of contents. 
• Create a meta-data XML record using the IMS meta-data specification to describe the resources in the manifest.
• Import the directly into the manifest file or provide a pointer to it. 
• Create a manifest file with an XML editor (e.g., XML Pro, XML Instance, XML Spy, XML Notepad.   Look at http://www.xml.com/ for more suggestions.). 
• Aggregate, or “zip” the manifest file and all of the resources into a single file, usually compressed. 

Technical Summary

Introduction

This outlines the structure of an IMS content package.  A content package is a combined, and usually compressed, file.  It is a complete unit: a package that can be transmitted as a whole.  The combination (or “aggregation”) can be accomplished via a zip, tar, jar, cab or equivalent file structure. The compression may enhance transmission.  This summary does not contain a complete description of the information model or the XML binding.  It gives you a background for a deeper reading of the specification.

The purpose of Content Package is that it allows a collection of resources and the plans for the use of those resources to be bundled into a single file and shipped over the internet from one system to another.  This allows the recipient to use the resources in the manner intended by the sender.  A Content Package has two main parts:

1. Manifest
2. Physical Resources

The content package not only provides a mechanism for delivering an aggregation of resources, it provides methods for accessing the resources in an organized manner.  This is accomplished by defined relationships within the package.  All of the relationships originate within the manifest file.  These relationships are illustrated below.

This illustration is intended only as an over view.  The relationships are described below. 

Manifest

The single required manifest portion of the package is expressed in XML (W3C version 1.0) in the IMS Content Packaging Specification version 1.0.  I’ll use XML here to illustrate the structures defined by the specifications, as XML is designed to create data structures. 

Warning:  To be a valid IMS Content Package, the package must contain a manifest file that must have the name of imsmanifest.xml. 

The manifest contains the information necessary to access the resources.  Therefore an IMS compliant learning management system must find the imsmanifest.xml file in order to access the resources.  There can be only one top-level manifest element.  The manifest file contains four sections:

• Meta-Data
• Organizations
• Resources
• (Sub-)Manifests

The basic structure of the manifest is:

manifest
	metadata
	organizations
	resources
	(sub-)manifests

This translates into XML as:

<?xml version="1.0"?>
<!DOCTYPE manifest SYSTEM "IMS_CONTENTv1p0.dtd">
<manifest identifier="MANIFEST1">
    <metadata></metadata>
	<organizations></organizations>
	<resources></resources>
	<manifest></manifest>
</manifest>

The XML control document for this particular instance is a DTD, "IMS_CONTENTv1p0.dtd".  The details of the DOCTYPE declaration are outside of the scope of this summary.  The top level, or root, element is manifest.  The manifest element contains an attribute, identifier, which must have a value that is unique within the entire manifest file.  In this case, the identifier is arbitrarily defined as “MANFIEST1”.  This pattern of unique identifiers must be observed throughout the entire manifest for all identifier attribute values.  Note that all element names (or “tokens”) are in lower case.  IMS has adopted this form as consistent with the practices of W3C.  Except for manifest, each of the tags above contains no content.  Each is illustrated with separate opening and closing tags for clarity.  Now let’s see what might actually be within those tags. 

Meta-data

The single optional metadata section contains information about the schema and version of the binding that this instance conforms to. You may include only one meta-data section in a manifest; and it is optional.  The meta-data section of the manifest file also incorporates IMS meta-data to describe the entire package.  The IMS meta-data is structured data, and it is well-matched to the capabilities of XML.  The IMS meta-data is expressed as a binding in XML.  The meta-data section may also contain other meta-data labels, such as Dublin Core.  An example of the meta-data section with a small portion of meta-data, expressed as an XML fragment of the entire manifest file as shown below:

<metadata>
    <schema>IMS Content</schema>
        <schemaversion>1.0</schemaversion>
        < imsmd:record 
            xmlns:imsmd="http://www.imsproject.org/xml/IMS_METADATAv1p1ns.dtd">
            <imsmd:general>
                <imsmd:title>
                    <imsmd:langstring lang="en_US">
                        Simple Manifest
                    </imsmd:langstring>
                </imsmd:title>
            </imsmd:general>
        </imsmd:record>
    <dc:date xmlns:dc="http://purl.org/dc/">
        2000-07-17
    </dc:date>
</metadata>

Note that the langstring element contains a lang attribute.  This attribute specifies the human language of the text enclosed in the tag set, in this case, US English.  The lang attribute is a standard XML 1.0 attribute. 

All of the IMS meta-data is contained within the element record.  The XML namespace prefix of “imsmd:” is used to qualify all of the IMS meta-data elements.  Namespace qualification serves to uniquely define an element with reference to a particular source.  The element must obey the constraints defined by that source.  The namespace prefix is defined using the “xmlns:imsmd=” notation.  The namespace prefix can alternatively be defined in the top--or root--element, manifest, rather than in the more local element, record, as shown. Top-level collection of all namespace definitions may allow processing alternatives in the future.  The details of namespacing are outside of the scope of this summary, but I have introduced them to give you an awareness of them.  Consider it “consciousness raising”. 

Tip: See http://www.w3.org/TR/REC-xml-names/ for more namespace information. 

Meta-data may also be external to the manifest.  You may included through the xinclude:include reference:

<xinclude:include href="moremetadata.xml"/>

Xinclude is a W3C draft standard.  You can use the external meta-data to simplify validation of the manifest, as the meta-data itself is thus external to the manifest.  You may include it in the content package, however.  We wanted to give you options so you could do what worked best for you. 

Organizations and Resources

Both an organizations and a resources section are required in a manifest.  These work together to provide a planned access to the physical resources, which may be included in the package or be external to it.

The organizational structures (e.g., table of contents with its items) point to resource elements that point to the physical resources.  A resource block may point to more than one physical resource. 

Organization

The single organizations section defines one or more arrangements of the resources.  The IMS Content Packaging Specification provides a table of contents as a common structure. You do not necessarily have to use it. We included it because it is a very commonly used method for organizing materials.  Other structures may be included in the organizations section of the manifest file, including replacing the table of contents. 

Warning: One organization must be designated as the default organization. 

A table of contents provides a useful default. The organizing structures do not point directly to the resources, but refer instead to a common resource referencing set in the resources section, below. 

<organizations default="TOC2">
    <tableofcontents identifier="TOC2" title="default">
        <item identifier="TOC2_ITEM1" identifierref="RESOURCE1" title="Lesson 1">
            <item identifier="TOC2_ITEM2" identifierref="RESOURCE3" title="Introduction 1"/>
            <item identifier="TOC2_ITEM3" identifierref="RESOURCE2" title="Content 1"/>
            <item identifier="TOC2_ITEM4" identifierref="RESOURCE4" title="Summary 1"/>
        </item> 
    </tableofcontents>
</organizations>

In this example organization is a tableofcontents with an identifier of TOC2 that contains an item TOC2_ITEM1.  This item, TOC_ITEM1 contains three items, TOC2_ITEM2, TOC2_ITEM3, and TOC2_ITEM4.

There may be several organizing structures within the organization.  For example, a package on history may be organized by geographic region and by chronology.  Several organizations may use the same resources.  The resources section mediates the actual access to the physical resources.  The organizations do not point directly to the physical resources; they point to resource elements that point to the physical resources.  A TOC item element may have attributes of identifier, identifierref, and title. 

Resources

The single, mandatory resources section provides references to the physical resources.  The organizations point to resource elements in the resources section. The resource elements point to the physical resources.  The organizations sections make use of the identifierref attribute to point to resources that are defined in the resources section.  For example, item TOC2_ITEM1 points to RESOURCE1 using the identifierref attribute.  Again, all identifiers must conform to the XML 1.0 ID standard, and they must be unique within the entire manifest file.  Having one resource point to all of the physical resource could create a simple collection.  

The physical resource files may be included in the aggregated content package, including directory structures.  Resources can define a base attribute defining a relative offset path for its contained resource files.

<:resources base="Masterlesson/">
<:resource identifier="RESOURCE1" 
type="webcontent" 
href="lesson1.htm">
<:file href="lesson1.htm"/>
<:/resource>
	  . . .
<:/resources>

The resource element points to the actual physical resources that may include files, URLs and manifests. 

Sub-Manifests

The top-level manifest may contain other manifests that have the same status as physical resources for the resource elements.  These sub-manifests have exactly the same structure as the top-level manifest.  In this way one organizational structure (e.g., a table of contents) can incorporate other manifests into its structure.  All of the files (physical resources) used by all of the manifests are aggregated in common, but the manifest file structures are maintained.  If several manifests within a package use the same file (e.g., and illustration), then that file does not need to be duplicated. 

Warning: Care must be taken to ensure that the identifier and identifierref values in all sub-manifests do not conflict with each other or with the top level values: all must be unique within the imsmanifest.xml file. 

Each manifest must have a unique identifier. 

<:?xml version="1.0"?>
<:!DOCTYPE manifest SYSTEM "IMS_CONTENTv1p0.dtd"-
<:manifest xmlns="IMS_CONTENTv1p0.dtd" 
xmlns:imsmd="http://www.imsproject.org/metadata" 
identifier="MANIFEST1">
	 <:metadata>. . .<:/metadata>
	 <:organizations>. . .<:/organizations>
	 <:resources>. . .<:/resources>

    <:manifest identifier="MANIFEST2">
        <:metadata>. . .<:/metadata>

        <:organizations default="TOC2">
            <:tableofcontents identifier="TOC2" title="default">. . .
            <:/tableofcontents>
        <:/organizations>

        <:resources>
            <:resource identifier="RESOURCE1">. . .<:/resource>
         . . .
        <:/resources>
    <:/manifest>
<:/manifest>

Physical Resources

The physical resources constitute the actual deliverable content of the package.  They may exist within the package or they may be external to the package, typically at a URL.  The IMS specification does not define how the physical resources that are included in the package are to be bundled into the package file.  I suggest you create a single directory structure where all of the files are placed.  The directory structure is wrapped up, and compressed, into the zip (or jar, tar or cab) file with the directory structure intact.  Upon the recipient’s unwrapping (uncompressing) of the package file—poof!--the entire directory structure is created and populated with the physical files.  The files are referenced within the directory structure by the resources in the manifest(s).  Each manifest’s resource block may assign a base offset as the starting point within the directory structure. 

Appendix

Sample XML manifest file:

<:?xml version="1.0"?>
<:!DOCTYPE manifest SYSTEM "IMS_CONTENTv1p0.dtd">
<:manifest xmlns="IMS_CONTENTv1p0.dtd" 
xmlns:imsmd="http://www.imsproject.org/metadata" 
identifier="MANIFEST1">
    <:metadata>
        <:schema>IMS Content<:/schema>
        <:schemaversion>1.0<:/schemaversion>
        <:imsmd:record>
            <:imsmd:general>
                <:imsmd:title>
                    <:imsmd:langstring lang="en_US">Simple Manifest<:/imsmd:langstring>
                <:/imsmd:title>
            <:/imsmd:general>
        <:/imsmd:record>
    <:/metadata>

    <:organizations default="TOC1">
        <:tableofcontents identifier="TOC1" title="default">
            <:item identifier="TOC1_ITEM1" identifierref="TOC2" title="Lesson 1"/>
            <:item identifier="TOC1_ITEM2" identifierref="TOC3" title="Lesson 2"/>
            <:item identifier="TOC1_ITEM3" identifierref="TOC4" title="Lesson 3"/>
        <:/tableofcontents>
    <:/organizations>

    <:resources>
        <:manifestref identifierref="MANIFEST2"/>
        <:manifestref identifierref="MANIFEST3"/>
        <:manifestref identifierref="MANIFEST4"/>
    <:/resources>

    <:manifest identifier="MANIFEST2">
        <:metadata>
            <:schema>IMS Content<:/schema>
            <:schemaversion>1.0<:/schemaversion>
            <:imsmd:record xmlns:imsmd="http://www.imsproject.org/metadata">
                <:imsmd:general>
                    <:imsmd:title>
                        <:imsmd:langstring lang="en_US">Lesson1<:/imsmd:langstring>
                    <:/imsmd:title>
                <:/imsmd:general>
            <:/imsmd:record>
        <:/metadata>

        <:organizations default="TOC2">
            <:tableofcontents identifier="TOC2" title="default">
                <:item   identifier="TOC2_ITEM1" 
identifierref="RESOURCE1" 
title="Lesson 1">
                    <:item identifier="TOC2_ITEM2" 
  identifierref="RESOURCE3" 
  title="Introduction 1"/>
                    <:item identifier="TOC2_ITEM3" 
  identifierref="RESOURCE2" 
title="Content 1"/>
                    <:item identifier="TOC2_ITEM4" 
  identifierref="RESOURCE4" 
  title="Summary 1"/>
                <:/item> 
            <:/tableofcontents>
        <:/organizations>

        <:resources>
            <:resource identifier="RESOURCE1" 
    type="webcontent" 
    href="lesson1.htm">
                <:file href="lesson1.htm"/>
            <:/resource>

            <:resource identifier="RESOURCE2" 
    type="webcontent" 
    href="intro1.htm">
                <:file href="intro1.htm"/>
            <:/resource>

            <:resource identifier="RESOURCE3" 
    type="webcontent" 
    href="content1.htm">
                <:file href="content1.htm"/>
            <:/resource>

            <:resource identifier="RESOURCE4" 
    type="webcontent" 
    href="summary1.htm">
                <:file href="summary1.htm"/>
            <:/resource>
        <:/resources>
    <:/manifest>

    <:manifest identifier="MANIFEST3">
        <:metadata>
            <:schema>IMS Content<:/schema>
            <:schemaversion>1.0<:/schemaversion>
            <:imsmd:record>
                <:imsmd:general>
                    <:imsmd:title>
                        <:imsmd:langstring lang="en_US">Lesson2<:/ imsmd:langstring>
                    <:/imsmd:title>
                <:/imsmd:general>
            <:/imsmd:record>
        <:/metadata>

        <:organizations default="TOC3">
            <:tableofcontents identifier="TOC3" 
     title="default">
                <:item identifier="TOC3_ITEM1" 
    identifierref="RESOURCE5" 
    title="Lesson 2">
                    <:item identifier="TOC3_ITEM2" 
  identifierref="RESOURCE6" 
  title="Introduction 2"/>
                    <:item identifier="TOC3_ITEM3" 
  identifierref="RESOURCE7" 
  title="Content 2"/>
                    <:item identifier="TOC3_ITEM4" 
  identifierref="RESOURCE8" 
  title="Summary 2"/>
                <:/item> 
            <:/tableofcontents>
        <:/organizations>

        <:resources>
            <:resource identifier="RESOURCE5" 
    type="webcontent" 
    href="lesson2.htm">
                <:file href="lesson2.htm"/>
            <:/resource>

            <:resource identifier="RESOURCE6" 
    type="webcontent" 
    href="intro2.htm">
                <:file href="intro2.htm"/>
            <:/resource>

            <:resource identifier="RESOURCE7" 
    type="webcontent" 
    href="content2.htm">
                <:file href="content2.htm"/>
            <:/resource>

            <:resource identifier="RESOURCE8" 
    type="webcontent" 
    href="summary2.htm">
                <:file href="summary2.htm"/>
            <:/resource>
        <:/resources>
    <:/manifest>

    <:manifest identifier="MANIFEST4">
        <:metadata>
            <:schema>IMS Content<:/schema>
            <:schemaversion>1.0<:/schemaversion>
            <:imsmd:record>
                <: imsmd:general>
                    <:imsmd:title>
                        <:imsmd:langstring lang="en_US">Lesson1<:/imsmd:langstring>
                    <:/imsmd:title>
                <:/imsmd:general>
            <:/imsmd:record>
        <:/metadata>

        <:organizations default="TOC4">
            <:tableofcontents identifier="TOC4" 
     title="default">
                <:item identifier="TOC4_ITEM1" 
    identifierref="RESOURCE9" 
    title="Lesson 1">
                    <:item identifier="TOC4_ITEM2" 
  identifierref="RESOURCE10" 
  title="Introduction 1"/>
                    <:item identifier="TOC4_ITEM3" 
  identifierref="RESOURCE11" 
  title="Content 1"/>
                    <:item identifier="TOC4_ITEM4" 
  identifierref="RESOURCE12"
  title="Summary 1"/>
                <:/item> 
            <:/tableofcontents>
        <:/organizations>

        <:resources>
            <:resource identifier="RESOURCE9"
    type="webcontent" 
    href="lesson3.htm">
                <:file href="lesson3.htm"/>
            <:/resource>

            <:resource identifier="RESOURCE10" 
    type="webcontent" 
    href="intro3.htm">
                <:file href="intro3.htm"/>
            <:/resource>

            <:resource identifier="RESOURCE11" 
    type="webcontent" 
    href="content3.htm">
                <:file href="content3.htm"/>
            <:/resource>

            <:resource identifier="RESOURCE12" 
    type="webcontent" 
    href="summary3.htm">
                <:file href="summary3.htm"/>
            <:/resource>
        <:/resources>
    <:/manifest>
<:/manifest>

Author: