Sequencing Sharable Content Objects
June 7, 2001
Mark J. Norton
Version 1.1 of SCORM defines two API functions to signal the start and end of SCO execution: LMSInitialize() and LMSFinish(). This is sufficient for linear sequencing models, but needs to be expanded to include other kinds of sequencing.
The document called Learning Structures - Process Flow describes nine kinds of sequencing for learning objects such as SCOs. First, we should consider the simple case of linear sequencing:
This is one of the cases considered by ADL at the recent PlugFest4. An extension was made to the IMS Packaging Specification to describe how SCOs are organized and sequenced. This organization representation is a good start towards describing how SCOs should be sequenced. The organization defines a SCO to be the first one in a sequence (details are not important here).
The SCO is delivered to a client browser where it is processed for display by a browser. Part of this processing is execution of included JavaScript elements, which is where the SCO invokes the SCORM runtime API. LMSInitialize() is used to start the communication process. Presumably, the LMS can make use of this information to start a clock running, etc.
At some point, the SCO is going to declare itself to be done. This can be triggered in a number of different ways: interaction time is done, the user clicks on a button or gadget indicating a desire to move on, time-based media finishes play, etc. Regardless of it is triggered, the SCO signals the LMS to advance by calling LMSFinish().
In a linear sequence, this series of events works just fine. By calling LMSFinish(), the LMS knows that the SCO is done and it knows which one is next, because there is only one place to go in a linear sequence. Let’s consider the case of a branching scenario next.
The top box in this diagram can be thought of as the entry SCO. It starts just like any other. In this example, however, there are three possible exit points. The simple use of LMSFinish() no longer works for us, even assuming a way to represent a sequencing structure of this kind. Fortunately, a hook has been left for us. Let’s assume that the sequence representation of this module has a way of indicating that one of three exits are possible from the first SCO. Further more, these possible exit points are ordered and numbered (1, 2, 3). When the user makes the choice represented by this branching, LMSFinish(n) is called, where n is the branch selected.
As long has exit points can be represented in this manner, the method can be extended to include other styles of learning, such as this case:
The Linear with Cycles model is essentially a linear presentation of SCOs. However, at certain points, the user is allowed to loop back to earlier points and proceed forward again. On example might be embedded assessment at box three which sends the user back to the start of a multi-SCO presentation for purpose of remedation. The sequencing model needs to be able to represent that box three has two exit points: continue and go back. The backwards link should be handled by referring to an earlier organziation item, not the SCO itself.
Sequence Representation
PlugFest4 used an example to illustrate how simple aggregation and sequencing could be represented in an IMS Package organization block. The following is extracted from the example manifest and simplifed:
In this example, three items are defined which refer to SCO references. The items are aggregated into a small module called “Steering & Sailing Rules”. The items are intended in this organization to be sequenced linearly from S110001 to S110002 to S110003.
As mentioned above, this works just fine for a linear presentation. The order of the items in this organization are defined to be the specific order of presentation. Now let’s look at the branching heirarchy sequence.
The Branching Heirarchy is defined by the fact that each learning activity can lead to one or more follow on activities based on some selection mechanism (usually done by the learner). In this learnign paradigm, a strict heirarchy is observed, which means that branches do not merge back at a lower level, there are no links to higher levels, and that all branches terminate in a leaf node.
Because items are able to contain other items in an organziation block, a similar sort of method used to represent the linear sequence can be used to describe the Branching Heirarchy sequence. Here is an example:
This oganization describes the sequence:
Each of the boxes in this sequence are delivered to the leaner as SCOs identifed by the identifierref parameter of the items in the organization. The nesting of items represents each level of the branching heirarchy. Ordering of the items within a higher level items defines selection number. Thus, when the user is presented with the question”What is your quest?”, he is given two buttons to click one (defined in the R_S110001 SCO). Clicking on button number 1 results in the display of SCO R_S110002. Clicking on button number 2 results in the display of SCO R_S110005. Selection and branching at the next level down happens in a similar manner. Ultimately, an item with no nested items within it is reached. This represents a leaf node of the Branching Heirarchy. Presumably, the user is presented with some sort of exit mechanism (although this is probamatical if the whole example above is treated as a SCO itself).
So far so good. Now let’s have a look at the Linear with Cycles example above. Moving from SCO 1 to 2 then 3 represents a normal linear sequence. In SCO 3, however, some selection criteria wants to branch back to SCO 1, or to the next SCO (or exit). This cannot be represented as either an ordered list, or as a strict heirarchy (tree). Somehow, we need to specify in SCO 3 that one choice leads to SCO 1 and another to some other SCO or exit.
I see two ways to accomplish this: extend the item definition to be able to include ordered exit pointers, or move the sequencing representation out of the organization back into a CSF document. Going back to the CSF description returns to ADL control over sequence definition. It also serves to separate organization information from sequencing information, which was merged in the PlugFest4 example.
Alternatively, we could add a new tag such as <exit> which could appear inside of an item which defines exit points for that item. This is a general solution which would allow all graph based sequences to be represented. Unfortunately, it introduces a tag into the Content Packaging schema which is specific to sequencing. I’m not sure that the Content Management group would find that appealing.