The SCORM data models are essenitally SCORM’s version of variables and they are used to hold specific pieces of information in very specific formats so that both your Opus publication and the online Learning Management System know what each is trying to tell the other.
The complete list is provided in the ADL specification and specifically in the "Run Time Environment" section of the specifcations, for example:
SCORM v1.2 – SCORM_1.2_RunTimeEnv.pdf
and for
SCORM 2004 – SCORM_2004_4ED_v1_1_RTE_20090814.pdf (or later version).
These are both available from the www.ADLnet.gov website.
We have listed the key ones here together with the format of the information or how they might best be used with Opus. The first name is the name used in the SCORM v1.2 specification whilst the second, bracketed name is the name of the data model in the 2004 specification.
You must ensure that the format of the information in the Opus variable is the same as that required by SCORM. If you are having trouble getting information stored in the LMS it is most likely that you are sending it a number when it is expecting a string (piece of text).
Note that some of these data models are specified as Read Only so your Opus publication will not be able to change them. We have noted this in the information below.
Format: String (text) – up to 255 characters
This is essentially a bookmark. It is a piece of text used to store the location in the lesson which the user has reached so far. Obviously the first time your publication connects with the LMS this will not be relevant so for many smaller publications which are intended to be completed in a single session this will not be used.
You can use this as a bookmark by using the Set SCORM Value action to store the current Opus page title into this data model and then when the publication is run again you can use the Get SCORM Value action to retrieve it and then use the Goto Page action in Opus to go to that page or offer the user the option to go to where they left off.
Your Opus publication can both read and write this information.
Format: String (text) – last name, first name initial (e.g: "Smith, John P")
This represents the name of the learner as maintained by the LMS and is the last name, first name and middle initial of the leaner in that order. The last name and first name must be separated by a comma.
You can reads this into your publication using the Get SCORM Value action and store it in a variable such as LOGIN_USER_NAME or LMS_LEARNER_NAME. We have provided a script which will split the basic data into LOGIN_FIRSTNAME and LOGIN_SURNAME.
Your Opus publication can only read this information it cannot amend it.
Format: String (text) – keyword only
This is a formal piece of information which details the progress of the learner. It must be provided as one of the following and note the keywords are case sensitive:
not attempted
The course has not yet been attempted by the learner (this would be the default value for any relevant Opus variable).
browsed
If users are allowed to simply browse the lesson, this tells the LMS that they have done so, This is not widely used. If you wish to support this in Opus you will need to make all SCORM scoring actions conditional on whether the user was just browsing. Can probably be ignored for most cases.
not attempted
The course has not yet been attempted by the learner (this would be the default value for any relevant Opus variable.
incomplete
The user has started the lesson but not completed it yet. In Opus you would probably set your variable to this on the first key page of your publication and leave it as that until the lesson had been completed. This is an example of where you might use Commit to ensure that this is stored in the LMS irrespective of what subsequently happens.
completed
this indicates that the lesson has been completed irrespective of any score. Obviously it is also used when no scoring is involved or the LMS doesn’t record pass or failure.
passed
this is used when there is a formal test in the publication and the user has scored enough to reach the pass threshhold. Often the publication only needs to provide the score and the LMS will decide if it is enough to pass the lesson.
failed
this is the complementary data model to the preceding "passed" and is used in the same cirucmstances except that it indicates the user did not score highliy enough. Again the LMS often undertakes this decision.
Your publication can read and write this value.
Format: Decimal number between 0 and 100.
The SCORM specification includes a number of scoring data models but this is the one most commonly used. It is probably best connected to the percentage score as tracked in the Opus variable SCORE_VALUE_PERCENT or Q_SCORE_VALUE_PERCENT if you are using Questions.
Your publication can read and write this value.