This project in an attempt to extend the [Open Educational API] (https://www.openonderwijsapi.nl/) (Open Onderwijs API) with learning analytics based on [xAPI statements] (https://github.com/adlnet/xAPI-Spec/blob/master/xAPI.md). It contains a locally running Learning Record Store, tooling to generate sample learning analytics data and API documentation which can be tested with actual requests.
The open educational API endpoints used for learning analytics are documented with Swagger UI. Swagger dynamically generates a site for live testing and exploring the API.
- node
- npm
- npm install -g swagger
- swagger project start
Although not necessary you can modify API definitions in a convenient way:
- swagger project edit
This opens a browser allowing live editing of API definitions.
OpenLRS is a secure, standards-based, standalone Learning Record Store. OpenLRS was built to fill the need for a high i/o storage mechanism for an open learning analytics environment.
- http://apereo-learning-analytics-initiative.github.io/OpenLRS (project page)
- OpenLRS (github repo)
- JDK 7+
- Maven 3+
- mvn clean package spring-boot:run
This starts OpenLRS on port 8080 using an in-memory datastore. The LRS is accessible at [http://127.0.0.1:8080] (http://127.0.0.1:8080) but has no gui. Note the in-memory database lacks some functionality, filtering doesn't work for instance. Please refer to the OpenLRS documentation to switch to permanent storage.
Apache JMeter is designed to load test functional behavior and measure performance. In this project it is used to provision our learning record store (locally running openLRS instance) to be able to query it via the Open Educational API.
- JDK 7+
Download Apache JMeter, extract the archive and run:
- cd bin
- ./jmeter.sh
In the GUI click the 'Open' icon. In the dialog navigate to the directory you extracted this project in. From here navigate to subdirectory 'api/resources/data', select file 'lrs.jmx' and click 'Open'. Now the script for provisioning our openLRS instance is loaded. Press the 'start' icon at the top of the screen to start provisioning. Now generated xAPI statements are loaded into our LRS. Collapse the 'Statements' section and select 'Summary Report' to get an overview of the run. On the same level 'View Results Tree' shows individual requests and responses - xAPI statements - to populate the LRS.
Credits go to Alan Berg for his work on LRS load testing scrips. Note the generated statements consist of combinations of verbs, actors, objects/activities and do not necessary make sense.
Now that we have our locally running LRS filled with sample data, we can start (if not already running) our open educational api:
- node app.js
The open educational API acts as a facade in front of the LRS. We can access it via the Swagger UI interface at http://127.0.0.1:10010/docs/ and fire requests.
In general responses from the evolving open educational API contain a 'meta' and a 'data' part in their body. If we would apply this pattern and wrap responses from a LRS it would break the xAPI specification. We should question ourselves if this is desirable.
Endpoints '/verbs' and '/recipes' do not exist in the xAPI specification. However it can be useful to get an overview of verbs and recipes used at an institution to get some sort of consistency in the statements which are defined and generated. "Define and document the verbs you use in your statements. This documentation is the beginning of a controlled vocabulary that will help to ensure your organization uses verbs and statements consistently in future xAPI projects. If your organization has been working with xAPI for a while, make sure you follow the verb usage standards established in previous projects." Source.
Timestamps used are in '2016-01-19T14:06:12Z' format (ISO 8601 UTC/Zulu).
In this PoC setup the open educational api proxies requests to the LRS backend and uses basic auth to connect to it. The open eductionel API uses oauth for authorization. Personalized queries ('my' statements) are possible by identifying the user based on the token being used, and query the LRS with agent filtering. For example: https://lrs/xAPI/statements?agent={"objectType": "Agent", "name": "Darlene Snyder", "mbox": "mailto:[email protected]"}
Apart from exposing learning activities from a Learning Record Store, it could be wise to opt for a Learning Record Warehouse. Such a data warehouse could analyse the learning record store based on predictive models and can provide convenience methods for students and staff. Endpoints such as '/studyprogress', '/risk' or '/intervention' could expose data about learning activities on a meta level.
The focus in this exploration has been on the open educational API as a gateway in front of backend systems such as a LRS. But the open educational API and the endusers interacting with it could also be treated as learning activities. The open educational API could internally generate xAPI statements and fire them when a student retrieves his/her schedule or marks by calling open educational api endpoints for instance.
The xAPI specification is already defined in swagger it seems. The xAPI-swagger repo hosts a yaml file which can be loaded into Swagger UI so you can explore it. Here is the visualization of xAPI specification.
Recipes define xAPI statements. A recipe is a standard way of expressing a particular type of experience. It provides a common language and prevents the use of different words saying the same thing. Recipes allow different systems to talk about things people do using the same words. Sharing of definitions is important. The article 'Dutch cooking with xAPI recipes and the flavour of various Learning Record Stores' (by A.Berg, H. Drachser, M. Scheffel, S. Ternier, M. Specht) provides an overview of standard recipes used by various institutions.
- https://goo.gl/TOC9wA (a registry of the complete statements in JSON format)
- https://goo.gl/uHhwSH (a spreadsheet with the most important information needed for each statement)