Taxonomy for Open Badges May Be Easier Than You Think

We’ve kicked off the Taxonomy Working Group for Open Badges with some great discussions. It’s a challenging topic that’s been bubbling in the Open Badges community for some time. The power of using the specification to connect digital credentials is generally agreed upon but how to do it well raises valid concerns and questions.

Some of the bigger questions have to do with the complexity and scope of Open Badges. How will we create a universal taxonomy that is manageable? How can a taxonomy address the many uses of Open Badges? If we have separate taxonomies, how is that any better than the tags we use now?

Open Badges is a technical specification for storing and delivering digital credentials. The early adopters have primarily been in the education space (a tremendously multi-faceted space in itself that includes K-12, after school, online learning, higher ed, etc.. ) but also in workforce training, workforce development, volunteer coordination, conferences, political movements… The ecosystem is expansive with varied objectives. It’s arguable that Open Badges will never have a single universal taxonomy sufficient enough to support the entire ecosystem. It needs a taxonomy system to make the connections within and throughout this ecosystem but it’d be an enormously difficult undertaking to try to define a single set of terms to serve the needs of all.

Instead, it’s suggested that Open Badges adopts a system of extensions accommodating many taxonomies, starting with already existing classifications systems. Although it sounds complicated, it’s actually much simpler than you’d think. Why is this better than tags? How can we make connections through many taxonomies if issuers aren’t using the same base terms?

Tags are a free-for all. Some issuers use them, many don’t. There is no reference for what tags to use, to know what each tag means or who is using which one(s) for what. Without a point of reference, logical connections can’t be made or at least not made well. Tags are also restricted to the badge class. There are no properties to tag assertions or issuers.

Taxonomies are classifications with meaning and with the proper implementation of extensions in Open Badges, JSON-LD makes it possible for each term to have human and machine readable links that reference the definition and source. This allows for many extensions to co-exist, for issuers to decide what they want to adopt and for the consuming applications to be able to distinguish the meanings and differences for each term. Also, with extensions, taxonomies can be applied to any aspect of a badge: badge class, assertion and issuer.

Here’s an example of what a taxonomy extension may look like. This example isn’t flushed out at all and we’re not quite ready to get into the best technical implementation but what it illustrates is how the linking works and how that provides capability to the issuing and consuming applications.

/* Implementation in a badge class */

{
"taxonomyExtensions:casraiEducationHistoryTaxonomy": {
"@context":"http://url-to-extension-context.json",
"type": ["Extension", "taxonomyExtensions:casraiEducationHistoryTaxonomy"],
"ids": [1,3]
}
}

/* Example of context */

{
"@context": {
"obi": "https://w3id.org/openbadges#",
"taxonomyExtensions": "http://url-human-readable-webpage-about-the-taxonomy.html",
"termIds": "http://url-human-readable-webpage-about-the-term-termIds.html",
},
"obi:validation": [
{
"obi:validatesType": "taxonomyExtensions",
"obi:validationSchema": "http://url-to-extension-schema.json"
}
]
}


/* Example of Schema */
{
"$schema": "http://json-schema.org/draft-04/schema#",
"title": "Taxonomy Extension",
"description": "An extension that allows you to add any taxonomy to your Open Badges",
"type": "stringArray",
"properties": {
"termIds": {
"type": "string"
}
},
"required": ["ids"]
}

In the /*Implementation in a badge class*/ what you see is a reference to @context which links to a JSON file that defines the extension and provides the human readable website that provides the definitions for each term. The context also links to the validation schema. Below the implementation you can see examples of the context as well as the schema.

By using extensions, issuers and the consumer applications have a common understanding of what the terms mean. Even if an issuer uses many of these extensions or many issuers use many different extensions, the consumer application understands them.

If issuers are using different taxonomies, how does that help make the connections we seek? Consumer apps make those connections. Since they are aware of the extensions, they can process them in a way that makes sense for their apps’ purposes. They make the connections. Also, keep in mind that we have a vast ecosystem that is in its early stages. Some taxonomies will be more “popular” than others. Some issuers will collaborate with other issuers to make their own specific connections. There will be experimentation. It will improve over time.

But we need to start somewhere. Our roles now are to set up the infrastructure to make room for this experimentation.

Taxonomy Working Group meetings are held every other Thursday from noon-1pm ET. The next one is 10/8. Here’s the etherpad with connection info: http://etherpad.badgealliance.org/taxonomy-wg-10-8-2105

Principal at OpenWorks Group, Tech Strategist, Writer, Researcher, Social Justice Technology Advocate, PhD Student in Media Psychology.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store