As I’ve come to understand the xAPI standard for learning experience data interoperability I’ve found it interesting that many people misunderstand what exactly xAPI is and is not.
- xAPI is not an instructional design methodology, although it will impact the ability of instructional designers to do their jobs better.
- xAPI does not analyze or evaluate learning experiences, although it enables the creation of metrics and analytical tools that L&D has not had to date.
- xAPI does not replace the LMS, although it enables learning done on any platform to be tracked and evaluated.
In my mind, it can be explained as two things:
- it is a technical standard to enable the creation of data about learning experiences
- it enables a common language(s), a lingua franca, to talk about that data
I’ll talk about #1 in a future post. In this post, I’ll address #2 and why it’s important.
Wikipedia provides the following definition of a lingua franca:
A lingua franca (/ˌlɪŋɡwə ˈfræŋkə/), also known as a bridge language, common language, trade language or vehicular language, is a language or dialect systematically (as opposed to occasionally, or casually) used to make communication possible between people who do not share a native language or dialect, particularly when it is a third language that is distinct from both native languages.
The key to this definition as applied to xAPI is the phrase “systematically used to make communication possible between people who do not share a native language or dialect”.
A lingua franca answers some of the key questions raised by skeptics of xAPI.
“Why do we need a standard like xAPI when various vendors are addressing or can address the analytics within their own system?”
Actually, there is no need at all for a lingua franca if you are going to work with tools all created by one vendor who has applied a common methodology across all their tools. But in this BYOD (Bring Your On Device), self-directed learning reality of today’s workplace, the ability to merge data from various systems and devices is facilitated by a common set of descriptors. To begin watching a video did you “start”, “initiate”, “play”, “begin”, “hit go”? What verb tense would you use – play, played, playing? In Big Data, these things matter and can be the difference between being able to build valid analytics or not. (FYI: the xAPI video community prescribes “played” for having started watching a video. All verbs in xAPI are in past tense.).
The same consideration goes for the programming language used to express the data. If some data comes to you in HTML5, some in XML and various other languages each applied differently by each vendor, your chances of ever cleaning it up on an ongoing basis in order to do regular reporting is very slim.
An agreed upon set of vocabulary that is systematically applied enables data from multiple systems to be merged and analyzed quickly and accurately. Ultimately, if well implemented widely, xAPI will enable industry-wide learning analytics.
“Why is it necessary to purchase a Learning Records Store in order to use xAPI data?”
There are open source LRSs that can be used for free. Vendors can build LRSs as stand alone or part of their tools (ie, LMSs). LRSs are built to assure that any data that resides in the LRS is in the form of valid xAPI statements. If the preferred vocabulary for a learning experience has been used, the data extracted from an LRS for analysis will have a very high level of validity. Validity is a major issue with Big Data. The xAPI LRS addresses this issue.
Data can be exported from an LRS to any data storage or analytics tool that is being used. Although many of the commercial LRSs available have analytics tools built in “out of the box”.
“How can a standard determine a singular vocabulary for all learning experiences?”
xAPI does not prescribe a single vocabulary. This course of action was dropped at the end of 2015 because it was seen as being too restrictive. In reality, the xAPI specification does not specify vocabulary. It enables various communities of practice to establish a list of vocabulary that is appropriate for reporting data in their domains. These vocabularies are listed by ADL and the Tin Can Registry as recommended vocabulary. Users of xAPI are highly encouraged to
- use already established vocabulary whenever possible
- join or start a community of practice in creating domain specific vocabulary
- as a last resort, create their own vocabulary and share it via ADL/Tin Can Registry.
It is through this collaborative process that an appropriate, systematically applied vocabulary will be established.
The xAPI standard establishes a structure for the data and parameters for various components enabling flexibility for necessary variations from domain to domain or device to device. This balance is the power behind xAPI.
“How will xAPI enable non-Learning data to be used in our analysis?”
With a common vocabulary established, data from non-xAPI systems can be easily mapped and connecting APIs can be written. Many of the major business systems like Salesforce, Slack, and HRMS systems already have export APIs established. xAPI can match up to these systems easily to create xAPI statements from their data and store them in the LRS. Thus only one connector is needed for each external tool.
A final benefit in the xAPI standard is that it is being developed in JSON using human-readable language. Built on common linguistic structure, it is understandable to non-technical practitioners of learning and development.
Establishing a common way of speaking about learning experiences, our lingua franca, will provide benefits to individual L&D departments, the organizations we serve, the industries we are part of.