SCORM Primer

SCORM is short for Sharable Content Object Reference Model. It consists of a set of specifications and standards (Note: Technically it consists of profiles of standards or specifications) maintained and documented by the Advanced Distributed Learning initiative. SCORM addresses interoperability between content and the platforms that deliver the content. SCORM derives from work done by the Aviation Industry CBT Committee (AICC), the IMS Global Learning Consortium, the IEEE Learning Technology Standards committee and others. SCORM is widely adopted by learning management systems, learning content management systems, authoring environment, assessment engines and course management systems. (Note: See (Collier, 2002), (Hall 2001) or (Masie, 2003) for definitions of these product categories.) WebCT and Blackboard both claim support for SCORM, as do products like Angel and Desire2Learn (WCET 2004). There are also open source projects such as RELOAD that provide SCORM tools. The following table shows some estimated adoption rates by various categories of products.

(Note on Adoption Rates: Note: Data is based on Brandon-Hall reports (Chapman, 2003) (Nantel, 2004), on private communications of results of surveys done by Thomson / NetG and Recombo, on the WCET Edutools site (WCET 2004), and confidential data available to the authors. The data are largely self-reported and lump “conformance,” “certification,” and “support” together. The table should be interpreted as qualitative only. SCORM refers to SCORM 1.2 and not to the newly released SCORM 2004. “IMS Specifications” refer to those that are not part of SCORM 1.2. The data for IMS specifications required interpretation of reports on (WCET 2004))

What Problems Does SCORM Address?

SCORM is designed to separate learning content from learning platforms. This allows content to be developed once and run on any platform, much in the way that a moive can be recorded on a DVD can be played on any DVD player.

The desire to separate content from learning platforms is market driven. As long as content is tied to a single platform, customers are locked in to that platform. If they want to make a change, their choices are to re-develop their content or to stay with the same system. Lock-in disappears if content can be developed once and run anywhere. This also increases the potential market for any given piece of content and enlarges the pool of content that can run on any given learning platform, adding value to both content and learning platforms (Collier, 2002; Hall, 2001; or Masie, 2003).

Packaging and Metadata

Two immediate requirements must be met if content is to be separated from learning platforms. First, a mechanism is needed to transport the content (the equivalent of the DVD and the standards that make it writable and readable). Second, a learning platform must be able to discern and display metadata about content when it is loaded into the platform (the equivalent of the menu showing the scenes and “bonus content” on a DVD).

SCORM (versions 1.2 and 2004) addresses these problems using the IMS Content Packaging specification and the IEEE Learning Object Metadata standard (Note: More precisely, SCORM 2004 metadata is a profile of the IEEE Learning Object Metadata standard, 1484.12.1-2002, (IEEE LOM, 2002) and an IEEE draft standard for an XML binding for LOM, 1484.12.3). Here are some details.

IMS Content Packaging: An IMS content package is Zip file that contains two parts:

  1. A collection of learning resources (files)
  2. An XML file called the manifest that contains
    1. A list of available resources and pointers to them. These could include files in the package or external links.
    2. One or more sets of instructions for structuring the available resources into a coherent learning experience.
    3. Metadata about the package and resources.

Learning Object Metadata: Learning Object Metadata (LOM) is a descriptive metadata standard that can be used to describe the following aspects of a learning resource:

  • General information about the resource (e.g., title, description and aggregation level)
  • Information related to its lifecycle (e.g., author, date and version)
  • Technical requirements and characteristics (e.g. size and platform requirements)
  • Educational characteristics (e.g., age level, type of the resource and learning time)
  • Rights (whether there is a cost and other restrictions on use)
  • Relationships to other learning resources
  • Classification according to an arbitrary taxonomy

Metadata is familiar to the digital library community. All fifteen elements from unqualified Dublin Core can be mapped to and from LOM elements.

IMS Versions and Course Management Systems

SCORM uses versions of IMS Content Packaging and IEEE LOM that fit its particular needs. Current and previous IMS versions are implemented in course management systems and other technology independent of SCORM. The combination of IMS Content Packaging and LOM solve the problems of exporting, transporting and importing learning resources as long as the resources are not required to interact with student data or other aspects of the learning environment.

