By jPablo Caballero | January 5, 2017
Sometimes the wording used to describe xAPI portray it as something that it’s not. This can a source of confusion. Read on to find out why.
Sometimes introductory texts about xAPI do say that it is a specification, but later talk about it as if it were a system, a piece of software that does something. xAPI is not a software system. It is a specification for an API. So, it is a document, a set of rules, that tell programmers certain things that they need to implement in their systems. If the systems implement those certain things following the rules prescribed in the specification, those systems will get along: they will be able to communicate amongst themselves, and they will have a common understanding of what the data they store and transmit means.
When reading or hearing something about xAPI, take notice of the language used, as that may help you separate the useful information from the hype-ish talk. For example, there’s an article somewhere that conveys the following (not quite literally, but almost):
xAPI will be able to tell us [many details about the learning experience]. It will analyze everything… it will look for trends… it will give full reporting… it will discover correlations between learning activities, results and performance…
If you see or hear wording of that nature, be cautious. As a specification, xAPI does not do anything, it just tells developers how to implement things in their systems. So, an assertion like the one shown in the example above, really sounds like there is a magical system that will be doing all those things… Wording like this should be raising red flags in your mind. Probably whoever expresses things like that is well-intentioned and just wants to stress the potential of xAPI, but this is the kind of language that leads to hype. Let’s see how those ideas could be expressed differently:
A “learning experience” (be it a traditional eLearning “course”, an electronic medical dummy for CPR practice, a simulator, a social network, or whatever) may be programmed to report many details about how the user is interacting with it.
If that learning experience conforms to xAPI, it can transmit all these details in a standard and consistent format to another system for storage (LRS).
Some other system may retrieve -again, using xAPI-prescribed methods- those details, and run analyses to discover trends, and to emit reports. Or maybe the LRS itself implements analysis/reporting/graphing capabilities.
Other non-learning system (e.g. a financial system, a CRM, the computer on a vehicle) might also generate usage data in the xAPI-prescribed format, and transmit it to maybe the same analysis system mentioned before.
Then, the analysis performed using both Training Data and Performance data might find correlations between behaviors during training and behaviors in the “real world”
Of course, this wording is more verbose and sober, and not so exciting… but it’s also less hype-inducing. If the objective is to help people learn about what is involved in an xAPI scenario, we shouldn’t just say “xAPI can do a million wonderful things” and not say a word about how.
So, it’s not that xAPI can do a bunch of cool things. It’s a bunch of disparate (and maybe complex) systems, that can communicate with and understand each other thanks to xAPI. They are separate systems, somebody has to create them, configure them, and somebody has to plan how they all should work together, etc. They don’t automagically exist because xAPI exists. And certainly xAPI doesn’t do all those things. In fact the specification doesn’t even say anything at all about analysis and reporting, for example.
readingtime: 136