Experience API (xAPI) Standard

Overview
xAPI History
Associated Projects
xAPI Technical Details
LRS Conformance
LRS Endpoints
xAPI Profiles
Security and Privacy
Resources
Videos
Citation

xAPI is a data and interface standard that lets software applications capture and share (big) data on human performance, along with associated context information (i.e., “experience” data). Combined with learning analytics, xAPI promises to revolutionize the way education and training are conducted, managed, and measured. xAPI can be incorporated into nearly any (new or existing) learning technology, and it is agnostic about the type of learning content being delivered. xAPI is open-source and licensed under Apache License, Version 2.0.

Overview

“xAPI” stands for Experience Application Programming Interface. The ‘x’ stands for experience, because xAPI enables detailed recording and transfer of “learning experience” data, whether those data come from an e-learning experience, a simulation-based training experience, a tablet-based educational experience, or even an operational (on-the-job) experience.

In software, an Application Programming Interface (API) allows two or more applications to exchange data with (or “talk to”) one another. In the context of education and training technologies, APIs can be used to share data about learners and learning activities. Hence, xAPI is a particular standard designed to enable the interoperable exchange of data about learners’ behaviors and performance. In other words, it encodes someone’s performance using a standard format, and it follows standardized transportation rules to move those data to a data store or between applications.

xAPI can be implemented in any digital environment, including mobile learning, simulations, virtual worlds, serious games, real-world activities, mobile and wearable devices, experiential learning, and more. It can be used to track and store data on any imaginable activity, such as:

Reading an article or interacting with an eBook
Watching a training video, stopping and starting it
Training progress data from a simulation
Performance in a mobile app
Chatting with a mentor
Physiological measures, such as heart-rate data
Micro-interactions with e-learning content
Team performance in a multi-player serious game
Quiz scores and answer history by question
Real-world performance in an operational context

The xAPI standard also includes guidelines for xAPI’s use (e.g., “xAPI Profiles”) as well as nested specifications for xAPI-formatted data storage, authentication, and access (i.e., Learning Record Stores).

xAPI History

In 2008, the Learning-Education-Training Systems Interoperability (LETSI) Federation was formed to investigate the next generation of SCORM requirements. LETSI produced over 100 white papers that would later become essential artifacts and sources of requirements for xAPI.

In 2010, the ADL Initiative began investigating new standardized experience tracking capabilities that could support emerging devices and technologies used for e-learning. It was envisioned that the learning data generated from xAPI should provide more than course completions, test scores, or the number of pages viewed by a learner. It should provide all types of learning activity data that can be analyzed and correlated to productivity and performance metrics.

In 2011, the ADL Initiative issued a contract to Rustici Software to develop a proposed baseline technology approach. This effort, called Project Tin Can, resulted in the first designs for xAPI. An ADL Initiative working group was then formed to mature the concept, resulting in the first formal release of xAPI version 1.0 in 2013.

As of late 2020, the xAPI specification was being formally standardized by the Institute of Electrical and Electronics Engineers (IEEE), a leading international standards organization for information technology, via the IEEE xAPI Working Group P9274.1.1. Establishing xAPI as a formal technical standard helps promote its acceptance and use worldwide.

xAPI has seen growing acceptance throughout the e-learning community, including its inclusion in DoDI 1322.26, and numerous adopters using xAPI in their products and services. The first IEEE release of the xAPI standard will be version 2.0. This version includes improvements such as language clarifications, better defined “actor” and “activity” relationships, standardized time stamps, and a best-practices guide.

Associated Projects

The following ADL Initiative projects are focused on xAPI:

xAPI Technical Details

xAPI uses the JSON data format and RESTful web-service APIs (i.e., HTTP methods for GET, PUT, POST, DELETE).

Interoperability

xAPI is designed for interoperability. It first addresses structural interoperability (i.e., the ability of two or more applications to exchange information). It does this by enforcing a consistent data structure in the form of statement objects. This kind of structural interoperability enables the integration of learning experience data from diverse sources—from any application or platform.

Next, xAPI provides interoperability by standardizing the API transfer methods used when communicating information about learning experiences between applications that comply with the specification. As part of this compliance, xAPI standardizes the format of requests and the expected responses. This standardization includes the use of Learning Record Stores (LRSs) which are discussed in more detail below.

Finally, xAPI enables semantic interoperability through the use of xAPI Profiles and shared vocabularies. This ensures that different systems can not only exchange the data (i.e., the “1s and 0s”) but also have shared interpretations of the data’s meaning.

Statement Object Model

xAPI statements are the structured data about a learning experience. An xAPI statement includes data about the actor (e.g., learner), verb (e.g., watched, passed), and object (e.g., video, quiz) as well as contextual information such as the timestamp and issuing authority, and also optional information such as results, other informational attachments, and context details.

Learning Record Stores

A Learning Record Store is a server (i.e., system capable of receiving and processing web requests) responsible for receiving, storing, and providing access to xAPI learning records.

The xAPI standard also defines requirements for the storage and retrieval of xAPI statements. All xAPI statements are validated and stored by an LRS. These data stores may be part of an LMS or other software package, or they can be standalone applications.

More precisely, an LRS is the implementation of the server-side requirements associated with xAPI. LRSs are responsible for storing, accessing, and often visualizing the data about learning experiences, activities, and performance. LRSs also validate the format of the statements, ensuring that only conformant statements are accepted and retained.

