Cmi5: Difference between revisions

The educational technology and digital learning wiki
Jump to navigation Jump to search
mNo edit summary
 
Line 231: Line 231:
|
|
|}
|}
== Course structure example ==


== Links ==
== Links ==

Latest revision as of 12:47, 5 May 2020

Draft

Introduction

cmi5 is as of 2018 the most recent elearning standard that defines how courses packaged as learning objects and imported to learning management systems (LMS) can interact with the latter in order to track student progress. It clarifies the use of the xAPI in the traditional e-learning domain.

cmi5 probably stands for computer managed instruction, fifth attempt. "CMI" was the name of the original AICC specification published in the early 1993 and that provided the the data model adopted by Scorm 1.2.

cmi5 is a xAPI profile, originally proposed by the AICC working group (one of the earliest actors in elearning standardization). That rational for creating a specific profile is given as follows: “Since the xAPI specification is highly generalized to support many different use cases, a set of “extra rules” (called a “profile”) is needed to ensure interoperability for a given use case. The cmi5 profile ensures plug and play interoperability between learning content and LMS systems. The use case that the cmi5 profile is specifically designed for is one where the learner launches the learning content/activity from the LMS user interface.”

The xAPI project defined this principle with a graphic that we reproduce here:

Data Flow in xAPI. Source: Experience API In cmi5, communication with the LRS happens through the LMS

cmi5 reduced this general case to the interaction of more traditional e-learning contents with a traditional learning management system.

The cmi5 specification “describes interoperable runtime communication between Learning Management Systems (LMS) and Assignable Units (AU)” (cmi5 Specification Profile for xAPI, retrieved July 2018). More precisely it defines how to use the xAPI specification for the following:

  • Launch by an LMS of AUs.
  • Launch and runtime environment used by LMS and AUs.
  • Runtime communication data and data transport between the LMS and AUs.
  • LMS course definition as it pertains to runtime data used by AUs.
  • LMS Course Structure Import/Export
  • Reporting requirements for the LMS.

History and versions:

According to the project page (retrieved July 2018), the cmi5 project was started in the AICC (Aviation Industry Computer-Based Training Committee) in 2010 and was expected to replace both AICC and SCORM specifications since they both have technical issues and constraints as well as significant overlap. The AICC was nearing completion of a SOAP-based communication mechanism 2012 about the same time as the REST-based xAPI emerged from ADL. xAPI had a broader application aim, but the same purpose. So, ADL and AICC agreed to cooperate on a cmi5 xAPI profile and in 2014, the AICC dissolved (even the the website disappeared) and formally transferred the cmi5 project to the ADL.

Major versions have stone names (they might have used them alphabetical order)

  • SOAP-based version (draft) in 2012
  • Sandstone (First version: May 15, 2015)
  • Quartz (First version: June 1, 2016)

Support

As of summer 2018, cmi5 has been adopted by some platforms. This standard is much simpler than older and more ambitious standards such as the complete SCORM 2004 (that includes IMS Simple Sequencing) or IMS Learning Design which were based on formal modeling languages. It also simplifies the the use of xAPI by restricting some functionality and by adding constraining rules. Since programmers are much are at ease with calling functions, i.e. using the REST API, more implementations could follow, even for the open source systems used in higher education. However, the past tells us that hardly any e-learning standard has been adopted by the major players in higher education and for various reasons. One is that higher education is conversational, i.e. is based on tutoring and in more advanced stages doing projects and for these no user tracking is needed, even if learning analytics folks claim otherwise. Finally, there are reasons to invest directly in xAPI as opposed to the more restrictive cmi5. This would allow a system like Moodle to communicate with other learning formats, such a serious games.

Also read SCORM and Moodle: A Long Relationship That May Last Forever, dated April 2017 and slides of Moodle and xAPI : The story so far

Basic mechanism

Cmi5 defines how learning materials are defined to include monitoring commands that can interact with a learning management system. A course is kind of learning object, very similar to IMS Content Packaging, technically speaking a zip file with a specific cmi5 XML file inside that is then uploaded to a LMS that is cmi5 compliant.

The most important object in the Cmi5 specification is the Assignable Unit (AU), i.e. a kind of learning object. Assignable Units are defined as: “learning content presentation launched from an LMS. The AU is the unit of tracking and management. The AU collects data on the learner and sends it to the LMS.” (cmi5 specification, V. Sandstone)

A course is then defined a as a collection of assignable units. Consequently the course structure is a “list of assignable units and launch parameters, with an implied sequence” (ibid)

The learning management system (LMS) is defined as “A computer system that may include the capabilities to register learners, launch learning presentations, analyze and report learner performance, and track learners' progress. LMS launching, reporting, and tracking roles are the focus of the cmi5 specification. The LMS must have an Learning Record Store (LRS) as part of its implementation.”

