IMS Caliper published – we now have a clearer picture how activity streams should be described


IMS Caliper, claimed to be “the world’s first interoperability standard for educational click stream data”, is now publicly available after a long period of testing among the consortium members. A Best Practice Guide, an Implementation Guide, and a Conformance and Certification Guide have been published together with a number of code libraries for Java, Javascript, Ruby, Python, .Net and PHP. There is also a Event Store available only for testing, as Caliper “does not include an open, standard based event store/LRS in its initial scope”.

There is no separate document outlining the information model of the new standard, but rather a collection of models. As explained by the Implementation Guide “the events and entities collected into metric profiles serve as the information model for Caliper”. There are profiles for different types of learning activities, like Assessment, Reading, Media, etc. There is, however, a Base Metric Profile, defining the core concepts for the Entities participating in Learning Interactions, and what constitutes an Event. An Event captures the Entities and Actions performed in a learning event, and consists of actor, action and object as required elements, and seven more optional elements describing what is generated, what is targeted, and so on.

Caliper high level illustration

IMS Caliper High Level Illustraton

The publishing of the standard was accompanied with the announcement that nine vendors have achieved conformance certification to the newly released Caliper Analytics standard.

RAM is not RAM any longer

Somewhat confusingly for the uninitiated, IMS has also had a parallel activity to Caliper, called RAM (Real-time Analytics Messaging) “to implement real-time, actionable messaging alerts”. According to the Implementation Guide, this work has now changed its name to IMS HED Analytics group. It is said to relate “to requirements to leverage a more minimal event with a free-form payload”. The current released Caliper v1.0 sensorAPI and CaliperEvent implementation and conformance validation support will be revised to a “transport” level of use”, informs the Guide.

“Interoperability standards that don’t interoperate”?

The publishing of Caliper will be met with great interest by the learning analytics community that has grown impatient waiting for an opportunity to compare Caliper with Experience API, the other activity specification in the field.  One of the first tweets  with the #imscaliper hash tag after the publications read “consider current disparity between #xapi & #imscaliper, interoperability standards that don’t interoperate”. It remains to be seen whether this is actually the case, or whether the differences between the two specifications are more a question of Caliper being more detailed in specifying a limited set of profiles, while xAPI keeps the specification and the profiling activities (recipe making in xAPI speak) separate.

If the alignment between xAPI and Caliper is to prove an easy match then this will also be to a great extent a question of politics and culture. The relationship between IMS and ADL has been tense at times, and the response  to xAPI community suggestions to map out the differences may suggest that IMS will be reluctant to find common ground now that they have a specification with some uptake in the US higher education market. 

Getting started video IMS Caliper



About Author

Tore Hoel is affiliated with Learning Centre and Library at HiOA, and has been working within the learning technology standardisation community for more than ten years. He is now working on Learning Analytics Interoperability within the LACE project.


  1. It seems like the glory old days of the ADL Scorm vs IMS common cartdridge debate are back again. ..
    Presumably (and hopefuly) Caliper can show how the good & simple ideas embedded in the original Xapi design may be taken forwards towards practicality and implementation with detailed vocabularies and registries. ..This is the main contribution us vendors expect from a solid community of clustered stakeholders (as that of IMS in the case of the educational sector).

    But we have a risk…

    The risk is again that smart people discuss and argue on the differences of their achievements rather than highlighting and explaining to vendors and adopters (the interest of which will be the main if not only measure of success for the new spec) how profiles and recipes may take a generic spec into real world implementation adding context and detail…
    If we explain this better rather than positioning Caliper as yet another alternative to Xapi, the uptake in the solution provider and adopter communities will be tenfold.

    In a nutshell we should better clarify that Xapi and Caliper are just sitting on different levels of detail…not really competing one with the other.

    In the Scorm age it was the other way round (eg ADL profiling specs originally from IMS) but the effect of wrong explanation and marketing was the same: competition amongst smart (learning) specs developers rather than massive adoption…

    Standardising user activity analytics and KPIs is going to be a key battle field in the next future .And not only in learning technologies..
    THE risk is that we…(smart)learning technologies people rather than unite and implement multi layered specs… spend time arguing and debating once again rather than understanding the different layers and worlds each spec addresses ..
    At the end someone might come in from outer space and take the analytics standard movement and push much faster than us..
    And in standards, the Winner Takes it All…in the end it might take learning also…

    FOR MORE ON THE TOPIC AND A VENDOR PERSPECTIVE read my ‘Dont worry be Xapi!’ Post on the Lace web site

  2. A key difference between caliper and xapi seems to be the governance model. While Caliper is strictly controlled by IMS, xAPI governance (at least so far) allows for a highly extensible de-centralised creation of usage experience, for example allowing communities of practice to introduce their own verbs. While the xAPI de-centralised approach is harder to coordinate, it may be better suited for experimental and research work while Caliper is more appropriate for production environments to the extent to which their needs can be served in the provided framework.
    I fully agree with Fabrizio on the potential danger of having two overlapping specifications. The best answer, probably, is being pragmatic, using what suits best and looking forward to someone providing translations of what can be translated (probably translating [parts of] Caliper sensor events to xAPI learning records is the lowest hanging fruit).
    After all, standards are not set by Committees but by those who provide affordable, easy to use tools ….

  3. Fabrizio, the trouble is that IMS have chosen to create Caliper to cover some of the same areas covered by xAPI but without building on xAPI. They are technically competing and non-compatible specifications sadly.

    Governance/license is a big difference as Ingo mentions. A big technical difference (at least from my reading of the documentation linked above) is that whilst xAPI statements have unique ids enabling them to be shared between networks of learning systems, Caliper ‘statements’ do not have ids at all. Presumably then Caliper can only be used internally within an LMS, or in very specifically delimited systems.


Leave A Reply