The Google Plus logo

Three solutions for integrating Tin Can and Open Badges

Lead Learning Designer Andrew Downes is our resident Tin Can expert. He’s one of the authors of the Tin Can API specification and provides Epic with the latest thinking on the new learning standard.

Tin Can and Open Badges are among the hottest topics in learning technologies right now. I’ve written quite a lot about Tin Can over the past few months, and recently I’ve been thinking about Open Badges and how these two standards might work together.

Launched at about the same time as Tin Can, the Open Badges project is strikingly similar to Tin Can, and it too has been gaining momentum. Both projects aim to record and report on any learning anywhere. Both do this by defining learning activities and reporting them to a central database via an API. For both Tin Can and Open Badges, reporting tools get this data out again via API. Tin Can calls this central database an LRS; the Open Badges equivalent is a Backpack.

Of course there are some crucial differences. Read below to learn more.

Tin Can and the learning journey

Tin Can was developed from within the world of e-learning. It’s aimed at people moving away from a SCORM-powered LMS and designed to tackle the problems of businesses and other organisations, whilst at the same time bringing significant benefits to the individual learner. Tin Can is used to track any learning and achievement down to a very granular level. Using Tin Can, you can paint a picture of the learner’s journey up to an achievement.

Open Badges and learner achievements

Open Badges, on the other hand, has come from Mozilla, the organisation most well known for creating and developing the Firefox web browser. Open Badges aims to provide a way for people to demonstrate achievements outside of formal qualifications from schools, colleges and universities. As you’d expect, Open Badges has a focus on graphical badges that represent the learner’s achievements. This narrower focus on significant ‘achievements’ allows Open Badges to recognise accomplishments and skills really well, but it doesn’t provide the broader picture of overall learning and analytics that you can get with Tin Can. (Learn more about Open Badges in our introductory blog post).

Open Badges and Tin Can were developed independently and were not designed to work together. But I’ve been thinking… could we somehow combine the two specifications so that we use Open Badges to recognise achievement and use Tin Can to tell the story around that achievement and provide analytics? The answer is yes. Yes, we can.

Three ways to incorporate Open Badges into a Tin Can LRS

1. In this first option, the Tin Can LRS acts as an Open Badges Backpack but uses Tin Can, rather than Open Badges APIs. We (as your learning technologies partner) would define a Tin Can profile for Open Badges – a set of vocabulary that will let Tin Can talk about Open badges in a standard way (see my ‘Watch out for flying cars’ blog post for more details on Tin Can vocabulary). Note that only those Tin Can statements that are specifically crafted to award Open Badges will do so; for example, Johnny earned Compliance Training Superstar badge. The system will not generate a badge for every single statement… and this is the way we want it. Badges are only awarded for achievements of significance, otherwise they become meaningless.

This solution has the advantage of piggybacking on the work of Open Badges with the least effort. It brings all the benefits of Open Badges into Tin Can. What it doesn’t do is allow the LRS to communicate with existing Open Badge systems. A website that displays Open Badges via the Open Badges API will not be able to display badges stored in our Tin Can LRS unless the website also implements Tin Can and the Open Badges profile we have defined.

2. In this next option, the LRS also implements the Open Badges Displayer, Verification and Endorsement APIs. This means that websites and apps that display badges can choose between the Tin Can and Open Badges APIs when getting data out of the LRS. Data about badges will still be input and stored into the LRS via Tin Can statements, but the LRS will translate this Tin Can data to meet the Open Badges standard when responding to requests from Open Badges powered tools.

3. In this third option, the LRS also implements the Open Badges Issuer API. This will mean that Open Badges tools will be able to send badge awards into our Tin Can LRS. Data about badges awarded to learners will be stored in our LRS and can be output as Tin Can statements. This approach provides interoperability between Tin Can LRS and Open Badges Issuers. Combining options two and three will allow any Open Badges tool to integrate with Tin Can systems without actually having to adopt Tin Can.

Find out more about Tin Can and Open Badges

This article is based on one I originally posted at tincanapi.co.uk back in April. Since then, myself and others in the Tin Can working group have been discussing these ideas with the Open Badges team at Mozilla. We’re starting to think about ways in which the two standards can slot together more formally in future. Epic will keep you posted as things develop!

Additional resources:

To find out how Epic can help with Tin Can or Open Badges, please get in touch. Or leave us a comment below. 

This post was written by Andrew Downes and first appeared on the Epic blog on 1st August 2013.