Best practices for global objective identifiers in SCORM

By Claude Ostyn
Copyright © 2006 Claude Ostyn

Overview

The SCORM 2004 specification allows success status and scores to persist for global learning or competency objectives. Precautions must be taken to avoid accidental collisions between objective identifers. Also, in practice this feature is often perverted to provide a kind of variable to allow communication between activities. This can unfortunately lead to the pollution of LMS data stores with persistent records for meaningless data that do not correspond to any actual learning or competency objective. This document describes the problem and proposes some best practices to deal with these issues.

Problem statement

The SCORM 2004 specification allows success status and scores to persist for global objectives. This in turn allows activities defined in SCORM packages to share this objective status information. In the current SCORM 2004 specification, global objectives are not formally declared or defined anywhere. Instead, a global objective is assumed to exist when a reference to the objective is associated with an activity. This reference is through an identifier specified in an objective map. For example, objective maps defined for activity A1 could specify that activity A1 will read the status of global objectives O1 and O2 before it starts and write the status for global objective O3 when if finishes. Because they are specified in such a map, O1, O2 and O3 are assumed to have a corresponding status record that persists independently of the activity. This allows another activity, say A2, to read the status of objective O3 as it may have been set by activity A2.

Global objectives were originally intended to allow the status to persist even across content packages, so that adaptive content packages could "know" about competencies already achieved by a learner and adapt their behavior accordingly. For example, assume that package P1 teaches or assesses how to compose a strong password, and that this competency is defined as objective O1. Another course that teaches the basics of computer security could then adapt its sequence so that it can skip the teaching of O1 if the learner has already mastered it.

Best practices

1. Make the identifier globally unique.

   A practical LMS may contain many packages provided by different, independent sources. Also, how competencies are defined may evolve over time. A package might get revised and new learning objects and activities added to it by people who have no access to the original design documentations to the package. Therefore, using identifiers like O1, O2, and so on for global objectives is not a good idea, because it can too easily lead to collisions in the future if the developer of one package used O2 to mean one thing but the developer of another package used O2 to mean another thing. This leads us to the first best practice for global objective identifiers: They should be globally unique. Creating globally unique identifiers is not a trivial matter, but there are many documented methods and utilities to create them. For example, the document Globally Unique Identifiers at http://www.ostyn.com/standards/docs/guids.htm explains how to create such identifiers.

   In practice, globally unique identifiers are really not designed for human beings. Authoring tools should use some simpler representations of the objectives, and map those to the actual objectives. For example, while working on a package, a temporary identifier like "Objective 1" or "Identify the power state" is obviously more usable than something like "F07CDF2A_2E1E_11DB_8AF6_B622A1EF5492". However, the global objective IDs in the package generated by the authoring tool should be globally unique.

   Note that the requirement for global uniqueness does not necessarily apply to the objective IDs used by a SCO in the SCORM "cmi" data model, since those can only be mapped directly only to objective identifiers local to an activity that uses the SCO. However, for sanity developers may prefer to use the same ID everywhere when the same objective or competency is being referenced.

   A useful approach might be to concatenate a human readable identifier with a truly unique identifier. This allows human readers to recognize the identifier, at least within the context of the package, while maintaining the uniqueness that is necessary for sanity.

2. Avoid polluting the LMS with global objectives that are not truly global

   Because global identifiers are the only method supported in SCORM 2004 to communicate data between identifiers, people have used them to convey information that has nothing to do with learning objectives or assessed competencies. For example, they have been used for things like keeping track of preferences, to control navigation menus, to pass data of individual test items to a summary, and so on.

   We have seen above that global objective status persists in the LMS even outside the scope of the content packages in which the global objectives are specified. This can be blocked by adding a flag in the package manifest to specify that the global objectives are not global to the LMS. This flag, if it is true, means that the status information for those objectives can be discarded as soon as the package is no longer in use. But if it is false, it means that the status information will persist in the LMS for at least as long as the learner is registered in the LMS. This can be a lot of useless data that will persist for a very long time. The result is pollution of the LMS records with meaningless global objective data. So, unless at least some of your objectives' status data are truly global in scope, you want to restrict the scope of the global objectives to your package by setting this flag in the manifest.

