Learning Record Store

Draft

Introduction

A so-called Learning Record Store (LRS) (sometimes called learning records store) is a data store for xAPI messages, i.e. collected information that track a learners' progress using a system like an LMS.

According to ADL (retrieved June 2016) “The Experience API (xAPI) is an open source specification that allows you to track any experience (i.e., formal, informal, or operational). xAPI can track reading an article or interacting with an eBook, watching a training video, chatting with a mentor, physiological measures such as heart-rate data, quiz scores, and answer history by question. But where does all that data get stored? That’s where a Learning Record Store (LRS) comes in. The LRS is the endpoint or enabling system for xAPI.”

Peter Berking: Choosing an LRS

Peter Berking, Senior Instructional Designer with ADL, wrote a paper Choosing an LRS from which we extract the following definition. Please notice the BY-NC-SA Creative Commons licence, i.e. if you reproduce the following text, you must cite the original author, Peter Berking and the original link

The xAPI spec documentation defines an LRS as “A system that stores learning information. Prior to the xAPI, most LRSs were Learning Management Systems (LMSs); however this document uses the term LRS to be clear that a full LMS is not necessary to implement the xAPI. The xAPI is dependent on an LRS to function.” (ADL, 2013). It is important to understand that the LRS is a cloud-based service that only deals with learning information storage and retrieval of learning information (i.e., xAPI statements). It does not include the myriad functions of an LMS, thus is not a replacement for one. This “lightweight” aspect of an LRS is appealing to some; not including the overhead bulk of LMS functions significantly reduces cost and complexity. However, LRSs can be made interoperable with or even integrated into LMSs, and often are, in cases where the LMS remains as the system of record for training records. It remains to be seen whether LRSs will exist primarily as a capability built into other systems (like LMSs) rather than a separate system, but right now, they are being sold mostly as a separate system. As a comparison between LRSs and LMSs, the following is a list of general functions normally provided by an LMS. LRS functions are highlighted:

• Structure – centralization and organization of all learning-related functions into one system, enabling efficient access to these functions via layered interface navigation functions.
• Security – protection from unauthorized access to courses, learner records, and administrative functions.
• Registration – finding and selecting or assigning courses, curricula, etc. by learners and their supervisors. This may include instructor-led training classes.
• Delivery – on-demand delivery of learning content and experiences to learners.
• Interaction – learner interaction with the content and communication between learners, instructors, course administrators, as well as between communicative content and the LMS (i.e. SCORM content).
• Assessment – administering assessments and the collection, tracking, and storing of assessment data, with further actions taken (possibly in other systems) based on the results of assessment. Many LMSs include the ability to create assessments as well.
• Tracking – tracking of learner data including progress on a predefined set of training goals and requirements, and tracking of courses for usage, especially in relation to required deployment of mandated training (for example, compliance training).
• Reporting – extraction and presentation of information by administrators and stakeholders about learners and courses, including the information that is tracked as described above.
• Record keeping – storage and maintenance of data about learners. This includes both demographical info profiling learners and their training progress and accomplishments. This is especially critical when an LMS is deployed as the official “system of record” for an organization.
• Facilitating Reuse – searching and recombining courses and possibly parts of courses for delivery in different curricula and learning tracks (this is a much more prominent feature of LCMSs, but can be included in an LMS).
• Personalization – configuration of LMS functions, interfaces, and features by learners and administrators to match personal preferences, organizational needs, etc.
• Integration – exchange of data with external systems to facilitate enterprise-wide tracking of learner performance and transfer of user data and to exploit external content and learning resources (i.e. content management systems).
• Administration – centralized management all of the functions in this list.

Note: Some LRSs include a Reporting function that presents xAPI data that is recorded in the LRS; however, it is not part of the core spec, and is thus not highlighted above, although it is strongly implied as an auxiliary function.