A guide detailing how to create IMS Content Packages that are compatible with eduCommons.
This document details how to write IMS Content packages that are compatible with
eduCommons 2.1.0-final.
eduCommons uses version 1.2 of the IMS Content Packaging Specification. XML Schemas
for the specification can be found at http://imsglobal.org/xsd/imscp_v1p2.xsd and
http://imsglobal.org/xsd/imsmd_v1p2p4.xsd.
In the process of writing software that exports eduCommons supported IMS Content
Packages, it is highly recommended to use a validating XML editor and associated
schema files to check manifests for validity. eduCommons in some circumstances
will expect import manifests to meet validity standards, and the chances of
creating content packages that will work with eduCommons will be greatly increased.
eduCommons provides XML schema files on export for this purpose.
An XML schema file for eduCommons specific metadata can be found both online
(http://cosl.usu.edu/xsd/educommonsv1.1.xsd) and in eduCommons IMS Content
Packages.
To use the IMS Content Package XML schemas along with the eduCommons schema, make
sure your manifest specifies these packages and the relevant XML schema informtation
in the header. Below is an example of attributes which you may want to set on the
manifest tag.
xmlns="http://www.imsglobal.org/xsd/imscp_v1p1"
xmlns:eduCommons="http://cosl.usu.edu/xsd/eduCommonsv1.1"
xmlns:imsmd="http://www.imsglobal.org/xsd/imsmd_v1p2"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.imsglobal.org/xsd/imscp_v1p1 imscp_v1p2.xsd
http://www.imsglobal.org/xsd/imsmd_v1p2 imsmd_v1p2p4.xsd
http://cosl.usu.edu/xsd/eduCommonsv1.1 eduCommonsv1.1.xsd">
The IMS CP specification allows content packages to be extended using custom
metadata fields. eduCommons takes advantage of this to pass information that
does not fit into the LOM metadata format. Using the eduCommons extensions
requires the use of the eduCommons namespace in typical XML style.
eduCommons can read values from colon prefixed tags, or by using an xmlns
attribute on the top level eduCommons tag as shown below. Although both methods
are acceptable, the latter is preferred due to the fact that it makes the
corresponding XML more readable. Examples in the rest of the document will
be given in this format.
<manifest xmlns="....
xmlns:eduCommons="http://cosl.usu.edu/xsd/eduCommonsv1.1"
...
>
...
<eduCommons:eduCommons>
<eduComons:objectType>
Course
</eduCommons:objectType>
</eduCommons:eduCommons>
...
</manifest>
<eduCommons xmlns="http://cosl.usu.edu/xsd/eduCommonsv1.1">
<objectType>
Course
</objectType>
</eduCommons>
eduCommons will add links to objects in the left hand navigation of a course
view through the use of the organizations section in an IMS content package.
Becuase IMS CP standards support multiple organizations within a manifest,
eduCommons will use the default organization if it is specified. If no default
is specified eduCommons will read from the first organization tag listed
in the organizations section.
eduCommons gets its left hand navigation information from the isVisible attribute
on items. If this attribute is present and set to true, eduCommons will mark
this object as displayable in the left hand navigation. eduCommons will order
left hand navigation items based on the ordering of item tags within the
organization section.
An example of how to write an organizations section that eduCommons can read is
given below. Notice how the default organization section is set, and how unique
identifiers are used to link the item to the resource in the resources section.
The IMS CP specification requires that any id value use be unique to the manifest,
otherwise anything can be used.
<oganizations default="ORG1234">
<organization identifier="ORG1234">
<item identifier="ITM1234" identifierref="RES1234" isVisible="true">
<title>
Hello World
</title>
</item>
...
</organization>
</organizations>
<resources>
<resource identifier="RES1234">
...
</resource>
...
</resources>
eduCommons stores metadata for every content object entered into its repository.
In order to write a content package that eduCommons can process, it is necessary
to include a metadata section for every resource specified in the manifest.
It is also important to note that eduCommons currently will not read top level
metadata sections, nor will it support nested manifests within IMS Content
Packages. Support for nested manifests, and non eduCommons content packages
are currently listed as future eduCommons features.
An example of how to lay out your manifest section to be eduCommons friendly is
given below.
<manifest>
<organizations>
<organization>
</organization>
</organizations>
<metadata>
... any metadata specified here is ignored by eduCommons ...
</metadata>
<resources>
<resource>
<metadata>
... metadata specified here is used to apply metadata
to content objects ...
</metadata>
<file href=" ... used by eduCommons to name the content object
and find it within the package ..."/>
</resource>
...
</resources>
<manifest>
... nested manifests are not currently supported by eduCommons,
but may be at a future date ...
</manifest>
</manifest>
The eduCommons course object is different to other content objects in that
it has extra requirements. eduCommons represents courses as both a document
and a container for content objects. This means in an IMS Manifest it will
appear as a content object that is connected to an HTML file (used to
render the front course page) and is also a folder which contains all content
related to the course. It appears in the manifest as both.
Courses also have additional metadata associated with them in the eduCommons
specific metadata section. This extra metadata is specified in a further section
below.
Each manifest should specify a course object as the initial resource.
You can create example IMS packages by building content in eduCommons and then
use the IMS export functionality to export them. This feature can be useful
in figuring out how to write compatible packages.
Metadata and Import/Export
