Understanding how the Experience API (xAPI sometimes known as Tin-Can API) is structured is the first hurdle to knowing just how flexible and powerful the xAPI can be.
If you consider this: you have a Learning Management System (LMS) as part of your Virtual Learning Environment (VLE) and you want to know WHAT, WHERE, WHEN and by WHOM interacted with your learning object. Sure, there are learning analytics that come with the LMS, but xAPI gives you so much more. Now, let’s say you’ve an innovate instructional designer or computer-based training developer that wants to add a video with overlaying questions. They’ve done their research and decided that want to add a H5P learning object into one of the courses – awesome! BUT, your LMS doesn’t natively host H5P – bugger. Fear not, it can be hosted externally, or there are other ways to embed it into your LMS. As the H5P is external to your LMS – how are you going to capture how the student engages with the H5P learning object? More to the point, how are you going to know what the student experienced.
As we said, H5P is not native to your LMS, so no learning analytics there, except maybe they entered the course, not much to go on really. Enter the flexibility of xAPI.
As the Learning Record Store (LRS) where you store your xAPI Statements is external to your VLE (or internal, doesn’t really matter as long as you can see it) your H5P object can pass an xAPI statement to the LRS and capture the experiences the student is being exposed to. Experiences such as viewed, interacted, attempted and answered as well as completed. These are known as Verbs and there is a predefined set of Verbs at https://registry.tincanapi.com/#home/verbs
There is a little caveat to this, especially with H5P. You may need to do a little programming to get the xAPI statements that H5P generates to be sent to the LRS.
When you look at the structure of an xAPI statement, there are three main sections that will get you started:
Actor : Verb : Object
The ACTOR part is WHO did it. Who was the person that actually engaged and had the experience. This is usually defined by an email address, as these are generally unique. This can also be a GROUP, but only one or the other.
The VERB is the HOW or the action that took place during the learning experience. Verbs are usually predefined. I say usually as you can create your own Verbs, although you should stick with what’s be defined. xAPI is still very much an evolving technology and VERBS are one area that should remain centralised. A VERB objectb will contain the name and an ID. This ID is a URL and will contain the definition of the VERB. This is critical as a word can have more than one meaning. Take the verb RUN for example. Was the experience based on a command that was RUN from a command line? Did the user RUN to a destination? These are two words that spell the same but have different meanings. It’s critical that the link (or ID) of the verb point to the correct definition. Think of it as meta-data for the verb.
Finally, the OBJECT. This is WHAT happened in the experience and this can be pretty lengthy and equally as complex. This is where you can capture the most amount of data. You’ll see what I mean in the example below.
With all this said, the learning curve to discovering more about xAPI and the flexibility it has can be a lengthy and sometimes confusing process. There are plenty of resources out there that step you through each facet of the xAPI Statement. I thought I’d put my spin on a resource in a way that helped me understand the structure and hope that it helps you in your journey of xAPI discovery.
Click on the image below to view a statement containing some (there’s a few more I’ve not added) of the aspects of a xAPI statement. Simply click on any of highlighted areas to find out more information and a link to the spec.