At the beginning of this month, the Badge Alliance published version 1.1 of the Open Badges specification. This is a technical reference for developers. However, it has exciting, far-reaching pedagogical and social possibilities that are worth highlighting. In this post, I want to explore just a couple of these: mapping and endorsement.
The Open Badges specification has always included a standard set of metadata fields that organisations use to issue badges. These include things like:
- Name: what the badge is called
- Description: what the badge is for
- Criteria: what individuals have to do to earn the badge
- Evidence: the work the individual did to earn the badge
This is great, but what happens when an organisation wants to add information over and above what’s included as standard? This is where Extensions come in:
“The 1.1 version of the Open Badges Specification introduces Extensions as a means for issuers to add additional metadata to Badge Objects beyond what the standard specifies itself. Additional properties are allowed without using Extensions, but Extensions allow issuers to declare how they are adding information so that it can be understood by others and other issuers can add the same sort of information in a compatible way.”
Let’s bring this to life with an example. Imagine a citywide initiative for credentialing digital skills. Perhaps it’s something like the Cities of Learning initiative with a diverse range of providers. Organisations involved might be interested in using an extension that includes where the individual carried out the activities that led to the badge being issued. Along with the name of the place, this would be even more powerful if the latitude/longitude/elevation was also included. Consider a field trip: along with the evidence captured (images/videos/audio), this would be a very rich picture of an individual’s achievement.
Previously, geographic data could have been arbitrarily added to the badge evidence page by the issuer. However, as a community-approved Extension, it becomes something that is processed, understood, and exchanged in the wider badging ecosystem. It’s adding to the standard in a way that benefits everybody.
For more on this, check out the JSON-LD website.
There are several different ways in which the term “endorsement” is used in various sectors. Here, it’s being used as a way for a third-party (individual or organisation) to lend their support to a badge. This is most likely to be in terms of brand recognition:
- a teacher-issued badge is endorsed by their institution
- a “maker” badge is endorsed by a brand (or “celebrity”) in the field
- a badge is endorsed by industry lead bodies (in a similar way to “kitemarks”)
There are many other ways this could work. At the moment, endorsement is indicated through the visual design of the badge and any arbitrary information added to existing metadata fields.
Excitingly, through the new Extensions functionality, those inspecting the issued badge could be certain the badge has been endorsed by the person or organisation referenced. This might happen through an equivalent to the Issuer field:
Instead of “Issuer,” it would mention “Endorser.” The URL would point to a specific mention on the endorser’s website of the particular badge being endorsed. Not only would the badge come with the backing of the original issuing organisation, but the additional weight provided by the endorsing organisation or individual.
More about endorsement can be found in this presentation by Nate Otto.
This has been a slightly technical explanation of a new innovation that could have a lot of social and pedagogical benefits. The documentation around the Open Badges specification and JSON-LD is excellent, meaning that even with my limited technical skills, I managed to propose an extension. It’s worth knowing what’s possible, even if you’re solely focused on learning design.
If you’re interested in any of it specifically, or Open Badges more generally, why not get involved in the community?
Banner image credit: Bryan Mathers