SCORM, or Sharable Content Object Reference Model, has been a standard for e-Learning content for years. It dictates how e-Learning courses and Learning Management Systems (LMSs) communicate with each other. However, it has some limitations due to the lack of offline learning capabilities, limited data reporting, and the inability to track informal learning experiences.

To handle these limitations, xAPI (Experience API, also known as Tin Can API) was developed. xAPI’s powerful experience tracking capabilities allow it to collect detailed data about learner activities across various platforms and contexts, including mobile learning, games, simulations, offline experiences, and more.

The cmi5 standard is designed to utilize the best features of SCORM and xAPI. While using xAPI’s broader, flexible capabilities for tracking learning experiences, cmi5 also ensures the LMS’s control over the learning environment like SCORM.

The cmi5 specification defines a standard way of launching courses and communicating status back to the LMS, allowing it to incorporate and control the learner’s experience. cmi5 also standardizes the way that course completion, pass/fail, and scoring information should be handled to ensure consistency across different LMSs – something that xAPI leaves open to interpretation.

With cmi5, a course can both stand alone (distributed via a web server) or be hosted in an LMS, and in both these scenarios, tracking is done in a standard way, enabling seamless data exchange between different systems. With the standard definitions of the cmi5 for both ‘launched’ and ‘completed’ states, Learning Records can thus be interchanged more effectively between SCORM and xAPI systems.

So, in essence, cmi5 helps the interoperability of Learning Records between SCORM and xAPI by prescribing standard rules for launching, grouping of content, tracking session time, reporting back to the LMS, and so on – merging the flexibility of xAPI to account for multifarious learning experiences with the structured control of SCORM for successful data integration.

1. It allows offline mobile learning Unlike with SCORM, cmi5 courses can be taken both online and offline. Students can take course materials when there’s no Internet connection with special mobile apps. The progress will be saved and sent to the LMS once the connection is restored.
2. It records any kind of activity With SCORM, you can only store predefined parameters. Unlike SCORM, the data that cmi5 tracks is not limited: you can get detailed information on learners’ activity, such as: Store an audio recording of your student responding to a question Store a video of your student performing a task Store an essay written by your student It’s also possible to track images, PDFs, audio and video files, and simulations.
3. It enables studying outside an LMS SCORM tracks formal instructor-led learning and leaves out much of modern learning that happens outside an LMS. Consider gaming and simulations, social learning and mobile apps – all these sources can be used and tracked with the cmi5 standard.
4. It’s easier to implement While SCORM is complicated, the cmi5 specification is only a few pages. It works “on top of” xAPI, so if you know the latter, you should be able to implement cmi5 quite easily.
5. It allows content distribution If you have worldwide students and you really care about them, then save them from using SCORM. With this standard, content must be stored on the same server as your LMS. This means that learners from far away must be really patient with the content load times. The question is becoming even more important, as content modules are getting bigger and bigger. With cmi5, only the course structure is imported, not the actual content. This means that content itself can reside anywhere. You can choose to store materials on a content distribution network (CDN) with several servers around your country or even around the world, so when your students open the content, they will automatically connect to the closest server.
6. It provides a better user experience This is what Art Werkenthin, president of RISC, Inc. and a member of the ADL cmi5 committee, says about the SCORM problem with pop-up windows: If you have ever used SCORM, you know about the pop-up windows. With SCORM, you get at least two windows: one for the LMS and the other for the SCORM content. Usually, you get more than two because sometimes the SCORM content decides to have its own “player” window. If you are an LMS administrator, you know you have to watch out for SCORM’s arch enemy—the pop-up blocker! How many times have you answered a call from a student who says, “The content won’t open”? You dread going on the hunt for all the possible pop-up blockers that may be installed on the student’s workstation. (Tip from the trenches: I’ve found as many as seven pop-up blockers on a single machine.) Even if you clear out all the pop-up blockers, you still get the occasional student that hates pop-up windows … so they just close them immediately, thereby breaking your SCORM module. Finally, if you want to support mobile, pop-ups are a “no-no.” Luckily, this was one of the first issues addressed in cmi5. Content can now launch in the same window as the LMS. The LMS disappears and the content opens; simple as that. When the content is done, it disappears and the LMS returns—right where you left off.

Caliper’s information model outlines various concepts, rules, and relationships designed to encapsulate the behaviors exhibited by learners. These behaviors are illustrated through Caliper profiles (like annotation, forum, session, etc.), featuring Event Types where users partake in activities characterized by a specific vocabulary. Additionally, the model provides Entity types (like agent, attempt, result, etc.) to elucidate the interactions between participants and components. This comprehensive framework offers an efficient way to track and analyze learner engagement and performance.