3. Use the identifier to indicate when a global objective is not really an objective.

   It is useful to be able to distinguish between true objectives and control variables that use the global objective mechanism. For example, when creating reports, if a LMS can recognize that an objective identifier is really the identifier of a variable, the information can be excluded so it does not pollute the report. A recommended best practice is to use a prefix for the identifier string. A traditional prefix that is easily recognizable is the prefix "var_". When a LMS finds an identifier tagged with this prefix, it can automatically manage its scope differently. It is also useful for content designers to be able to distinguish by just looking at the identifier between real objectives and objectives perverted to function as control variables. The best practice may over time be extended to become part of the standard and maybe include some other prefixes that are extremely unlikely to be found in an actual learning objective or competency definition identifier.

4. Document the objective identifier with a reusable competency definition

   It is usually desirable to distinguish between meaningful and meaningless global objective records. If an identifier tagging convention like the "var_" prefix was not used, another method is required. This method could be used alongside with the tagging method. Here is how it works: If a global objective is meaningful, the meaning must be captured somewhere. Ideally this meaning was captured even before the content was created, maybe during the instructional design analysis phase when the purposes for the learning project are being defined in the form of required competencies and associated learning objectives.

   This meaning information typically would consist of a short statement and maybe a more verbose description. The meaning may be captured as a formal definition as a traditional multipart learning objective. Other data may also be involved in the definition of the meaning for the objective. The identifier should be assigned to whatever record contains that meaning.

   If you capture the information about the target objective or competency, you might as well do it using a published standard. The IMS RDCEO (Reusable Definition of Competency or Educational Objective) specification and its offspring, the IEEE P1484.20.1 draft standard for Reusable Competency Definitions can be used here. They both include the requirement for a globally unique identifier, which can of course also be the identifier you use for a global objective in SCORM. This best practice allows for a convenient filtering out of garbage global objective status records in a LMS. The rule can then be very simple: If the LMS is aware of a RDCEO or RCD record that matches the global objective identifier, then the objective status record can be treated as meaningful. Otherwise, it is probably meaningless, just an artifact from using global objectives as variables in a SCORM package.

   Note that specifications and best practices are only beginning to emerge for RCD repositories, but for this purpose any collection of RCD records will do.

5. Document meaningful objectives in metadata

   Unfortunately neither the SCORM specification nor the ADL-R repository specification require a clear identification of the objectives in the metadata associated with a SCORM package. However, a best practice would be to use an IEEE LOM (Learning Object Metadata) Classification element for each meaningful global objective used in the package.

   The purpose of the LOM Classification element should be set to be either Learning Objective or Competency. A direct mapping is possible between a SCORM global objective identifier and the identifier of an objective or competency in LOM (the taxonID sub-element within a Classification) and the identifier of the global objective. Such a LOM Classification element can also be directly mapped to a RDCEO or RCD record, using the same identifier.

Conclusion

At a minimum, one should use the "var_" prefix for identifiers of global objectives that are not really global objectives, and make sure that the objective IDs that might leak outside the scope of a package are globally unique.

Like everything else, best practices evolve over time. The best practices described in this document are simple, standards based where possible, and relatively inexpensive to implement. This is by design, to allow easy remapping of the data and behavior into future standards and behaviors.

By adopting the best practices described above, content developers as well as LMS and LCMS developers can make their products easier to use and to maintain without compromising SCORM conformance. Graceful degradation is also possible to interoperate with products that do not follow the best practices. For example, when a content package is ingested into a LMS, the operator might be given the option to verify which best practices the package is known to follow. If this cannot be verified, the package and its associated global objectives could be flagged as "suspect" for any management process to control data pollution.

Terms of use for this document

This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 2.5 License.