An Overview of Common Cartridge

Continued coverage of IMS. There's an IMS Common Cartridge testing tool, but they don't want to enable access without registration.


Kevin Riley

We got a bunch of content vendors and providers together to see what they supported, based on customer demand. We found quite a lot in common. The Common Cartridge format is based on fairly mature technologies that have been availble for a few years.

The features in version one:
- we have cartridge metadata
- also, resource metadata - we wanted to be able to earmark resources, to state whether it's visible (or not) to an instructor or learner
- there support for rich content - med stuff, media files, but also application files - eg. MS Word
- integrated assessments - we used th question types that are actually deployed: multiple choice, true/false, essay, fill in the blank, pattern match
- discussion forum integration
- authorization for protected content - not DRM but something very light

Common Cartridge enhancements, version 1.1:
- extends role metadata to include a mentor
- great demand for multilingual support; we've adopted the alt.variant element recommended by the accessibility group
- for assessment, we included instructions for completing the assessment that could be viewed by the user - the QTI rubric was integrated for that purpose
- integration with LTI (Learning Technology Integrattion)
- association of learning outcomes with particular resources
- human-readable lesson plans, specifc to the instructor

The building blogs of the specification are:
- the Dublin Core element set as the basis for the carridge
- LOM as the in formation mode for the cartridge metadata, based on LOM schema loose binding
- packaging - is a profile of Content Packaging version 1.2
- testing - IMS QTI 1.2.1 (this was based on what publishers are actually using)
- IMS authroization web service 1.0
- basic LTI, which is a provile of IMS LTI 2.0

What does the spec do: it defines a concrete unabiguous set fo schema for building cartridges, and describes additional constraints to be applied to the schemas, leading to two main lvels of complianc and a third for cartridges containing only QTI.

We don't define a run-time -- that is entirely the province of the platform. What we define is the data expcted by the platform; the platform has to deliver them.

- diagram of LMS run-time environment

Potential future:

- integration with web applications
- also with e-books
- also with services in their own library

Common Cartridge metadata resides in the manifest. It is not order-sensitive. Any content included in the cartridg requiring a special player must be described in the metadata, so users are forewarned.

Resource metadata optimally restricts who a resource is visible to. Curriculum metadata identified learning requirements. There has been much discussion of this. Instead of tagging the cartridge directly from tokens of values of a curriculum model, we refer to the originating domain, identify the coverage or region, and then for this specific resource we list one or more URLs of standards relevant to that resource.

There are conceptually four difference thypes of content that can be in a cartridge:
- learner experience data - the learning material, what we would normally think of
- supplemental resources, that can be pulled in by the instructor
- operational data - eg., authorization
- descriptive metadata

There is a content hierarchy:
lowest: HTML, application files (Word, PDF), static content
next: web links - content accessed from the web at runtime, which can b updated after the cartridge has been distributed
next: XML - eg., QTI, etc. which can b managed by the LMS
highest: LTI - other technologies - ebooks, virtual labs, multi-user simulations, etc.

The content we don't use - aftr a vigorous use of Ockham;'s razor:
- multiple organizations
- CP version-specific objects
- sub-manifests
- inter-package linking

Things that were added:
- a group-level folder that shared content had to be placed into, to avoid ad hoc links
- in a Common Cartridge there are no learning objects - there are learning application objcts

- diagram - schematic of common cartridge, taken from model of content packaging

- diagram - cartridge web content links - illustrating how cartridge can refer to shared resources, but not each other

Only one question bank is permitted in a cartridge. There's no order in a question bank. It only supports the limited question types mentioned above. The question bank cannot be referenced by any of the resources in the cartridge.

LTI - is a means to launch or reference an external tool, but also to gather outcomes. Basic LTI v 1.0 is hot off the press.

Also, eBook integration. We have publishers selling books to learners, and also making cartridges availabel to isntructors, to help them use the book. The professor installs the cartridge in the LMS, and then via LTI the LMS can access the book. So now we can (eg) refer the learner to the particular section in the eBook relevant to the place they are in the course.

The way we do this is via the hosted service for eBooks (because you can't guarante the student is at the right machine to access the downloaded eBook).

Finally, there are two forms of authroization: authorization on import - is this a valid site, do they have a valid license? And then, is there authorization on use.

How do we achioeve adoption? We have the spec, we have a mchanism for regional and national profiles, and we have a profil registry and a compliance program. We also have a mechanim for support and collaboration, for example, the CC Alliance.

On the profiling side: education is nver going to be uniform around the world. So our standards have to support local practice. So we have to allow customization, even if it's only around language and vocabularies. In some cases this may require functional change, but we don't encourage that.

The compliance program - members of the alliance who pass the test can use 'compliance' marks. It is a self-test. We have an automated test tool (downloadable free of charge). Anybody can test a cartridge - there's nowhere to hide. On the platform side we have run-time tests that are designed to exercise every known functionality. Also, we have some known-error cartridges.

The cartridge test tool is run on the destop, run by Java, available on tn home page of the IMS website. You can batch-load cartridges for testing. It generates a test report for each cartridge.