Summary
- Define how user activity data will be tracked, so that they can be used for Learning Analytics
- Specify how event tracking requirements will be set in the context of a Learning Analytics Task/Module
- Model user activity data for Learning Analytics on the SlideWiki platform level
- Translate and store user activity data in Learning Record Store (LRS)
Background and goals
The SlideWiki project aims to provide various modules where analysis of user activities data can be performed.
User activity data will be stored in a Learning Record Store using the xAPI (Tincan API) form of representation.
The SlideWiki platform should be able to send any data relating to activities performed by registered users to the LRS. This should be implemented in such a way as to decouple the event triggering with the event handling, i.e. events will be collected and handled in separate process.
The activities service shall provide the facilities for that, as it is already the central hub through which all user activities are processed thus far. It must be relatively easy and straightforward to prepare the event data using a custom model via the platform (or any other service), and send it to the activities service. The activities service will then have proper handlers for each activity type that will transform it to a properly defined xAPI event and forward it to the SlideWiki LRS directly. Alternatively, the xAPI service could receive the activity data and the transformation and forwarding would be performed there.
The user activity data stored in the LRS will in turn be available to the various analytics modules we aim to provide, namely:
- User Profiling & Skills Recognition
- Content Recommendation
- Advanced Analytics
- Interactive Visual Analytics
In this requirements document we aim to define the data collection module, by which we mean:
- the LRS instance that we are going to be using as the SlideWiki user activity data store
- the facilities in activities service through which it will be possible to define user activity data, the collection of which a learning analytics module shall require
- the SlideWiki platform methods/components via which data collection will be performed for the specific activity data type
Assumptions
- For the usage and learning activities data we are are going to use existing and well defined model for representation, which is the xAPI (or Tincan API)
- For the collection of such data we are going to deploy and maintain an instance of Learning Locker, a Learning Record Store (LRS)
The SlideWiki LRS content will potentially include data external to SlideWiki, e.g. from a Learning Management System (LMS)
User activity data will be collected via the activities-service of the project and forwarded to the LRS
Requirements
| # | Title | User Story | Importance | Notes | JIRA |
|---|---|---|---|---|---|
| 1 | Setup Learning Locker | Setup and maintain an instance of Learning Locker | Must have | SWIK-977 - Getting issue details... STATUS | |
| 2 | Update activity model | The platform or a service should be able to send arbitrary user activity data to the service. The model right now requires a well-defined activity type and activity data. Ideally we need to provided a model for general use so that modules could request event tracking without updating the activity service source code. | Must have | SWIK-1145 - Getting issue details... STATUS | |
| 3 | Implement Pub/Sub model for activity handling | The collecting and handling of activity data should be decoupled. A well-known and versatile pattern is the publisher / subscriber model. The activity service will server as the event message broker between publishers (the platform mainly were the events originate) and subscribers (the xAPI-service for LRS integration, or a service that might be developed for a Learning Analytics module). | SWIK-1146 - Getting issue details... STATUS | ||
| 4 | Provide event transformation and forwarding to LRS via the xAPI service | The xAPI service should provide new routes via which events will be received by the activity service, transformed to xAPI format and stored in the Learning Locker LRS. Event data received will be expected to be modeled according to the more general model defined in (2). | This is about providing facilities in the form of helper methods so that Learning Analytics developers can easily add event handling code for a new event type. | SWIK-1147 - Getting issue details... STATUS | |
| 5 | Add a simple module for facilitating custom event tracking in the platform | The updated activity model in (2) will make it easy for platform developers to add event tracking code for any event a Learning Analytics may require. We would like to make it even easier by providing a platform module / library that can receive a minimal set of arguments, and enhance with data from the current user session context before forwarding an event to the activities service. | SWIK-1148 - Getting issue details... STATUS |
Questions
Below is a list of questions to be addressed as a result of this requirements document:
| Question | Asked by | Outcome |
|---|---|---|
Not Doing
| Feature | Status |
|---|---|
Source material for user/stakeholder feedback
Evaluation at UniBonn :
Project Partners feedback: