|
By using the content of this page, you agree with the terms
of use spelled out in detail at the bottom of the page.
For information
about Click2learn products and services, please see the main Click2learn web site.
The Shareable Content Object Reference Model (SCORM), published by the Advanced Distributed Learning (ADL) project, is a de facto standard for e-learning content. This document is a brief overview of the SCORM specification to help non-technical readers understand the underlying technology and rules. This document is intended for anyone who needs to understand better what SCORM 1.2 enables and makes difficult. It also explains some of the magical incantations that often follow a mention of SCORM, like "SCO" and "manifest". The second half of the document is slightly more technical and answers some common questions about how SCORM content packages are built.
The business case for SCORMThe business case for SCORM can be summarized in one picture. Before SCORM, integrating content with a delivery platform for e-Learning or training used to take days, weeks or sometimes years, unless the content was built specifically for that platform. Often the costs of modifying the content or building special adapters, along with the time to deployment, were simply prohibitive.
Some advantages of SCORM are:
SCORM is a set of specifications that describes:
The SCORM specification is actually a set of specifications profiles based on various other industry standards and specifications. The current official version is 1.2 and was first published in 2001.
The SCORM specification does not cover all aspects of a learning enterprise; for example, it does not specify how tracking information is stored and what reports are generated, what pedagogical or training models should be used, or how learner information is compiled.
SCORM 1.2 also does not specify how content is sequenced by a runtime service. The most common assumption is that the user is free to choose any part of the content. Future SCORM specifications will define how to specify sequencing behavior for content. In the meantime, SCORM 1.2 provides a robust specification for content that can be packaged and migrated between systems, installed on an LMS or archived in a plug-and-play manner.
There is a version 1.3 in the works, which will extend on SCORM 1.2 by specifying how to add prescriptions for sequencing. That new version will probably not become final until sometime in late 2003 and content developed to conform to SCORM 1.2 should still be able to function in an implementation of SCORM 1.3.
In the SCORM 1.2 specification, SCORM-compliant learning content is either—in SCORM terminology—a Content Aggregation Package or a Resource Package. A Resource Package is a collection of learning assets that is not intended for delivery as such, for example to archive or migrate a collection of asset. This document does not describe how to build or use Resource Packages; it focuses on deliverable content. A Content Aggregation Package is:
A SCORM-compliant learning management system (LMS) is a system that:
The SCORM 1.2 specification does not require that the LMS user interface behave in any particular way, except for the fact that the user must be able to choose and launch any SCO designed by an item in the content organization.
What a LMS does with the tracking information that may be communicated by a SCO is also not specified by SCORM 1.2. Obviously, often the reason to have a LMS in the first place is to collect this tracking information and use it for learning management or reporting purposes, but whether and how to do this is left to the LMS implementers and vendors to decide.
Note that although SCORM was designed primarily to support content delivery and tracking through a web server, it does not require the use of the internet or even of a network. It is possible to have a SCORM implementation that uses a closed intranet. You may even have purely local, offline implementation. For example, with an offline runtime environment, you should be able to play SCORM compliant content on a laptop or workstation with no network connection whatsoever. The offline runtime component may or may not include a "mini-LMS" capable of recording tracking information. Such an implementation may perhaps include synchronization with a server-based LMS when a mobile computer is reconnected to a network. Whether or how to do this is however beyond the scope of SCORM.
It is possible to author SCORM content with a simple text editor. However, this does not easily produce the rich content and interactions that a real authoring tool can facilitate. A tool such as Click2learn's Aspen 2.0 Web-based enterprise LCMS, or desktop authoring tools such as Click2learn's ToolBook 8.5, does much of the work automatically: You just specify that you want to export the content as a SCORM package and it will do it for you. Those tools are designed specifically to isolate designers and subject matter experts from the technical minutiae described in the SCORM specification, so that they can focus on what the content shows, tells and teaches.
For example, Aspen Learning Content Management Server (LCMS) is a global, scalable, 100% Web-based application that enables rapid creation, delivery and management of high quality learning content for your entire enterprise. Aspen LCMS is designed to facilitate the separation of presentation, logic and behavior in learning objects, providing maximum flexibility and reusability. The team-based authoring environment allows concurrent development, allowing instructional designers, subject matter experts, project managers, and reviewers to work together to create high quality courses quickly. In this big picture, SCORM conformance plays only a small part, although it is a critical one.
Note that there are many ways to achieve SCORM conformance, which is good because it leaves a lot of room for creativity.
Content created for SCORM 1.2 according to the guidelines in this document will not automatically be rendered obsolescent by SCORM 1.3 or other future specifications because:
An update of this document is planned for release after the final version SCORM 1.3 specification is released in late 2003.
There is no precise definition of "learning object", but the term itself is useful to describe a broad category of digital assets that can be used for learning, training, and performance or knowledge development. A learning object can be as small as a paragraph of text and as large as a 3 month online course. SCORM can deal with learning objects of any size. Not everyone, however, is ready to take the conceptual plunge and many people try to relate learning objects to familiar nomenclatures. For example, they will tell you that a learning object is something that covers a single topic, or that a learning object is something that a user can complete at a single sitting. Unfortunately, these idiosyncratic definitions don't agree with those of other people who think that a learning object is a content aggregation of any size. Deliberately undefined terms do have their use, and "Learning Object" is one of those, along with "food", "software", "fuel", "commerce", and so on.
SCORM content is made of so-called Shareable Content Objects (SCOs) aggregated into a content package. The SCOs are a specialized type of learning object. Each SCO is a unit of content that can be delivered to a learner by a SCORM-compliant learning management system in order to create a useful learning experience.
The SCOs used in a SCORM-compliant package may be fully included in the package, or used by reference. For example, under certain conditions a learning sequence may include learning objects that reside on another server. Note that the security restrictions implemented in Web browsers to prevent malicious cross-server exploits make the use of learning objects that reside on another server more difficult. How to solve this problem is an issue for learning content management system and content repository vendors to resolve. There is nothing you can do in the content itself to work around this security barrier.
A Web-based learning object that can be included in a package for delivery by a SCORM compliant learning management system as an individual activity is called a "Shareable Content Object" (SCO). In practice, SCOs come in two main flavors:
SCORM 1.3 will introduce a new kind of object, a "SCA", short for "Sharable Content Asset". Unlike a SCO, a SCA is totally passive and does not communicate at all with the runtime environment. For example, a document or a picture could be incorporated in a package and delivered as part of content sequencing without having to be wrapped in a SCO.
Regardless of how many SCORM features they use, SCORM 1.2 compatible learning objects do not communicate across the Web to a remote server. They only communicate with a specific object within the same browser environment on the client side. The implementer of the delivery environment provides that object. There is a well-defined way for the content to find that object and communicate with it using simple JavaScript code or its equivalent. This has major advantages:
The SCORM API implementation is instantiated on the client side by a runtime service before the SCO is launched. This implementation may vary from vendor to vendor. For example, the API may be implemented in an HTML frameset that contains a "stage" frame within which the learning objects are launched.
The person or entity that creates a package of learning objects decides how the learning objects are organized. However, since SCORM 1.2 does not define any sequencing information, the learner will be able to choose which learning object to use and in which order.
Future versions of SCORM, starting with SCORM 1.3 will add a more advanced sequencing model to SCORM 1.2, to allow the implementation of richer pedagogical or instructional models.
SCORM 1.2 uses the IMS Packaging specification as a foundation for the packaging and organization of learning objects. A package may contain more than one organization of the same learning objects. For example, you could define two or more tracks covering the same subject at different levels of depth, or for different audiences. An LMS can take advantage of this to allow a choice of the more appropriate organization.
SCORM 1.2 specifies how to build a package, but it does not specify how an LMS uses some optional features of the package such as multiple content organizations. Once the learner, manager or learning managements system has chosen an organization within the package, however, SCORM 1.2 does specify that the learner must be able to launch each of the learning objects (SCOs) defined in the organization.
The organization of the SCORM learning objects in a package is described in a hierarchical tree structure, such as a course structure or hierarchy of content. SCORM does not specify a particular depth of the tree. Also, SCORM does not specify any particular nomenclature to name the levels of the tree, such as "course, lesson, topic" or "unit, module, lesson.” You are free to use whatever nomenclature you like, or none. The length of the branches of the trees may vary.
Each item in the tree can point to a learning object, or it can contain other items. Each item must have a title, which a run time environment will display to the learner.
An item in the tree can have children and also point to a learning object. For example, if your content hierarchy represents sections, chapters and pages, the chapter headings may have their own "cover page.” However, in SCORM 1.3, only learning objects associated with leaf nodes in the tree will be launched and tracked as SCOs.
You can mix and match SCOs at all levels of technical compatibility within the same organization. For example, you can aggregate simple, one-page SCOs created with Notepad with complex SCOs created with an advanced authoring tool such as ToolBook.
Older organization models, like the Aviation Industry CBT Committee (AICC) course structure made of Blocks and Assignable Units, can be mapped directly into this organization model.
Content organization models that use directed graphs cannot be represented directly in the SCORM hierarchical tree structure. However, many directed graphs can be represented by making multiple items point to another organization in the package, instead of referencing a SCO. See the description of the packaging manifest (below) and the IMS Content Packaging specifications for more information on how to achieve this with sub-manifests.
SCORM 1.2 does not define how to sequence SCOs. It is assumed that the user can choose any item in the content structure.
In user-choice sequencing, the runtime service allows the user to choose any item in the entire learning object organization. Depending on the implementation, this could be accomplished through a visual tree, a menu or a set of nested menus. SCORM 1.2 does not specify what the user interface to choose an item will look like.
For example, a typical implementation with a table of content may work like this: When the learner selects an item in the table of content, the item is highlighted and the corresponding learning object is launched in the stage window. If the item has children, but no learning object of its own, the first child that has a learning object is highlighted and that learning object is launched.
You can assign a mastery score to an activity that uses a SCO. If a score is reported for the SCO, the runtime service compares the score with the mastery score to set the status of the activity to "passed" or "failed.” This overrides any status that may have been reported by the SCO.
See details in the SCORM specification. The runtime service can unload a SCO when the time allowed has expired; however this behavior is not well defined and may not be available on all implementations because it requires the run time environment to be more complex on the client side.
SCORM 1.2 defines a very basic form of prerequisites. A prerequisite references another element in an organization tree that must be completed or mastered. However, because the SCORM specification does not clearly define the behavior associated with prerequisites, only a way to specify them, use prerequisites at your own risk. SCORM 1.3 will include more robust sequencing rules that will not rely on hard-wired references between items, but that will instead allow adaptive sequencing decisions based on the status of learning objectives.
In order to implement SCORM-compliant learning objects and SCOs it is useful to understand a little bit of the runtime environment in which they will be used. To distinguish this runtime service from the rest of the LMS and its login, authentication, storage and reporting services, we will refer to the runtime environment and the processes that manage it as the "runtime service.”
The distinction between LMS and runtime service can be useful because an LMS and the user experience may have, for example, different latency requirements.
The runtime service can be implemented in part on the client side (i.e., on the learner's computer) and in part on the server side (i.e. somewhere on a server). In an offline situation, the server side of the environment is emulated by an application that runs on the learner's computer.
The client side of the runtime service:
The server side of the runtime service and the rest of the learning management system are completely invisible to the scripts in SCORM learning objects. The user interface components of the runtime service, such as a table of content or navigation buttons, are also completely invisible to SCORM learning objects. How the client side of the runtime service is implemented, and how it communicates with the server are totally invisible to the content. The only parts of the runtime service with which a SCORM learning object can detect and communicate are:
The learning objects are specifically prohibited from navigating to other learning objects within the stage window. Only the runtime service can load another learning object in the stage window. The runtime service uses the content organization defined in the content package as its guide to manage navigation between learning objects.
SCORM specifies how to package learning objects as SCOs so that they can be aggregated, stored, copied, moved, archived, uploaded and eventually delivered to a user by any SCORM-compliant management system. A package may contain one SCO, or many SCOs.
The IMS Global Learning Consortium (http://home.click2learn.com/standardswork/scorm12rk/overviews/www.imsglobal.org) has developed a packaging specification for learning content that provides a useful blueprint to generic content organization in the form of a manifest included with the package. The manifest is used to inventory the content of the package, but also to describe it through metadata. The manifest may also be used to show how the content is organized. SCORM 1.2 content packaging is based on the IMS specification.
An IMS packaging manifest is an XML document that contains several parts:
Metadata that describe the package.
Organizations: Zero, one or more hiearchical maps that describe how the content is organized. Each item in such a map can reference a resource in the package. For SCORM content intended for delivery to an end user, the manifest must contain at least one organization.
Resources, which specify actual chunks of content that can be used. More than one organization item can reference the same resource. A resource can also have its own metadata. A SCO is typically described by a resource.
Sub-manifests (nested manifests), which describe a subset of the content in a package. A sub-manifest can have its own metadata, organizations and resources.
The IMS
Content Packaging model used in
SCORM
For example, if you were to display an organization as a table of contents, by selecting an item in the table of contents you could launch or open the corresponding resource.
Instead of an atomic resource, an item in an organization may reference a sub-manifest, and thus an entire other organization. This can be very useful if the same organized "chunks" of content are used in more than one place in a course, for example. This also makes the packaging of organizations in the shape of a directed graph more convenient. Because they are self-contained and can have metadata, sub-manifests can also be useful as a way to identify the parts of a package that can be extracted and reused in another context.
This packaging model is the foundation for the SCORM 1.2 content structure and organization. SCORM 1.2 extends the package definition by specifying additional data elements. In the XML document, those extensions are identified by the namespace prefix adlcp:
SCORM specifies how to add metadata to a package. You put this metadata at the top level of the manifest. SCORM also adds the option to reference a separate metadata file included in the package. To conform to SCORM 1.2, you may either include the metadata in the manifest directly, or use the SCORM-defined extension to reference an external metadata file. You cannot do both, i.e. you may not have both inline metadata in the manifest and a reference to a metadata file. SCORM also allows additional metadata as defined by the IMS schema.
Create an XML manifest. This is an XML file with a header as specified in SCORM 1.2.
When the SCORM content you created is installed in an LMS or repository, it will probably not end up in the same directory as on your development system, or have the same access rights associated with it. Therefore you must follow these rules in the organization of any internal links in your Web content:
You can associate a SCO with any item in the organization tree. Note however that the Simple Sequencing model for SCORM 1.3 will probably allow SCOs only for leaf nodes in the tree.
Claude Ostyn has been involved with Learning Technology Standards for several years as a contributor and member of various working groups of the IEEE Learning Technology Standards Committee and the IMS Global Learning Consortium. He was also part of the technical consultants team that helped in the genesis of the SCORM specifications.
He has been with Click2learn since the early days when the company was still called Asymetrix. He directed the design and implementation of what was, way back then, a new kind of hypertext help system with state of the art on line tutorials. He later added multimedia widgets to ToolBook and designed ToolBook CBT edition, the first e-learning authoring tool to use wizards, templates and smart, context-sensitive objects rather than coding and flowcharts, which later evolved into Click2learn Instructor.
His background includes a Film and Video degree, extended stints in remote Alaskan places as artist in the schools, ethnographic, training, and commercial video production, stand-up training of adults in areas ranging from filmmaking to spreadsheets, an Education degree from Stanford and the occasional use of an excellent recipe for chocolate mousse that begins with "take some good, dark Belgian chocolate…"
Photo: J.R. Garcia
Copyright © 2003 by Click2learn, Inc. - All rights reserved.
This document is a Click2learn Standards Projects, subject to change without notice. Permission is hereby granted for Click2learn customers and contractors, and for participants in industry standard initiatives, to reproduce this document for purposes of standardization services, including demonstration. If this document or any portion of this document is to be submitted to any standards body, notification shall be given to Click2learn. Other entities seeking permission to reproduce all or any portion of this document, for these or other uses, must contact the Click2learn Copyrights and Permissions Department for the appropriate license. The publication of this document does not imply that Click2learn, Inc. intends to implement any of the functionality described in this. Click2learn, Inc. reserves the right to modify this document, demonstration applications and any other product or offering specification without notice. The document is provided "as is" and Click2learn expressly disclaims any implied warranties and conditions, including any implied warranties or merchantability or fitness for a particular purpose, title or non-infringement. Click2learn does not make any representations or warranties that this document demonstration applications available on this page are (i) accurate, correct, or timely; or (ii) updated or otherwise contain current information. Use of any information contained in this document. This document is Copyright © 2000-2003 by Click2learn, Inc. - All rights reserved.
Click2learn, the Click2learn logo, Aspen, the Aspen logo, Aspen Learning Management Server, Aspen Learning Content Management Server, Aspen Virtual Classroom Server and ToolBook are trademarks of Click2learn, Inc. All other company and/or product names are the property of their respective owners. Information in this document is subject to change without notice.
Click2learn Copyrights and Permissions
110 - 110th Ave NE,
Suite 700
Bellevue WA 98004
USA