This month’s edition of Learning Corner features guest contributor Andrew Downes, a Learning 
and Interoperability Consultant with Watershed LRS, discussing data portability and how to ensure that your data is portable.
Andrew has a background in instructional design and development—including the creation of learning content, experiences and platforms—in both the corporate and academic worlds.
Andrew is a leading thinker in Evidence-Driven Learning Strategy and Learning Technologies Interoperability. Andrew helps organizations develop learning strategies based on evidence and evaluation, working with vendors to get at data from the products those organizations use.
One of the authors of the Experience API (xAPI) specification and much of the content on experienceapi.com, Andrew is recognized as an expert in xAPI and has delivered numerous presentations, webinars, and training sessions across the globe.
Andrew maintains a number of open-source code projects, including two xAPI-related Moodle plugins. He’s a contributor to several other open-source projects, including Learning Locker LRS.
How Portable Is Your Data?
Data portability, or the ability to move data between systems, is especially important in learning. Being able to collect data that’s scattered across multiple systems and bring it together in one place allows us to make sense of that data as a whole.
With growing adoption of xAPI, data portability is getting a lot easier for learning records. Products that adopt xAPI can be connected much more easily than those that don’t. However, using xAPI doesn’t guarantee a smooth integration, at least when it comes to making use of and interpreting data. That’s why it’s important to keep a few key items in mind to ensure the best portability of your learning records.
SCORM vs. xAPI
SCORM was designed in part to provide data portability from an e-learning course to a learning management system (LMS). However, it doesn’t provide a mechanism for moving data out of the LMS, or for bringing in data from other sources.
xAPI, on the other hand, is designed for universal learning records portability. That means you can use xAPI to bring data into your LMS and also get that data out again. This is especially important when you want to bring all your data together into a central Learning Record Store (LRS), and when you want to migrate your learning records to a new LMS.
Not all LMSs that advertise xAPI support provide ways for you to get data out, so be sure to ask LMS vendors to show you how to get your data out of the LMS and into another system.
xAPI vs. an LMS’s API
Many LMSs implement their own APIs, which you can query to get your data out. This is good, but it’s not good enough. An API that doesn’t follow an interoperability specification means that you’re forced to create an integration for every system you want to link—and that takes time and money. On the other hand, when implemented properly, xAPI enables you to configure a connection to send data to another LRS in less than 15 minutes.
3 Tips to Ensure Data Portability
Even where you’re using xAPI, you’re not guaranteed a completely smooth integration—at least when it comes to making use of and interpreting data. xAPI is a flexible specification that allows data about a wide range of activities to be tracked. This flexibility also means that it’s possible to send nonsense data. If you’re developing your own xAPI tracking or trying out an xAPI-tracked application, there are three tests you can apply to help ensure data portability.
1. Validate your data against the strictest LRS you can find.
Some LRSs are stricter than others when it comes to accepting xAPI statements. At first glance, a less strict LRS might seem like a good option to test your data since it’s easier to write statements that appear to work. A stricter LRS, however, will help you avoid problems in the long run, as statement restrictions will always be in place to ensure learning record consumers can interpret the data correctly. Without strict validation, you run the risk of building up a collection of statements that end up being very difficult to work with when you come to want to make use of or transport the data in future.
I recommend testing xAPI statements against a SCORM Engine-based LRS—such as Watershed, SCORM Cloud, or RISC VTA’s internal LRS. If you choose Watershed from that list, you’ll also have access to a debug log of all errors messages so you can review them later, and more detailed error messages. Wax LRS is another, non-Engine-based, LRS that offers strict validation of statements, clear error messages and debugging tools.
This rule applies not just to testing. When building an ecosystem that involves multiple LRSs, try to have the data coming into your strictest LRS first, and then funneling onto any other LRSs. This protects your ecosystem from bad data and avoid the scenario where data exists in one LRS but not the other.
2. Make sure your data tells a story.
Getting valid xAPI statements is only half the battle. It’s entirely possible to send valid xAPI statements that don’t communicate anything meaningful about learning activity. For example, I’ve seen streams of statements where it’s impossible to tell how many attempts the learner had at the activity, or to figure out the time spent from multiple reported durations.
Getting valid #xAPI statements is only half the battle. It’s entirely possible to send valid xAPI statements that don’t communicate anything meaningful about #learning activity. #data Share on X
Test your statements by asking someone who has a working knowledge of xAPI, but who is unfamiliar with that particular learning activity, to review them. Using only that statement data, he or she should be able to accurately understand and fully describe a learner’s interactions. f a human can’t understand what’s going on then a computer program such as a report doesn’t stand a chance. Make sure you’re tracking what happens with all the relevant detail and that you’re only tracking it once. Reach out to experts for help if you need it.
Recipes and profiles such as cmi5 can also help with telling a clear story, as they set out a template to follow. Don’t assume that just because you follow a recipe that you can skip this test though. You still need to make sure your data makes sense.
3. Test against tools that consume xAPI data.
Finally, the most important step in making sure your data is portable and useful is to test it against some of the tools that will ultimately consume the data. For instance, after ensuring my statements are valid and tell clear stories, I load them into Watershed reports to see how the data is represented. Seeing the data visualized will often alert me to problems with the statements that I miss when looking at the raw data itself.
Make sure your testing tool properly consumes and interprets all of the statements’ details. For this test to be useful, avoid reports that simply count statements or verbs, as they don’t focus on the details that ultimately provide the insights you want. Consider the questions that stakeholders might ask about the data and then try building a report to answer those questions. If you can’t build a report, then either your reporting tool or your data are limited.
Final thoughts
Data is valuable. It’s important that it’s portable, or we’re forced to leave it behind. xAPI really helps with data portability, but it’s not the complete solution. Validate your data against a strict LRS, ensure your data tells a story, and test the usability of your data with the proper tools.
Data is valuable. It's important that it's portable, or we're forced to leave it behind. #xAPI really helps with #data portability, but it's not the complete solution. Share on X
LinkedIn - https://www.linkedin.com/company/riscinc
Twitter - https://twitter.com/RISC_Inc (@RISC_Inc)
Facebook - https://www.facebook.com/RISC-Inc
For more information or a demo of RISC's learning management ecosystem, contact us at sales@risc-inc.com.