Understanding the Purpose and Evolution of xAPI and Learning Record Stores

Understanding the Purpose and Evolution of xAPI and Learning Record Stores

Introduction

In conversations with colleagues, customers and prospective customers, the topic of xAPI and Learning Record Stores (LRS) comes up periodically. With over 20 years of experience working with the people at the Advanced Distributed Learning Initiative (ADL), I do have some insights. It is important to understand that ADL is a Federal Government entity. It is a component of the Department of Defense (DoD), reporting to the Defense Human Resources Activity (DHRA). At their core, ADL performs R&D and publishes information technology standards associated with training for the Federal Government. Initially, ADL’s entire focus was development of interoperability standards for eLearning courseware and Learning Management Systems (LMSs). In our industry they are most recognized for the development of the Sharable Content Object Reference Model (SCORM). The SCORM standard quickly eclipsed other standards to become the primary eLearning content interoperability and packaging method used not only by the DoD, but also by the entire training industry. Today, all major learning and education management systems support SCORM. Like with any standard, SCORM had its critics and contributors. Over time it has evolved to become the only truly universal training and education technology standard.

The xAPI and LRS standards are extensions of the SCORM standard with specific goals and attempting to solve specific issues. Both have their origins in the DoD community with input from industry. Learn more about ADL at www.adlnet.gov.

The History of xAPI

No alt text provided for this image

The xAPI (Experience Application Programming Interface) formerly known as “Tin-Can”, originated in 2008 as a response to a collection of concepts developed by the Learning Education Training Systems Interoperability (LETSI) federation (a non-profit group that was focused on learning content interoperability and evolution). Tin-Can was commissioned as a project by the DoD via ADL.

Tin-Can was envisioned as an expanded learning content interoperability standard. Its initial goal was to solve issues associated with the use of learning content developed using non-standard and legacy eLearning standards (i.e. AICC) without having to re-architect hundreds of SCORM conformant learning delivery and management platforms. Tin-Can also focused on resolving emerging issues associated with the Cross-Origin Resource Sharing (CORS) standard.

No alt text provided for this image

CORS was introduced into World Wide Web Consortium (W3C) browser specifications in 2005 and became a significant issue for cross-domain learning content interoperability by 2007. The CORS standard introduced security restrictions for sharing information across different domains and platforms. It also introduced secure methods for sharing information, content and security session data elements (AJAX, Web-Messaging, etc.). Learning content library providers needed a solution to the new CORS security measures in order to support their clients. The only other option would be for clients to load packaged libraries of courses onto their Learning Management System (LMS) and update these packages as required. This was untenable for a number of reasons, including content maintenance, copyright protection and security. CORS workarounds became a central issue in the development of Tin-Can to support the needs of the learning content library providers that had already adopted SCORM.

No alt text provided for this image

Instead of waiting for the new “Tin-Can” standard to be developed and adopted by LMS and education management solution providers, the major learning content providers implemented their own solutions by introducing AJAX and Web-Messaging capabilities into their SCORM Content Aggregation Packages. These new IEEE, W3C and HTML5 specifications caused Tin-Can to become a solution in search of a problem. As a result, adoption of the Tin-Can standard outside of the DoD was poor.

Introducing xAPI Learning Record Stores (LRS)

The investment in development of the Tin-Can standard was not insignificant. Looking back at the recommendations of the now defunct LETSI federation (see letsi.org), ADL decided to move forward with a variant of Tin-Can with new branding; The Experience API (xAPI).

No alt text provided for this image

This new approach introduced the concept of a Learning Record Store (LRS) as an extension to the Tin-Can/xAPI protocols. The LRS standard created a whole new form of learning management that attempts to track and integrate disparate learning experiences and then see that data alongside all of the other data that an organization’s LMS or education management system collects. It also introduced the concept that learning happens everywhere, not just in the LMS. The “experience” element of xAPI promotes that content and experience from a variety of sources should be aggregated to present a more complete record of the learner. The LRS standard also included methods for integration of badging technologies to support credentialing and certification management.

Current Status

Since its’ debut in 2017, the adoption of the xAPI and LRS standards has suffered from the same low adoption rates as their Tin-Can predecessor. Creating a LRS can be done cost effectively by Federal Government agencies that can control access to learning content and personnel records. The privacy policies and security concerns of corporations, associations and higher education institutions contrast significantly with the controls available to the Federal Government. These factors tend to severely limit the amount of Personal Identifiable Information (PII), including individual performance data, than can be housed and communicated to third-parties in these settings.

