Linkages to other badges

Over the last few weeks I have been diving into other badge systems to figure out a way to consolidate badges from other existing (non-obi compliant) systems into the Mozilla Open Badges Backpack. This has really forced me to think about the metadata that makes up the Open Badge. Some of the other badge systems I have looked at include;

• khan academy - https://github.com/Khan/khan-api
• codeacademy - http://www.codecademy.com
• foursquare - https://developer.foursquare.com/
• stackoverflow - https://api.stackexchange.com/
• codewall - http://coderwall.com/api

What I find interesting is that it is not immediately clear how all these badge systems will map to the current OBI specification for a badge. And until we have a standard metadata specification for the badge, we don't really have an "open" badge. I have great faith that the open community, Mozilla and the open badges team will work toward an open metadata standard for all (or should that be ALL) badges. I also believe that their work at implementing webmaker badges will improve the current open badge metadata standard greatly.

WebMaker Badges show a system design where badges are linked, clustered and the detail of a cumulative badge.

IMHO, a number of attributes regarding a badge need to be added or brought into the discussion about badges. Fortunately, I am not the first to think about this. A page within the open badge github was put in place six months ago to foster such a discussion (it remains empty, but it is there). Three of the attributes I can see originating from the new webmaker "ecosystem" of badges are what I will name; linked, clustered and the detail of a cumulative badge. A little further below in this post is how I see these three, and a couple of my additions, need to be considered within the metadata of the badge. But first, I think it important to consider who is assigning this relationship.

Who creates a badges relationships?
I believe two different people (or groups) create the badge relationships; the issuer and the earner.

• The issuer creates a badge and its metadata detailing the badges criteria, origin, contact, etc. The issuer also knows how the badge exists in relationship to other badges. Does the badge stand alone as representing a skill or knowledge all on its own? or does the badge exist with other badges to be a part of a curriculum, learning objectives, a learning journey or a cluster of skills and knowledge?
• The earner, who has little control over a badges metadata, will also create relationships between badges. Is the earner creating their own learning journey or clustering badges to represent a unique set of skills and knowledge. I believe one of the strengths of badges is how the earner is given greater control of their learning by allowing them to create a personalized curriculum.The earner needs to be able to organize their own badges. Fortunately this can be done in the Mozilla badges backpack.

This distinction is important when considering the required additions to the badge metadata specification. Once a badge is issued its attributes cannot be altered for (given current thinking) this would invalidate the badge. I agree with this assertion. What this means is that if an earner wants to set relationships among their earned badges this needs to be done in the earners badge backpack and not alter the metadata of the badge itself. I believe the issuer has many reasons to set the relationships within the metadata of the badge, as the issuer understands how the badges fits within learning and related learning. Look to the above webmaker badges for an example of this.

Badge relationships:
Currently I see four different kinds of badge relationships. All of these apply to the issuer where only a subset apply to the earner. Please do not confuse a badge with curriculum or assessment, they represent mastery of a skill or knowledge.

Some possible additional json attributes

1. journey (or linked) - a set of badges that represent a learning journey. They are related through subject matter or knowledge domain. Badges are issued and some build upon each other, others are gates (you need this badge or set of badges to move on to earning other badges). They may be the previous or next badge in a learning journey.
2. clustered (or grouped) - badges can be clustered to represent a domain of knowledge or the complete mastery of a skill.
3. master-detail - a set of badges may be sub-badges to a master badge. The idea being someone needs to collect a set of badges to be awarded the overall competency badge. (the webmaker badges seem this way). This badge relationship differs from clustered in there is no higher level badge or overall competency badge with the clustered relationship.
4. dynamic - some badges change or are updated through time. This is very apparent with engagement type badges (see stackoverflow) where the more someone contributes the greater a badge is given value for the specific earner.

Next steps?
I believe the Mozilla badge needs to incorporate these (or similar) additional attributes into the badges metadata specification. Not all may be required as a part of the specification as having them baked into the badge may not be the best place for them. But I believe these relationships need to be considered in the design of the badge, its metadata, the role of the backpack and its features, and what features should be part of the displayer.

To assist with this endeavour I will continue in mapping existing non-OBI compliant badge systems to determine the gap between emerging badge systems and what the current Mozilla Open Badge can support. I will continue my journey toward building a badge consolidation system with an alpha release at some unannounced date in the future (I've got a family to support so paid work will be my priority, duhhh).