Learning Functionality and SCORM

The ability for content to communicate with the learning management system may not appear to be particularly valuable if we are dealing with content such as a text document, a PowerPoint™ presentation, or an interactive tool that does not keep track of its interactions with a learner. Here the role of the learning platform is to allow content to be stored, located and launched, and these issues are addressed by metadata and packaging standards described above. However, huge investments are being made in learning content and tools that track interactions with learners and the learner’s progress. There is considerable value in being able to communicate this information to the learning management environment. To take advantage of these investments across all learning platforms requires a standard for communication between content and the learning platform.

A concern with separating content from learning platforms is the loss of learning functionality. With traditional computer based instruction, the software is the content. This is true for training program like Mavis Beacon Teaches Typing®? and for standard computer games and simulations. These programs have the ability to track user interactions and to adjust their behavior accordingly, for example by presenting more challenging problems after mastery of easier ones has been demonstrated through a test. If content is to be developed independently of learning platforms, then this type of learning functionality requires clear standards for communication and coordination between the content and the learning platform as the content is running.

The approach taken by SCORM is based on work done by the Aviation Industry CBT Committee (AICC) in the late 1990’s. The overall setup assumes that a student is interacting with a learning platform through a Web browser window. The learning platform delivers content to the student’s desktop, either in the same browser environment or in an external window, but the parent window is always owned by the learning platform.

In the SCORM model, learning content is broken down into discrete chunks. These were called lessons in the original AICC work and are called sharable content objects or SCOs in SCORM. The learning platform is responsible for delivering SCOs one at a time. While a SCO is running, it can communicate with the learning platform.

The information it can communicate includes:

  • The student’s identity and certain preferences
  • Time spent in the SCO
  • Results of tests and test questions
  • Information about the student’s achievement on the SCO and the student’s mastery of learning objectives, including ones not addressed by the current SCO)
  • “Bookmarks” that keep a student’s place in a SCO

When the SCO is finished running, it signals the learning platform and passes control back to it. The learning platform then delivers another SCO.

This flow is summarized in the following sequence of steps:

  1. The Learning platform delivers a SCO to student
  2. The SCO runs in student environment and communicates with learning platform
  3. The SCO signals that it is finished
  4. The Learning platform delivers new SCO

The SCORM API and Data Model

The above flow is implemented through two standards. (Note: More preciesly, as of this writing one is an IEEE standard (IEEE 1484.12.2-2003) and the other is a IEEE draft standard (1484.11.) anticipated to become a standard by the end of 2004.) The first is an API, or application programming interface that uses JavaScript™. The API defines a set of JavaScript™ functions that allow content to communicate with a learning platform. The second is a data model that determines the type and format of information that may be communicated.

The way this works is as follows:

  • When a SCO is designed, it uses the functions specified in the API standard. These functions will not work unless the SCO is loaded into an environment created by a SCORM learning platform.
  • When a SCORM learning platform sets up a window environment on the student’s desktop, it includes an “adaptor” that has functions exactly matching the functions in the API standard. (Note: Often, the adaptor, is a Java™ applet with the APO functions included as methods.) These are fully working functions that would cause the learning platform to send and receive data if they were invoked, but without a SCO loaded into a window, there is nothing to invoke them.

The situation at this point is very much like having a DVD player and a TV plugged in and ready to go but with the cable between them disconnected.

  • In order to connect the JavaScript™ in the SCO to the functions in the adaptor, the SCO contains additional piece of code that searches for the adaptor and makes the connection. This is requirement for a SCO. Since it is the SCO that finds the adaptor, the SCO is required to signal the learning platform that a connection has been made. This is done by invoking one of the API functions.
  • It is also a requirement that the SCO signal the learning platform when it terminates. This is also done through the API.

