If only everything worked together…

Last time out I talked about the issues that stop our learning systems working together and the problems that causes. I concluded that adopting a standard way of talking about learning activity across the organisation, using a well-defined data structure, is the key to cracking the problem.

And, right now, the best option open to us the xAPI specification.

xAPI is not some magic token that will solve data interoperability on its own. It is simply a way in which we can define the data that we share between systems. If you buy learning systems it should be on your checklist to ensure that the data generated by whatever system you are going to bring in has the potential to operate within your ecosystem.  

Choosing a Learning Record Store

An essential part of the xAPI is the Learning Record Store (LRS). This is the intermediate piece that takes data from one system, stores it and makes it available to other systems. It means that in the xAPI world, your various parts of the system do not talk directly to each other, they communicate through the LRS.

The first thing you need to know about a Learning Record Store is that not just anything can legitimately call itself an LRS. Unlike an LMS, or VLE, or LCMS, or whatever other e-learning acronym you come across, an LRS must meet a very specific set of rules in order to be considered ‘conformant’ to xAPI rules. Only then can it be considered a Learning Record Store.

This is important because one of the absolute key functions of the Learning Record Store is to check that data is valid according to the xAPI specification. And there are a lot of nuances in doing this:If your LRS does not do this to the letter, then you may be storing data that you cannot use again.

As data piles up in the LRS it will slowly become obvious that you can’t connect it to the other systems. And that’s where you hit a catch; xAPI data is immutable, you cannot change it. If you spent a year collecting garbage data you couldn’t do much about it once you found out.

Better to check the LRS you want is conformant before you start collecting. Any reputable vendor in the space (Learning Locker included) will be able to show you the results of conformance testing they have carried out.

Getting Data Flowing

You’ve got three broad choices to get data into the LRS:

  1. Use the xAPI features of your applications
  2. Use each application’s API to translate to xAPI
  3. Grab any data you can and parse it into xAPI

…so let’s take a look at each in a bit more detail to identify the best method for you.

1. Use the xAPI features of your applications

The first option is ideal; use the xAPI features of your applications. If the other parts of your eco system already use xAPI then getting them to send this data to the LRS is simple. Your LRS will give you a set of credentials (think username and password) which you can store in the activity provider along with where the data needs to be sent (we call this the endpoint). That is it. The two are connected.

2. Use each application’s API to translate to xAPI

The second option is perhaps more realistic to expect. Whilst a lot of applications have adopted the xAPI as a standard feature, many more have not. Do not take this as a sign of slow progress. Application providers may have to do a good deal of behind the scenes work to get xAPI going. Standard ways of working are slow to emerge, especially when older, incumbent specifications get in the way. Work started on HTML5 in 2004 and took 10 years to become the current standard for HTML. It still isn’t fully adopted. xAPI is on the way to doing this in half the time.

For many of these ‘yet to upgrade’ applications, there is a halfway house; take what they already do and translate it into xAPI format. This isn’t something you are going to do without a developer or two, but the process will be a familiar one to anyone who deals with data and technology. We worked with the Charity Learning Consortium (CLC) to create a plugin for Moodle that took the existing Activity Log, expanded it a bit to get the right data in place and then translated it to xAPI. We standardised the approach somewhat, so that you could apply the same logic to any other application. It’s a couple clicks to install and it works.

3. Grab any data you can and parse it into xAPI

The final option is the messiest. Grab any data you can extract from an application and turn it into xAPI format. This isn’t something you want to do by hand, this is a job for developers. And it’s not likely to happen in real-time; it’s more likely to be historic data that you are capturing or, at best, a process that runs every few days.

You can use the same basic logic that we do with the Moodle plugin, only you have to feed it manually instead of hooking it to a pre-existing system. And this presumes that you can download the right data at all in the first place. If you can get data into a CSV format, developers can probably do something with it. If you can’t get that it might be a lost cause. But then again, if you can’t get this data out in some form or another, it’s not likely to be a hugely significant part of your ecosystem.

Example Learning Ecosystem

Your New Learning Ecosystem

Adopting xAPI and a Learning Record Store will give you the opportunity to re-think your approach. Where previously we could only recognise experiences that happened on the LMS, now we have a way to recognise work from any web-based application (and a few that aren’t even on the web).

Thousands of learning providers have popped up over recent years. The race is on to aggregate third party providers and start recognising the work people do outside of the LMS as part of the learning blend. With the xAPI at the heart of your strategy, we can actually start doing this today.

If you’re ready to take that step and are interested in finding out more about how xAPI can benefit your organisation, get in touch – we’d love to talk you through things and get you set up with Learning Locker to help find your feet.