The LMS imports a course structure that contain at least one AU. The cmi5 model then describes the following steps of a learning/tracking experience:

  • The AUs are launched by the learner and the the LMS writes launching data to the LRS, i.e. identification of the AU, student ID
  • The AU requires launch data plus previous state information from the LMS, i.e. it will have some data about the learner, including prior work with this unit.
  • The Learner view AU contents and (hopefully) engages in learning. During this time, the AU can store data and request data from the LMS.
  • When the learner exist from the AU, it reports final tracking data to the LMS.

Launching

The launch method uses "Get" URLs like this (not URL-encoded, and formatted with spaces for better readability!) 

http://www.example.com/LA1/Start.html
 ?endpoint =     http://lrs.example.com/lrslistener/
 &fetch =        http://lms.example.com/tokenGen.htm?k=2390289x0
 &actor =        {"objectType": "Agent",
                 "account":  {"homePage": "http://www.example.com", "name": "1625378"} }
 &registration = 760e3480-ba55-4991-94b0-01820dbd23a2
 &activityId =   http://www.example.com/LA1/001/intro

Parameters mean the following:

  • endpoint: The URL address of the LMS to be used for sending messages from the AU
  • fetch: URL for an authorization token
  • actor: A JSON object defining the learner
  • registration: A unique ID for this learning session
  • Activity ID: A unique ID associated with this AU.

Structure of the course

Course information is encoded in XML format in a single file. The XSD schema, CourseStructure.xsd, is fairly simple. A course has the following high level structure:

  • title
  • description
  • objectives (optional)
  • blocks with au's inside (optional)
  • au

The following simple example found in the cmi5 specification (retrieved, July 2018) shows a simple, minimal example. A more complete example with multiple objectives and nested blocks can be found here.

<?xml version="1.0" encoding="utf-8"?>
<courseStructure xmlns="https://w3id.org/xapi/profiles/cmi5/v1/CourseStructure.xsd">
  <course id="http://course-repository.example.edu/identifiers/courses/02baafcf">
    <title>
      <langstring lang="en-US">Introduction to Geology</langstring>
    </title>
    <description>
      <langstring lang="en-US">
        This course will introduce you into the basics of geology. This includes subjects such as
        plate tectonics, geological materials and the history of the Earth.
      </langstring>
    </description>
  </course>
  <au id="http://course-repository.example.edu/identifiers/courses/02baafcf/aus/4c07">
    <title>
      <langstring lang="en-US">Introduction to Geology</langstring>
    </title>
    <description>
      <langstring lang="en-US">
        This course will introduce you into the basics of geology. This includes subjects such as
        plate tectonics, geological materials and the history of the Earth.
      </langstring>
    </description>
    <url>http://course-repository.example.edu/identifiers/courses/02baafcf/aus/4c07/launch.html</url>
  </au>
</courseStructure>


Typically a course is delivered in a zip file that must include

  • A course structure file, named cmi5.xml
  • various media files that use relative URLs to other media files within the course structure
  • external materials can be accessed through fully qualified URLs

Alternatively, a single course structure file, using external resources, also can be used.

cmi5.xml is the equivalent of the imsmanifest.xml in IMS Content Packaging and SCORM 1.2.

cmi5 compared to SCORM 1.2 and 2004

According to cmi5 vs SCORM Comparison, “cmi5 builds upon the lessons learned from AICC and SCORM specifications, address the limitations of each, and adds new capabilities”.

cmi5 is simpler than SCORM 2004, but compensates this by allowing authors to record any data they want during the learning process. All SCORM versions are limited to a list of collected data.

cmi5 contents can reside everywhere, i.e. must be physically imported into the LMS

cmi5 uses a LRS, i.e. a standardized learning record store from which data can be retrieved in flexible ways.

There is no support for remediation in cmi5. We believe that since IMS Simple Sequencing was too difficult to implement and to understand for typical LMS authors and developers, remediation was removed. It cannot be replaced by the simple "moveOn" criteria found in the specification.

Data model

(This section needs to completed some day ....)

Supported xAPI verbs

xAPI is based on messages that can be sent from the LMS to the AU or from the AU to the LMS

Supported xAPI verbs in cmi5
Verb Description AU LMS
Launched Records that the LMS did launch the AU Store to the LRS
Initialized The AU will tell that it is initialized Send to LMS, must be the first statement sent.
Completed Indicates that the learner did all the required activities (views, quizzes, etc.) Send to LMS (only once)
Passed Learner passed one activity in the AU or the whole AU. Can include a scaled score Send to LMS, using a record LMS must use either Passed or completed to move on.
Failed Learner failed an activity Send to LMS
Abandoned Abnormal termination
Waived AU requirements were met by other means LMS can use this statement with a reason
Terminated Learner terminated activity
Satisfied Learner can move on (has met all the moveOn criteria)

A learner can pass or complete or (pass en complete) or (pass or complete)

Result

Result is a xAPI data structure that can contain the following properties (progress and reasons are cmi5 extensions)

Property
Score
Success
Completion
Duration
Progress
Reason

Links

Official

Project page

Specifications

CMi5 makes the use of the following specifications:

Other

Introductions and tutorials

Retrieved from "https://edutechwiki.unige.ch/mediawiki/index.php?title=Cmi5&oldid=74305"