What Is The xAPI Format?
The key to understanding the xAPI format is understanding xAPI statements. If you have read much about the xAPI previously, chances are you have come across the idea of an « xAPI Statement, » that is, the manner in which we transfer data between the Provider, the LRS, and the Consumer. That statement takes the form of what we call a « triple »: An Actor (John Smith), a Verb (completed), and an Object (a Learning Activity). To extend the meaning of the statement, we add context about John Smith, the Verb, the Object, and the wider circumstances in which the activity took place. This context might include details like where John Smith was in the world when the activity occurred, what course the learning activity was part of, and how long John spent on the activity, for example.
eBook Release
Download this eBook and discover why and how you too should be using xAPI.
Using this simple format, you can understand what has been done, anywhere – be it on an LMS, application, mobile device, even on the point of sale device. In fact, pretty much any device that can be connected to the internet can be translated into this format. Technically speaking, xAPI statements are parsed using JSON – JavaScript Object Notation. JSON looks a bit like XML, but it is generally simpler to follow and more lightweight – it takes fewer characters to write what you mean. Whilst it might look a little odd at first, JSON is quite readable as a format. Understanding JSON, of course, also helps a lot towards understanding the xAPI format.
How Does The xAPI Work?
In an xAPI world, we talk about « Activity Providers » (APs), Learning Record Stores (LRSs), and Activity Consumers (ACs). Activity Providers create data in the xAPI format and submit it to the LRS. APs are systems and applications on which learning activities and events take place. Learning content, learning portals, apps, and more can all behave as « Activity Providers. » In an xAPI ecosystem, we expect many Activity Providers to be submitting data to the LRS at the same time. Learning Record Stores are databases that verify that the input matches the xAPI specification, storing all valid data for retrieval by Activity Consumers or by administrative users who wish to access the « raw » xAPI data for analysis. Activity Consumers are similar systems to Activity Providers (an AP could, in fact, be an AC as well), in that they are typically systems and applications that modify the user experience based on xAPI data. This might be an LMS that « checks off » a completed learning activity because that activity appears in the LRS. Or it could be something more complex; a leaderboard, a badge issuing system, or learning content.
For example, if you had a piece of eLearning content that was set to track via xAPI, we would consider that the « Activity Provider »; it is the source of the learning activity data. Understanding this is vital to understanding the xAPI. This activity data would then be sent to the LRS in the form of an « xAPI statement. » The LRS would accept the data (providing it is valid) and store it. Later on, an administrator may visit the LRS to check on a learner’s progress, which is stored here. Another piece of eLearning content might also consume this data, making it both an Activity Provider and Consumer. When acting as a Consumer, the eLearning content could advance the user onto a point deeper into the learning activity, bypassing content that the learner probably already knows if the relevant previous experience is found in the LRS.
eLearning is just one example of an activity provider. Learning Management Systems (LMSs), mobile apps, portals, smart devices, and other software packages, like CRM, could all be sources of xAPI data. Almost all of these sources could also be consumers under the right circumstances. We also see analytics programs, certification and badging platforms, and other Learning Record Stores (LRSs) as likely consumers of xAPI data.
The Statement API is immutable to avoid issues of data being tampered with or otherwise altered after it has been sent. That is, you can’t edit or delete a statement after it has been sent. If you have genuinely inserted a statement by mistake (or with the wrong detail), then you can use the « Void » technique to render the previously-stored statement redundant (more about Voiding later). But you won’t find an LRS with the ability to directly edit or even delete a statement as it is not a feature of xAPI. There is a lot more to statements than that, and wewill go into more detail about additional context later on, but statements aren’t the only thing we can talk about using xAPI. In fact, the xAPI specification actually gives us four different API « endpoints » to which we can submit data and get data back. These are the Statement, State, Agent Profile, and Activity Profile APIs.
Conclusion
Are you keen on understanding the xAPI and its amazing potential? Download the eBook The Learning Technology Manager’s Guide Τo xAPI and begin your amazing journey.
