SCORM stands for Shareable Content Object Reference Model; it was created by the US Defense Department’s Advanced Distributed Learning (ADL) Initiative (http://www.adlnet.gov). While one of the ideals driving the SCORM’s creation was to promote content reusability and thus —more grandiosely – to facilitate the emergence of a “content ecosystem” in which learning professionals could mix and match already existing pieces of content to suit their educational needs, the reality is that the initiative has been more successful at simplifying course “packaging” and structural organization, and standardizing how courses communicate with an LMS, than creating reusable content objects. To arrive at the SCORM standard, the ADL took the best of several existing learning standards (the airline industry’s AICC structural and communication protocols; the IMS GLC’s packaging standards; certain aspects of the European ARIADNE initiative) and combined them. It used JavaScript (technically, the more platform-neutral ECMAScript) as the language for communication between the LMS and courses, and set strict standards on storing course/learner information (such as completion, score, time in course, et cetera). Because of the ease of its implementation, and its more comprehensive and (arguably) web-native approach, the SCORM very quickly beat out AICC as the de facto corporate eLearning course integration standard.
SCORM 1.2 has two primary components: The Content Aggregation Module and the Run-Time Environment. The Content Aggregation Module defines how courses are required to be packaged in order to be considered SCORM conformant. A course must be packaged as a single zip file that contains:
- Course Resources: These are the course’s content files. They may be in any folder structure and contain any web-deliverable content.
- imsmanifest.xml: This is an XML file that contains all the metadata for the course. It defines values for data elements such as the course title and code, a list of all course resources, a course description, the course structure, a list of course SCOs, a mastery score, and other structural and definitional information. This file must be at the top level of the zip package and can NOT be in a sub folder. This document’s structure must conform to an XML schema maintained by the ADL.
(So what is a SCO anyway? A SCO is a Sharable Content Object. This is the lowest level of learning content contained in a course, and is the basic building block of learning, envisioned by the SCORM’s creators to be able to be re-purposed for any number of different courses. Each SCO, after course upload, is listed in the LMS-created table of contents, and is tracked separately from the other SCOs in a course. In order to simplify learner interactions with learning content, however, many course developers choose to make courses consisting of a single SCO, with this SCO containing all of the course content. This allows greater control over the look and feel of a course’s table of contents or index, as well as over the order in which learners encounter each section of content. )
The Run-Time Environment defines the details of how the SCO can communicate with the LMS. It specifies what commands must (or can) be called at what point, what acceptable data can be stored in the LMS, and how those data need to be formatted. For example, the variable field cmi.core.lesson_status (which tracks the status of the course in the LMS) may only be set equal to one of the following values: “passed”, “completed”, “failed”, “incomplete”, “browsed” or “not attempted”. Attempting to have the course set this field to any other value will cause the LMS to throw an error. This level of detail is specified for all supported data elements, and extends in some cases to prescribing data type (e.g., “integer” or “text”) and allowable character-length.
The complexity inherent in developing a standard for an industry with multiple vendors and implementers at different levels of conformance and technological sophistication can cause, and has caused, some confusion around its implementation, particularly with regard to the data model. For example, there was one significant mistake around the data model definitions in the SCORM 1.2 standard: it allowed certain objects in the data model to be optionally supported by a conformant LMS. This was true for both the Interactions elements (which capture and store information around quiz and assessment questions) and the Objectives elements (which can be used to store learner states – score; completion progress; etc. – for specific course objectives). Although many LMSes supported these optional elements, many others did not; and a course creator often wouldn’t be able to tell the level of support for these elements until the course was deployed on the LMS. This meant that course builders couldn’t guarantee that administrators would be capable of doing, say, question-level item analysis on a course’s assessments or quizzes, even though the courses had been built to accommodate this need. This issue has been resolved in SCORM 2004.
With the definition of the Run-Time environment and Content Aggregation Model completed, the SCORM 1.2 standard was released. Due to its straightforwardness and ease of implementation, it has become the most used eLearning standard in the corporate United States. It counts over 160 “certified conformant” learning products, with 85 of them being Learning Management Systems.
If you are interested in delving deeper into the SCORM standard, you can access all of the SCORM documentation on the ADL site at http://www.adlnet.gov. Also, you can check to see if your LMS vendor is SCORM certified at http://www.adlnet.gov/Technologies/scorm/Custom%20Pages/Certified%20Products.aspx.
* I would like to thank Ted Blanchard for contributing to this entry.
Posts
0 comments:
Post a Comment