An Initial Experience of the xAPI
September 15, 2014
This blog represents my own opinions about the xAPI from my personal experience with it and does not represent the views of everyone maintaining Learning Locker. I do however share some of the thoughts shared by Aaron in one of his recent blog posts and I would suggest that anyone reading this also reads that.
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 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.
Separated Parts
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 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 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”.
Conclusion
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.
Got a learning problem to solve?
Get in touch to discover how we can help
