Over the past week or so we have started looking at the Mozilla Open Badge platform and how it could, possibly, be applied to use within HEIs (and beyond). It started to become apparent, through reading other peoples blog posts and reading through mailing lists, that there is already some work going on to award badges for completion of modules of study or achieving particular learning outcomes. After looking at what information is required to award a badge using the Open Badge framework, I created a design for a platform that can be picked up and used within another institution or context with minimal customisation required. The purpose of this blog post is to document the decision processes involved and to describe and show the resulting design.

The Basics

The basic premise of the system is fairly simple: create badges and award them to individuals who meet the criteria for each badge. These awarded badges can be ‘baked’ (to include the relevant information) and sent to individual’s ‘backpacks’ – be that the OpenBadge backpack or an internally hosted version.

This suggests that data pertaining to the following is required: Badges, Objectives and Earned Badges.

Adding A Few Extras

If the objectives required for badges are to be at least based on outcomes of programmes of study (be that at a full degree award level, or one constituent module within a degree), then it may be necessary, or at least preferred, to categorise the objectives within the badging system, or to add types of objectives to the system. Programme outcomes, if taken from our own programme specification documents can be split into at least three different types: Knowledge and understanding; Subject-specific skills and attributes; Transferrable skills and attributes. However, this categorisation of objectives may not hold true for other HEIs that may wish to use this code, and almost certainly would not be applicable if the code was used outside of the education sector. So objective types also have to be stored within the system.

When considering (still within a HE context) how the badging system might be expanded beyond learning outcomes of programmes or modules, you begin to open up the potential of including other data sources into the mix, such as library data, participation with extra curricular activities etc. For this reason, I’ve also included a badge source to the data, so that badges can be awarded from different sources and be differentiated as such through the data and its presentation to users. Again, another group of data to be stored: the source of a badge.

Designing the System

Data Requirements

Firstly, a list of the data required within the system:

• Objectives for badges
• Badges
• Badges earned
• Source of badges
• Types of objectives

Doing the whole relational database thing on the data results in a structure something like:

• Objectives
• Objective Types
• Badges
• Badge-Objective Links
• Badge Sources
• Completed Objectives
• Awarded Badges

A quick Entity Relationship Diagram (including suggested links to possible external data sources) would look something like this:

Obviously this data structure and suggested ERD is subject to change as I go through the development and prototyping stage.

With a data structure in place, mapping out the flows within the system and designing and implementing the APIs to do the data input and output are the next two steps in the process!

Data & Process Flows

There are several obvious functions that must exist within the system to allow the awarding of open badges to individuals. These functions include:

1. Storing badge information
2. Storing objective information
3. Storing objective types
4. Linking badges and objectives
5. Storing various sources of badges
6. Tracking objective completion for users
7. Checking badge completion
8. Storing completed badges for users
9. Creating assertions for completed badges
10. Presenting badges to a user through email
11. Sending badges to a user’s backpack

In order to make the system compatible with existing data sources outside the bounds of the system shown above, the following API functions will need to be externally accessible:

1. Add badges to the system
2. Add a new badge source
3. Add objectives to the system
4. Add objective types to the system
5. Uploading a badge image to the server
6. Mark objectives as completed
7. Search for existing objectives
8. View completed badges for a user
9. View completed objectives for a user
10. View existing badges
11. View existing objectives

A quick data flow (ish) diagram shows how the data may flow internally within the system and the data that may be required from external sources, for one of the main series of functions – marking an objectives as being completed, through to awarding the badge to a user.

 What Next?

Firstly, I need to put together a prototype of a system that resembles the one described above. The code will be available on GitHub and licensed appropriately for reuse. Then we need to decide how we *may* go about prototyping the use of the system and any further development that is required. There is no agreement to go beyond the research and prototyping of badges at Lincoln yet and the most likely use case is for awarding badges for extra-curricula achievements, such as participation in workshops and those identified by the Higher Education Achievement Report (HEAR).