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 serves as CEO for Learning Pool LTD, with responsibility for the commercial, product and people functions based mostly in the UK, reporting to the Group CEO.
Previously, Ben served as Chief Product Officer for Learning Pool where he worked to help define and develop Learning Pool’s next generation of workplace digital learning platforms, with a focus on Learning Experience Platforms and the Learning Analytics space.
Before Learning Pool, Ben helped to build HT2 Labs from humble beginnings into a globally recognized innovator in workplace digital learning. Learning Pool completed an acquisition of HT2 Labs in June 2019.
Ben’s expertise is based in research, having previously completed his PhD researching the impact of gamification on adult social learning, Ben has authored and contributed chapters for many books, has two peer-reviewed academic papers and has presented at conferences around the world, including TEDx.
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