xAPI uses a distributed implementation architecture. In other words, rather than use a single LRS for all data, xAPI is best implemented with many distributed LRSs that can communicate with each other. Each LRS can be public, private, or a combination of the two (i.e., private but sharing limited data with public).

LRS Conformance

Because an xAPI LRS validates each xAPI statement it receives, LRSs are the linchpin of a functional xAPI implementation. Organizations seeking to build or buy an LRS should procure one that meets xAPI conformance standards, i.e., that has demonstrated it adherence to the xAPI standard via a Conformance Test Suite. The ADL Initiative hosts a publicly available LRS Conformance Test Suite designed for use by DoD organizations and their vendors.

DoD and other Federal Government organizations are encouraged to use the following statement in their acquisition documents (e.g., statements of work, performance work statements, or other applicable program requirements documentation):

The contractor shall ensure the learning record store (LRS) is conformant to the Experience API (xAPI) Specification Version 2.0.

The following documents will be cited in the request for proposal (RFP) package (keyed to the appropriate section) for LRS: Experience API LRS Testing Requirements.

Acceptance will be based on the following:

Conformance: An error-free repeatable test log output for the LRS, providing evidence that the Experience API Version 1.0.3 LRS-Conformant conformance label has been achieved.

LRS Endpoints

An LRS Endpoint (alternatively called a sub-API or xAPI Resource) is simply a URL within the LRS that listens for HTTP requests. The xAPI LRS specification implements six endpoints:

The Statement Endpoint is used for all xAPI statements. Example URL composition: https://myLRS/xAPI/statements
The About Resource Endpoint returns metadata about the LRS (e.g., the xAPI version or LRS configuration details). Example URL composition: http://myLRS/xAPI/about
The Activities Endpoint returns metadata about a particular, unique activity. “Unique activities” may be, for example, different online courses, and their metadata might include their titles, descriptions, and usage instructions. This endpoint only returns data, and it can only be accessed with the GET command. Example URL composition: http://myLRS/xAPI/activities
The Agents Endpoint returns metadata about a particular agent. An “agent” may be a learner or class cohort, for example. This endpoint only returns data, and it can only be accessed with the GET command. Example URL composition: https://myLRS/xAPI/agents
Three endpoints fall under the “Document Endpoints” category; these endpoints all involve user-defined key-value pairs, which are typically unique to a given system. The Document Endpoints are primarily used by (local) Learning Activity Providers. The data stored in these endpoints represent the current situation at a given time, and those data can be updated (replacing old data) if/when the current situation changes.
- The Agent Profile Endpoint allows the storage and return of universal data about a particular user (e.g., that learner’s preferred language, accessibility preferences such as closed captioning). Example URL composition: https://myLRS/xAPI/agents/profile
- The Activity Profile allows the storage and return of universal data about a particular activity (e.g., minimum required score, time limit, what happens if the time limit is exceeded). Example URL composition: https://myLRS/xAPI/activities/profile
- The State Endpoint allows the storage and return of data about the current state of an activity for a particular learner (e.g., bookmark, state of play of the simulation, other state variables). In other words, the State Endpoint stores data about an activity/agent combination. Example URL composition: https://myLRS/xAPI/activities/state

xAPI Profiles

An xAPI Profile is a specific set of rules and documentation for implementing xAPI in a particular context. Profiles generally provide a particular vocabulary of terms and variable formats. xAPI Profiles help create semantic interoperability.

xAPI’s flexible and extensible data model makes it easy for Learning Record Providers to encode many different types of learning experiences. However, this flexibility makes it difficult for Learning Record Consumers to make sense out of the data. xAPI Profiles are the set of vocabulary terms and usage rules for a particular domain (e.g., a subject matter, like emergency medicine; or delivery format, like videos). Using these vocabularies and rules, developers can create interoperable statements. A common vocabulary is needed, so that both Providers and Consumers can understand the data represented in an xAPI statement.

Security and Privacy

xAPI includes various controls designed to support information assurance. For example, xAPI includes instructions and best practices for authorization, authentication, scoping data, anonymizing data, encryption, and implementation architectures to address information assurance concerns. However, security and privacy remain ongoing research topics.

Each organization controls its own implementation of xAPI, including its security and privacy. LRSs are responsible for storing data at rest and the associated security. That means each LRS (and the data it contains) can be as secure (or as un-secure) as desired. From an external perspective, only LRS endpoints are visible to the outside world. Behind those endpoints, LRS implementers are free to use any architecture, technology, or security controls desired.

For more information on xAPI security, go to https://github.com/xapisec

Resources

Open Source Software from ADL Initiative

xAPI Profiles

Adding xAPI to SCORM-based e-Learning Courseware

Videos

ADL xAPI bootcamp 11:58 – July 2015

What is cmi5? from the Systems Engineer Perspective 03:50 – April 2015

What is cmi5? from the SCORM Developer Perspective 01:57 – April 2015

Citation

Johnson, A. (SETA Contractor), Werkentin, A. and Hernandez, M. (SETA Contractor) (2020) Understanding and Applying cmi5 in an xAPI Solution. In Volume 2020 (Eds.), Proceedings of the 2020 Virtual Interservice/Industry Training, Simulation, and Education Conference (vIITSEC). Arlington, VA: National Training and Simulation Association.