The definition of learning in Google dictionary is “the acquisition of knowledge or skills through study, experience, or being taught.”. Even under the three basic headings of study, experience and being taught we can group most events in any given hour, on any given day, week, month or year and call them learning events.
Humans are learning machines, everything we experience is a learning event that either confirms and re-enforces previous learning or provides us with new knowledge, perspectives, skills, experiences and expectations.
Learning is something we do naturally, and we do it all the time.
So, what is learning is in the sphere of L&D or Training departments?
In this context, learning is an event that can be reported on! Which means that the learning event must be one which the Department has control over. This means controlling the access, delivery media, timeframe and the success criteria for that event. Just look at the standard training delivery formats of eLearning or face to face training. Both formats are all about control of the training delivery down to the time and location and they also look at learning at a more macro/broad topic level.
Outside of eLearning and face to face training, people are still learning and acquiring skills and knowledge all the time. But there is a gap in our ability to acknowledge and report on these uncontrolled micro learning activities.
It’s this gap between defined learning courses and more learner driven learning experiences that xAPI has been developed to fill. xAPI is a method we can use to report on learning experiences that happen within our existing delivery structures and also through any other networked device, application, media or object.
So xAPI is really about learning related data. Getting more data, getting better data, getting constant data and being able to report on this data.
To make this happen xAPI needs 3 things:
- A standard data statement being generated by the experience of the learner – this statement structure effectively states “I did this” for any learning experience
- A method to transfer the data from the experience to a database – this is coding that is either already embedded within the experience or needs to be added by you (or a company who can create this code or who provides a connection to experiences that pre-coded)
- A place to store the data being generated by the learners – this is called a Learning Record Store or LRS
But before we get to those concepts one quick home truth. We are dealing with electronic data here, so as some point the details of the learning training experience needs to travel to the LRS, so connectivity will be required at some point in this process, but it does not need to be constant. For instance data captured on a tablet device whilst the device is off-line can be downloaded to the LRS once the connection is re-established, but a connection will be required at some point.
Let’s touch on each of the 3 xAPI components in a little more detail.
Standard data statements
In order for the learning records to all make sense a standardised structure has been created around the “I did this” concept, since each leaning event being tracked means that the learner has done something. When a learner does something a “statement” is sent to the LRS that contains three components:
- The Actor is an individual or group being tracked in the Statements. (The I in “I did this”)he Actor
- The Verb is the action being done by the Actor within a Statement. (The did in “I did this”)
- The Activity is the something with which an Actor interacted. It can be a unit of instruction, experience, or performance that is to be tracked. (The this in “I did this”). Interpretation of Activity is broad, meaning that Activities can even be tangible objects such as a pump or motor. Other examples of Activities include a book, an e-learning course, a calendar event (such as a meeting) and a physical event (like walking to specified destination).
The method of transfer
Depending on your technical know-how this part of the xAPI story may lead you to work more closely with a content vendor, such as B Online Learning, that understands coding. To get your xAPI statement (I did this) to your LRS you will need to have computer coding, embedded in the device or program or object that the Actor is working on or with, that will pick up the details of the learning event and transfer those details via a web link to the LRS.
There are several different coding languages that xAPI can work on such as Java, PHP, Python or .NET to name only a few, but this is really the critical aspect of XAPI as it is a properly formatted code that mean the difference between being able to track and report on learning events and getting no tracking and reporting at all.
We will cover some different examples of where this coding can be applied to get a practical outcome in an upcoming blog.
Learning Record Store (LRS)
This is basically a computer server that is responsible for receiving, storing, and providing access to Learning Records. The LRS differs from a Learning Management System (LMS) in that the LRS is all about accumulating data records and LMS authenticates learners, registers them in courses and assessments then completes those courses and assessments.
An LRS can part of a larger Learning Platform like Birch or it can stand alone. We will cover how Birch works with xAPI data and why having an LRS embedded within your learning platform makes a great deal of sense in an another blog soon.