We are now ready to walk through what happens when student wants to take a SCORM course using a SCORM learning platform:

  1. A student initiates a session with the learning platform. This establishes the identity of the student to the platform. The platform is assumed to have access to the student’s records, preferences, past history with courses taken on that platform etc.
  2. The learning platform sets up a browser window environment that allows the student to interact with it. This is enabled with a SCORM API adaptor.
  3. The student selects a course. The course is made up of SCOs.
  4. The learning platform now decides which SCO to load. This could be done in two ways:
    1. On the basis of a request made by the student, e.g. by selecting a SCO from a table of contents provided by the learning platform, or
    2. By taking into account which SCOs the student has completed, what results have been obtained, what bookmarks have been set etc. (The rules for doing this will be the subject of the next section.)
  5. A new SCO (or the last SCO seen at last point bookmarked) is loaded into the student’s window environment.
  6. The SCO connects to the adaptor provided by the learning platform.
  7. The student starts working through the SCO. At various points the SCO may request information or transmit information to the learning platform.
  8. When the student is finished with the SCO, the SCO terminates and the learning platform determines which SCO to deliver next, going back to step 4.
  9. The student may terminate the process at any time using controls provided by the learning platform.

Sequencing

There is still one piece missing from SCORM as it is described so far: the rules by which a learning platform decides which SCO to deliver next. This is not a problem for courses with single SCO or that allow students to select SCOs from a table of contents. But rules are needed if the same type of instructional design strategies and adaptive behaviors are to be defined for SCORM content as have long been implemented in stand-alone educational software. The latest version of SCORM addresses this using a relatively new IMS specification called Simple Sequencing.

IMS Simple Sequencing views courses as consisting of a tree of activities. Activities may be attempted, may be completed and may report results. An activity (unlike a SCO) is not required to report results: Simple Sequencing allows for “non-communicative” content.

Simple Sequencing also uses the concept of a learning objective. Learning objectives can be measured and completed. Multiple activities can affect the state of a single learning objective, and one or more learning objectives can affect whether or not a student engages in a particular activity.

Using IMS Simple Sequencing, a learner starts at the root of an activity tree and progresses through it according to a set of rules that can depend on the status and history of every activity and learning objective. The rules can require a student to take the next activity, choose from among a set of activities, or take a linearly sequenced set of activities with the option of going either backwards or forwards. The rules can limit the number of attempts made for an activity, and there are provisions for randomizing or selecting a given number from among a set of activities. Simple Sequencing rules also define how results from multiple activities are combined into a single result.

Implications of SCORM

SCORM has significant implications for the design of both learning resources and course management systems.

  • It is fundamental to SCORM that navigation be controlled by the learning platform. This requires larger resources to be broken up into self-contained sections. This is also implicit in the IMS Content Packaging specification.

    Sections must provide their own internal navigation, but navigation between them is the responsibility of the system that delivers them.

  • From an instructional design perspective, as well as from a sequencing perspective, these sections should ideally treat a single learning objective.

    In other words, sections should be learning objects in the Learnativity sense.

    In SCORM, quizzes and tests are a type of content like any other content. They are not a feature of the learning platform. The same applies to chat rooms, bulletin boards and other learning activities that are often provided by course management systems.

    This is counter to the way traditional course management systems are architected.

  • SCORM (or IMS Content Packaging) requires a lot of metadata.

    IMS Content Packages permit metadata at every level. SCORM requires that metadata be provided at least for SCOs, especially if content is to be modified, disaggregated and re-aggregated. SCORM makes several elements mandatory for SCO metadata. These include technical format, version, status and rights metadata, all of which are seldom provided with current learning content.

SCORM Tools

SCORM has significant uptake by learning platforms used for training. It is also gaining adoption among developers of academic learning platforms. WebCT and Blackboard both claim support for SCORM, as do products like Angel and Desire2Learn (Edutools, 2004). Still more can import IMS content packages and understand Learning Object Metadata.

On the authoring side, Macromedia products can be configured (usually by the addition of a free extension) to produce SCORM content. Authoring tools like Trivantis Lectora, Ready Go, IBT Web Authoring, and Impatica products can as well. (Nantel, 2004). There also open source projects such as RELOAD (RELOAD, 2004) that provide SCORM tools.