I have been interacting with the xAPI for over a month now and whilst I can see why it’s useful in terms of analysing experiences to enhance learning, I can’t see it becoming a useful standard in its current form due to a lack of separation and adoption. I believe the specification must be separated into smaller specifications to (a) increase adoption, (b) reduce complexity, and (c) encourage modular implementations.
Benefits of Separation
Splitting the specification into smaller specifications can increase adoption since other specifications can use the same parts. For example the xAPI currently shares parts with Activity Streams but these parts have been completely re-specified by the xAPI when instead the parts could be specified in the same way in one specification to improve interoperability between the two specifications. Additionally, increasing adoption means that there are more people maintaining the specification.
Reducing the complexity of the xAPI may also increase adoption since it becomes easier to understand for newcomers. This would be achieved by splitting up the specification into smaller parts as (a) these parts could be used in other specifications that newcomers could be familiar with, and (b) the dependencies of the parts and their scope would be far more obvious.
Finally, splitting up the xAPI would probably encourage modular implementations, for example someone may just want to validate that the data meets the specified data model instead of implementing the API too, etc. Multiple LRSs could then use the same validator and have their own API implementation hence reducing their workload.
I’m not 100% on what the parts could be, but I like to look at the specification from a MVC perspective since it seems that the specification has already defined a model and a view (the API). The controller would therefore supply the API with the model most likely from a Database or an external source.
The model could be limited to representing an experience and could be split up further to share parts with the Activity Streams specification (such as the actor, object, etc). The model could also be specified in such a way that it may be used in XML, JSON, and other similar formats. Aaron also refers to this as “A standard for the Data Model” in his blog post.
The scope of the API (view) could be restricted to creating and retrieving experiences so that they can be analysed and shared. I’m unaware if this is true but parts of this API could also be split if it shares parts with other specifications such as the Activity Streams specification. This is referred to by Aaron as “A standard for the Statement API”.
Finally, the scope of the controller could be maintaining the data such that it continues to comply with the specified data model so that it can be retrieved correctly via the API. Aaron refers to this as “A standard for the Learning Record Store”.
A standard is “an accepted or approved example of something against which others are judged or measured”, yes the xAPI meets the definition of a standard for the most part, but the specification must improve to gain greater adoption otherwise it’s likely to become stagnant and useless.
The first steps to improving the specification, in my opinion, are to split the specification up into smaller parts.
Ben Betts was one of the founders of HT2 Labs and his work with the company helped to define the ‘next generation’ of workplace digital learning platforms. Under Ben’s direction, HT2 Labs were amongst the first to put gamification into a Learning Experience Platform. They were the first to really grasp how social learning could be applied in the workplace. And HT2 Labs were the first to release an enterprise-ready Learning Record Store.
As Chief Product Officer, his focus is now on developing Learning Pool’s product portfolio and strategy. For the wider industry, he’s also focused on helping companies learn from employees’ collective experiences, on the role of self-directed learning in the workplace and on social learning, gamification and xAPI.
Get started by telling us what you need and one of our team will be in touch very soon.
+44 207 101 9383
US +1 857 284 1420
+44 345 074 4114*
US +1 844 238 5577
* call charges vary depending on your provider