There are noteworthy content source sites, like LinkedIn Learning (formerly Lynda.com) that support elements of the LRS standard. Unfortunately, even banner sites like LinkedIn are unable to warehouse the aggregate learning experience of their users because most corporations, government entities and member associations do not disclose personnel training records to third-parties.

Many associations do have exemptions that allow for the final results of a learner or test-taker to be communicated to the organization that is paying the fee for the credential, license or certification. Many associations also allow the individual to grant access to elements of their achievements to third-parties, like LinkedIn. Most member associations and credentialing organizations already provide badging and verification APIs to subscribing organizations without the need to spin-up a LRS. Access to these APIs normally requires the consent of the learner.

Most State and Federal certification and licensing bodies do not electronically share licensing and certification achievements with employers or third-party LRS sites even with the permission of the individual achieving the recognition. Most government agencies operate with APIs that enable employers and other agencies to verify the authenticity of certification or license information on a go/no-go basis, without a LRS.

For most corporations, “experience” elements are currently managed in conjunction with their talent and performance management programs. These “experience” elements tend to be focused on internal and external programs that meet organizational needs and personnel development requirements. Most eLearning content providers use AJAX or Web-messaging in conjunction with SCORM to support their corporate clients. External classroom and virtual classroom learning providers generally supply their clients with results via standard APIs integrated with the client LMS. It may be short-sighted, but many corporations find “self-claimed” activities and experiences of little value to their employee development programs.

No alt text provided for this image

Educational institutions have implemented a number of LRS repositories. Unfortunately, the privacy issues discussed above have been an impediment to their potential. Most institutions do not allow their alumni to record “experiences” achieved outside of the institution in their LRS implementation. While there are exceptions, educational institutions have generally steered clear of the liability and expense associated with maintaining a comprehensive alumni LRS.

No alt text provided for this image

Combined, these issues present a situation where even though most major LMS providers can support the xAPI standard, there are very few LRS installations for these systems to communicate with. It should also be noted than any large repository of PII and learner accomplishment information could easily become the target for hackers requiring comprehensive security protocols and constant oversight.

Summary

No alt text provided for this image

ADL and their supporting contractors should be applauded for their vision and efforts in herding inputs from a wide range of organizations into the xAPI and LRS standards. For the DoD and other Federal Government agencies, the benefits of centralized LRS implementations has been measurable. As a customer, the Federal Government is somewhat unique in its ability to control the security, content and access to the resulting LRS sites. While government agencies can mandate the implementation of these standards as it applies to their programs, the issues of PII, security, expense and cost-benefit have been significant barriers to wider industry adoption.

No alt text provided for this image

Outside of the DoD and the U.S. Federal Government, the xAPI and LRS standards have experienced low industry adoption rates. While these standards have only been in existence for five years, it is hard to predict if there is light at the end of the tunnel as it relates to corporate, association and higher education implementation. The concepts presented by the LRS standard are laudable, but the barriers to industry-wide acceptance appear equally ominous.

Over 20 years ago, enterprising technologists introduced protocols and standards for the exchange of patient health care and insurance information. The advantages of these health care exchange standards were obvious. Equally obvious was the risk associated with maintaining these patient records in a portable electronic format. These risks generated the requirement for the Health Insurance Portability and Accountability Act of 1996 (HIPAA). Without governing regulation, like HIPAA, and significant cost-benefit to the sponsoring organization, the realization of the LRS vision beyond the DoD and other Federal Government agencies may be difficult to attain. 

About This Newsletter

Tips, Tools and Techniques provides research, new methods and collaborative events for developers, managers and instructors. Topics are selected based on market trends, industry events and subscriber recommendations. Subscribers can also participate in our monthly online events and share their success stories. Click here to subscribe.

About KMSI

KMSI has been providing learning and talent management technologies for over 20 years. If our technologies meet your requirements we would love to work with your organization. With KMx Enterprise and KMxASP there are no "per-user" fees; both provide for unlimited users. With all of our offerings there are no maintenance fees and no upgrade fees. KMSI will match or beat the price offered by any competitor that provides a similarly capable solution. Visit www.kmsi.com to learn more.

No alt text provided for this image

To view or add a comment, sign in

More articles by Jack Lee

Insights from the community

Others also viewed

Explore topics