Learning Record Store

A Learning Record Store (LRS) is a data store system that serves as a repository for learning records collected from connected systems where learning activities are conducted. It is an essential component in the process flow for using the Experience API (xAPI) standard by ADL or the Caliper standard by IMS Global. The Experience API is also known as the "Tin Can API" and is an Open Source e-learning specification developed after AICC and SCORM. The concept of the LRS was introduced to the e-learning industry in 2011, and proposes a shift to the way e-learning specifications function.

History

SCORM has been the e-learning industry software specification for interoperability from 2001 until the present. The governing body of SCORM, Advanced Distributed Learning (ADL), realized that the specification was not keeping up with advancements in technology, and that it needed to be updated. ADL issued a Broad Agency Announcement (BAA) asking for assistance with updating the SCORM specification. The BAA was awarded to Rustici Software, and the result was a one-year research and development project called Project Tin Can. The final result of Project Tin Can was the Experience API along with the concept of the LRS.

Overview

xAPI-enabled learning activities generate statements, or records of e-learning in the form of "I did this" or "Actor verb object". These statements are transmitted over HTTP or HTTPS to an LRS. The main function of an LRS is to store and retrieve the data that's generated from Experience API statements.

An LRS can exist inside a traditional learning management system (LMS), or on its own. LRSs can communicate learner data with other systems, such as LMSs, sensor-enabled devices, mobile technology, and other LRSs. Systems sending data to an LRS are known as "Activity Providers." Individual learners can have their own LRSs, or Personal Data Lockers, in which they store all of their learning data for their own personal records.

xAPI statements are capable of being sent to multiple LRSs at once. With traditional LMSs, a learner's data stays with the organization that administers the LMS. When the LRS is introduced, the sharing of learning data is possible, and the learning data can follow the learner wherever the learner goes (for example, from job to job or from school to school.)

LRSs offer the ability to create very in-depth e-learning analytics because of the large amounts of learning data they record and store. Traditional e-learning specifications like SCORM are limited to storing simple data points such as a final score, or that a course has been started or completed. With the statement structure that the LRS records, there are many data points that can be reported against. Reports can be pulled on any number of combinations of "actor", "verb" and "object". However, an LRS that is built strictly to the Experience API specification doesn't have a built-in reporting mechanism. The LRS administrator (or the administrator of the LMS in which the LRS exists) must provide means to access the data in the LRS, and in turn create a reporting system for the data.

There are some points that vendors often omit about the LRS. The argument is it is beneficial because learners have data records that secure everything. However, learners bring their records along upon leaving the school or company and insert this data into the Learning Management System (LMS) assuming it contains an LRS. In education, the records of students’ learning can shift from primary to secondary education. Some vendors changed this approach by deleting the record of an individual who leaves regardless of the reason.

An example of an LRS for Caliper is the Callisto Project published by OpenEd.