Open Source xAPI Capabilities for the Total Learning Architecture
Open Source for the TLA
Including: Learning Record Stores and xAPI Filters for TLA business logic
Our team has been working hard to get new open source capabilities out to the xAPI community
The goal is to provide open source versions of the key components necessary to implement the xAPI data flow required to support an implementation of ADL’s Total Learning Architecture. The following resources will help you to establish a system where data flow is governed by xAPI Profiles and which leverages the elaboration of the Learning Record Store concept to render “Noisy” LRSs at the edge of your learning ecosystem and “Transactional” LRSs closer to the center of the system.
You can think of a Noisy LRS as being responsible for capturing any and all of the xAPI emitted by a data source. This data source could be something traditional like an LMS or it could be something more advanced such as a VR application. So long as it emits proper xAPI data, that data will be validated and collected in the Noisy LRS. And you may have any number of Noisy LRSs… there could be one per data source or one per region in a globally distributed system. The point is that they collect whatever xAPI is thrown at them.
The Transactional LRS, on the other hand, will only be collecting specific data relevant to a business purpose. For example, a competency assertion system may need evidence of learning activities in the form of xAPI data statements. Rather than search for the needed data from among any and all of the Noisy LRSs, the competency system can be connected to a single Transactional LRS into which the required evidentiary data has already been filtered.
“But I thought I just needed one LRS…”
Well, that completely depends upon your use case. In the event you are just collecting data from your LMS in order to report completions and poll which pieces of content were engaged with most often, then yes, you probably only need one LRS. And it might even come packaged with your LMS.
But in the event you are dealing with a more complex ecosystem or more advanced business processes, it is generally more efficient to collect data on the edge and then funnel what you need to where you need it to be. Obviously, this quickly can become expensive. That’s partly why we developed SQL LRS — the free Apache 2.0 open source Learning Record Store. Because it is lightweight, containerized, and free, you can quickly deploy SQL LRS as many times as you need in order to accomplish your business objectives. Multiple instances of SQL LRS might be set up in the cloud, each touching a different type of data source or representing the data created by teams in different parts of a large organization. Instances of SQL LRS might be deployed to portable drives allowing for offline data collection in the field. In any of these cases, SQL LRS is being used as a Noisy LRS.
So, what’s a Transactional LRS?
Transactional LRSs are governed by xAPI Profiles or other filters that ensure that only certain xAPI data makes it in. So, let’s say you have implemented a competency assertion system that requires a certain type of evidence to be collected as a series of xAPI statements. And let’s say that your training environment is truly immersive — so you have events occurring in VR and AR, you are running desktop or mobile simulations, you’ve got apps where learners take quizzes, and you are managing everything through a mix of LMSs and LXPs. In a TLA scenario, you would have a ring of Noisy LRSs capturing xAPI data from all of those data sources. The data would then be forwarded through a filter. That filter would contain some sort of logic to let some data pass through to a Transactional LRS while keeping other data out. In our scenario, we are only letting data pass through that supports our competency assertion system. The Transactional LRS stores that evidentiary data.
But how do we forward and filter the data from one LRS to another?
There have been statement forwarders for as long as there have been LRSs. But they tend to be used for the purpose of duplicating the data in one LRS to another LRS. This week, we released LRSPipe — an open source forwarder with built-in filters governed by xAPI Profiles. So what does this mean? This means that you can collect data in your ring of Noisy LRSs and then use LRSPipe to forward data — data that is being filtered to your specification — to one or more Transactional LRSs. The filter itself is governed by the xAPI Profiles specification — meaning you can set it to filter by statement templates or by patterns in the xAPI Profile. Returning to our example of a system feeding data to a competency assertion system:
The learner engages in an immersive learning experience.
xAPI data from among the data sources providing that experience are sent to the ring of Noisy LRSs.
LRSPipe is configured to allow only the data necessary to make the competency assertions to pass through its filter.
The data is forwarded from the Noisy LRSs, through LRSPipe, and to the Transactional LRS.
The xAPI data in the Transactional LRS is used as evidence by the competency assertion system.
And this can be done now? It’s not science fiction?
It’s not science fiction.
Here are the resources you need to get started. They are all free and released as open source under the Apache 2.0 license. Please contact us with any questions.
SQL LRS
Project Site: sqllrs.com
GitHub Release: https://github.com/yetanalytics/lrsql/releases
Documentation: https://yetanalytics.github.io/lrsql/
Contribute: https://github.com/yetanalytics/lrsql
Docker Hub: https://hub.docker.com/r/yetanalytics/lrsql
SQL LRS CloudFormation Template (for quick enterprise deployment on AWS cloud)
CloudFormation Template: https://www.sqllrs.com/sql-lrs-cloud-formation-template
GitHub Documentation: https://github.com/yetanalytics/lrsql/blob/main/doc/aws.md
LRSPipe
Project Page: https://www.sqllrs.com/lrspipe
GitHub Release: https://github.com/yetanalytics/xapipe
Docker Hub: https://hub.docker.com/r/yetanalytics/xapipe