BadgeClass:

This is one of three required .json objects that define a badge. The BadgecClass is the object which articulates the meaning of a particular badge. In a more traditional educational setting someone (maybe you) would articulate the outcomes and skills that you (the issuer) assert that the recipient of this badge has demonstrated. This object allows you to share both the outcomes or skills that the badge represents along with specific assessment strategies or tools that you are using to validate those skills. You are also able to document within the BadgeClass object any alignments that your badge shares with other standards (industry or otherwise) that are relevant to the skills represented by the badge.

Consider, in our current transcript based system, how we determine the meaning of student success in a particular course at a school that is not our own. We look up the course number and read the miniscule course description from the catalog for starters. Rarely is this a satisfying experience. If we are persistent we may be able to find a web page that describes in greater detail what skills are developed in a particular class but in this age of LMS like Blackboard richer details are typically out of the public view. If we are fortunate the course description connects it to some national standard or accrediting body though we are often dubious depending about the particulars of the national standard and how it is implemented at the school in question.

In designing the learning experience for which you are awarding a badge imagine that you can lay out, in as much detail as you choose, what is contained in your learning experience. What activities you have constructed, what assessment and evaluation strategies you are using, and how all of that aligns with local, national, or global standards in your field of expertise. All of that rich context is immediately available (assuming network access and interest on the part of the viewer) to anyone presented with the badge you have awarded. This is one of the features that many find compelling about badges.

Dissecting a BadgeClass Object:

I would certainly recommend opening the link above to see the formal statement to go with any discussion here. Discussion of the creation of .json files generally is linked here.

"@context":

Like all tools, software or otherwise, there are shared standards for what is expected. In the ecosystem of badge objects the standard that you are using at time that you issue a badge needs to be specified and this is the statement that specifically articulates that. Currently the various generations of badges are forward and backward compatible when using the Open Badge spec but there are outstanding questions about badges and badge objects that are created in the many different badge issuing platforms. This compatibility question is referred to as the 'interoperability question".

"id":

This is the url where the json file (shown above) will be hosted. When you issue a badge it, the badge, will also contain this information which will provide any viewer of the badge with relevant information about the skills etc that are represented by the badge. If this .json file is moved or deleted any badges of this kind that you have issued will be adrift in the universe and are sometimes referred to as zombie badges.

"type":

This string indentifies which of the required badge objects this .json file represents. This is an example of a BadgeClass object (uppercase required I think but I haven't checked). The other object types are Assertion and Issuer objects.

"name":

At last you get to name your badge. I'm not aware of any limitations on the length of names but it would seem prudent to be restrained. If you complete the processes to create your own badge from scratch I will award you this badge and this is the name that will be displayed.

"description":

Think of this as the equivalent to the catalog description of a course. Short, sweet, and to the point. Unlike a course catalog you will shortly have the opportunity to provide as much information as you want to any viewer of the badge.

"image":

Badge images do not have a formal specification (which is a little surprising) but tracking various current discussions there are a couple of expectations that should be met. Preferred image files are .png or svg. The image aspect should be square and the folks who created the standard seem to working at around 300 px by 300 px. There is also a need to keep the image file size below 256k which is pretty compact. The question of image design is actually a very rich and deep one that warrants some attention once you settle down to seriously issue badges. Doug Belshaw offers a thoughtful introduction to the issues here and David Leaser has addressed many of the badge design issues in his presentation of the IBM in house badging system described in this slide deck. CSU has done a nice job thinking this through for their Digital Badge Program.

"criteria":

This is what initial hooked me on open badges. This url links the badge viewer to a description of the criteria that you develop for awarding this badge. This can be as rich and meaningful as you want to spend time articulating. At a minimum it will articulate the skills that you claim the holder of the badge has demonstrated to you. It can certainly include descriptions of assessment strategies you use and samples of badgeable work. This document applies to all recipients of this BadgeClass. You will have a separate opportunity to share the work, a form of electronic portfolio if you will, of a specific recipient in the Assertion object.

"alignment": (not required)

This option is an opportunity to articulate any alignment this badge has with other criteria whether they are industry standards or other learning organizations. Badges for machinist skills might plausibly be aligned with NIMS standards without necessarily being identical. In this case I can point the badge viewer at the Open Badge Spec to bolster the relevance of this badge to the overall open badge ecosytem. It is certainly true that one might include any such alignments in the criteria link for the badge but this provides an additional tool for displaying those alignments on the surface.

"tags": (not required)

In the world of big data and search optimization it is relevant to make the metadata for a badge more accessible to search engines and thereby the rest of the world. All the usual considerations for search optimization are relevant here and aligns with the JSON-LD data standard.