Open Badges vs Tin Can

Two interesting initiatives are working on solutions aimed at making the learning process and its outcomes more visible and more exploitable. One is Open badges: it is lead by The Mozilla Foundation with the objective to facilitate the informal recognition of informal learning. The other is Tin Can: it is the offspring of the SCORM community and is aiming at providing a flexible framework to record learning events and outcomes.

One way to elicit the difference between the two approaches is to explore the type of statements that can be expressed in each world:

  • Tin Can: “I did this”
  • Open Badges: “She can do this”

As one might infer from these statements, Tin Can is more learner centric (she is the one generating the statement) while Open Badges is more organisation-centric (most badges, so far, are issued by organisations). Such inference would probably raise the hair of many members of the Open Badges community who see themselves as the champions of individual empowerment. Yet, the fact is that most Open Badges are issued to the learner, for the learner, not by the learner.

It is true that issuing a Badge to oneself does not make much sense. yet, issuing a statement such as “I can do this” is worth recording as it could be used at a later stage to deliver a badge. In a sense, one could say that a Tin Can statement is like a badge (to record data) without a badge (to display).

When looking in detail at the data structures of the two specifications, one can see the following differences:

  • Tin Can statement: actor, action verb, object
  • Open Badge assertion: issuer, owner, criteria, evidence

What was missing in the initial Tin Can specification was the link to evidence. It is now corrected with the option to add attachments to a Tin Can statement. On the other hand, Tin Can does not seem to provide a field to capture the relationship between the issuer and the owner which is what contributes to making Open Badges a native trust network.

Open Badges, Tin Can and ePortfolios

Another way to approach the differences/complements between Open Badges and Tin Can is to explore how each specification could contribute to the building of an ePortfolio. Let us imagine that an eportfolio narrative contains a number of statements such as “I did this”, “I did that”, etc. When writing a narrative with an eportfolio today, you use a word processor for which statements are just a sequence of meaningless characters —sometimes connected to external elements through an hypertext link.

Now, imagine that to compose a narrative, the eportfolio author has access to the complete database of statements contained in a Tin Can Learning Record Store (LRS). The narrative would not be a mere sequence of character strings, but a composition of granular statements generated during the learning/working process. We would have de facto a semantic editor (4th of the 10 eportfolio challenges published by EIfEL in 2009).

Open Badges, Tin Can: towards one specification?

While Open Badges is well suited to recognise learning, in its current implementation (the need for a badge issuer, a badge displayer and a backpack) it is not suited to track the elementary components and activities related to learning. While Tin Can is well suited to track the elementary components of a learning process, it does not seem well suited to authenticate the claims related to the recognition of competencies: for that, you need to elicit the relationship between the issuer and owner of the claim, something that Open Badges does well.

Could we imagine that a single specification would be able to cover different levels of granularity and authentication? Yes. In Fact, Open Badges has all the structures needed to support a mechanism similar to Tin Can.

But in order to do so, the first thing would be to think out of the Badge frame, and imagine how the Open Badges infrastructure could be used for other things than displaying badges.

In the context of Open Badges, a Tin Can statement is like a Badge, without a Badge, or more precisely, a set of metadata that is stored in the backpack but not displayable as a badge.

On the other hand, having a series of Tin Can statements in the Backpack could be exploited to deliver a badge or to construct the narrative of an eportfolio, eportfolio that could be used to obtain a badge…

Conclusion (temporary)

The Open Badge Infrastructure seems to have all the features required to implement the equivalent of Tin Can. In order to make it happen, the Open Badges community will need to dissociate the records stored in the Backpack from their representations as a Badge. This will be discussed in a following article.

7 thoughts on “Open Badges vs Tin Can

  1. Hi,

    Thank you for such a well written comparison between Tin Can and Open badges. This article helped me re-direct my thinking about the two.

    But I would give Tin Can a thumbs up in the anticipation of more insight about the learner in comparison with an open badge.


    • Serge says:

      TinCan should be used for more granular data, while Open Badges for less granular ones, that could be inferred from the aggregation of a series of TinCan statements. it is unfortunate that Open Badges are used in lieu of TinCan statements, for small granular pieces of information. It is why we should treat them both as ‘assertions’, one with pretty pictures (Open Badges), the other without (xAPI/TinCan statements).

    • Serge says:

      Yes, a blockchain would be an elegant solution. The question now is: do we need one blockchain per LMS or per person. We are currently working on the idea of a personal ledger, so my initial exploring path would be to have xAPI data recorded in the personal ledger. From a LMS point of view, it should be valuable access to other data beyond xAPI statements and conversely. The discussion has already started: Badgechain

  2. Charles Boisvert says:

    My (very pragmatic) temptation would be to use tin can to record fine-grained events, but some of the events would be
    effectively exploiting both methods for what they are good at.
    Are there limits to doing that?

    • Serge says:

      I agree that xAPI statements is probably better for recording fine-grained events. On the other hand, having them “verifiable” individually or collectively) as in “verifiable claims” might be an interesting feature to create a chain of verifiable events.

Leave a Reply

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.