For Caliper, JSON-LD provides the necessary representational horsepower to both describe these kinds of data linkages and specify how data is to be understood when published and shared across a network.

{
    "@context": "http://purl.imsglobal.org/ctx/caliper/v1p2",
    "id": "urn:uuid:fcd495d0-3740-4298-9bec-1154571dc211",
    "type": "SessionEvent",
    "profile": "SessionProfile",
    "actor": {
        "id": "https://example.edu/users/554433",
        "type": "Person"
    },
    "action": "LoggedIn",
    "object": {
        "id": "https://example.edu",
        "type": "SoftwareApplication",
        "version": "v2"
    },
    "eventTime": "2016-11-15T10:15:00.000Z",
    "edApp": "https://example.edu",
    "session": {
        "id": "https://example.edu/sessions/1f6442a482de72ea6ad134943812bff564a76259",
        "type": "Session",
        "user": "https://example.edu/users/554433",
        "dateCreated": "2016-11-15T10:00:00.000Z",
        "startedAtTime": "2016-11-15T10:00:00.000Z"
    }
}

See example in spec here: https://www.imsglobal.org/spec/caliper/v1p2

Here is an example of an IMS Caliper Analytics JSON-LD event statement. Please note that this example shows a simple reading event where a student has viewed a reading material:

{
    "@context": "http://purl.imsglobal.org/ctx/caliper/v1p1",
    "id": "urn:uuid:a50ca17f-5971-47bb-8fca-4e6e6879001d",
    "type": "ReadingEvent",
    "actor": {
        "id": "https://example.edu/user/554433",
        "type": "Person"
    },
    "action": "Viewed",
    "object": {
        "id": "https://example.com/etextbook/2018/geometry/chapter1",
        "type": "DigitalResource",
        "name": "Chapter 1"
    },
    "eventTime": "2018-08-01T06:00:00.000Z"
}

In this JSON-LD example:

• @context provides the context for the data, which is the URL of the Caliper context document.
• id is the Unique Event Identifier.
• type is ReadingEvent, representing the event of the actor viewing the object.
• actor is represented by the user identifier and type.
• action signifies the type of action the actor performed. In this case, Viewed.
• object contains the specifications for the object viewed by the actor, followed by its ID, type, and name.
• eventTime provides information about when the action occurred, in a specific ISO 8601 format.

Similarities:

1. Both are used for tracking learning experiences: xAPI and IMS Caliper are both designed to track, store, and retrieve data about learning experiences.
2. JSON-based data: Both xAPI and IMS Caliper records are based on JavaScript Object Notation (JSON), making them lightweight and easy to work with.
3. Detailed Learning Analytics: Both standards facilitate deep and granular learning analysis by allowing the tracking of fine-grained learning activities.

Differences:

1. Messaging Philosophy: The xAPI follows an Actor-Verb-Object (e.g., “John completed a quiz”) paradigm which offers great flexibility and granularity. In contrast, IMS Caliper models events based on Metric Profiles (e.g., Reading, Assessment, Media, etc.), which categorizes activity types, offering a more structured schema.
2. Interoperability Scope: xAPI is somewhat more versatile given its application goes beyond just the web environment. It can track learning experiences across various platforms like mobile learning, games, simulations, and even offline learning. IMS Caliper, although comprehensive, primarily targets web-based digital learning environments.
3. LRS vs. Sensor API: xAPI uses a Learning Record Store (LRS) to store and retrieve learning data. However, Caliper uses a Sensor API approach, where different ‘sensors’ input data based on the event that has happened.

As for the translation of IMS Caliper learning records into xAPI format and vice versa, this typically requires middleware or a translation service that can understand both schemas. This software would map the fields in a Caliper event to their corresponding fields in an xAPI statement, create a new xAPI-compliant statement, and send it to an LRS.

Such a solution could theoretically be developed using technologies like Python or Node.js, but it’s important to note that this translation process would require a solid understanding of both specifications to ensure accurate mapping and maintenance of data integrity. As of now, there’s no widely recognized or commercialized software that offers this specific translation between Caliper and xAPI. However, developers and educators in the desire or need of such a service usually design it based on the unique demands of their systems.

Ultimately, both standards are designed with a similar goal: to improve the understanding of student learning through analytics. The right one to use often depends on the specific use case, or an institution may choose to use both in different contexts to fully cater to their analytical needs.