Prezi Notes:

Many of these notes will link to broader discussions of the ideas and information indicated in the Prezi. I acknowledge up from that I will violate modern standards of web design by putting too much information on a given page as well as not making the pages mobile friendly - my apologies.

Slide 1:

Title Slide

Slide 2:

Acknowledgements

Slide 3:

Don't worry....all the material for this presentation is available at this website.

Slide 4:

...the web material for this presentation goes deeper and wider so relax!

Slide 5:

Open Badge global structure: A very quick overview of the primary roles in open badges. The Issuer who awards the badge, the Earner who is awarded the badge which is a visual marker that contains all the embedded information about the skills asserted, and the Displayer to who the badge is presented and wishes to understand what the badge represents. It is probably helpful to think of a badge as a form of portable credential or transcript of skills that lives with the Earner and not with the Issuer.

Slide 6:

Big Picture for presentation: The model for this presentation is that to understand a tool it helps to build one from scratch to understand it's strengths and weaknesses. Much like building a chair or a guitar - it helps you understand the potential and what you can expect from others who build them for you. Badges are where the web was back in the mid 90's. This presentation is intended to show you the nuts and bolts so you can build a badge for yourself. 45 min for talk but I have built this to only be 30 min long so there is plenty of time for discussion and questions. Please ask.

Slide 7:

Big Picture: This graphic illustrates the variety of objects that need to exist in order to award a badge. These all represent bits of data associated with the badge that need to flow smoothly between various people involved in the process. Each of these objects is a JSON object (.json file) which we will talk about momentarily. The BadgeClass and Issuer objects (files) are needed to set the stage much like creating a school and a curriculum with outcomes. The alignment object is embedded in the BadgeClass object. The Assertion object is the actual tool for awarding a badge to an individual. A separate Assertion object is created for each person who is awarded a badge. The Assertion contains within it the tools to identify the recipient and to verify that they have earned the badge.

Slide 8:

Open Badge Specification 1.1: For folks who are building badge tools and applications for us to use this is the articulation of the technical standard for open badges. One of the challenges currently occuring is that while open badges are designed to be transportable between systems many badges/badging systems are not compatible with the open standard. In many ways this defeats a principle value of open badges.

Slide 9:

JSON Objects: These data objects certainly seem simple but it has been surprising to me how difficult it is to generate a very simple file of this format. In the end I found it very helpful to purchase an app to support the creation of .json files. I have tried a variety of other tools including web tools with very limited success. Here are some links to support your exploration of this data interchange format.

Slide 10:

BadgeClass Objects: The BadgeClass object is essentially an articulation of your 'course' design. It describes what the skills or outcomes are that this badge is intended to validate. Unlike a short paragraph in a catalog one can create very extensive documentation for a badge. We'll walk through the individual elements of the .json file which are also described in the link above.

Slide 11:

@context defines the version of the badge spec that these objects are written to match. Just like different versions of Word files or web documents. This leads every json object to tell the application where to get the information to interpret the file.

Slide 12:

"criteria" -- this is one of the potentially valuable features of a badge that allows a much richer sharing of the skills and competencies asserted by the badge. Instead of a simple catalog entry this can be as rich and deep (or not) as the issuer wishes to spend the energy to describe. It offers the additional opportunity to present and discuss the assessment tools and strategies that affirm the skills being asserted or validated by the badge.

Slide 13:

"alignment" {} -- this is also a valuable feature of the badge in that it explicitly articulates any other skills and compentencies that this badge is aligned with. These could be a range of industry standards or community discussions that are relevant to the context of the badge. These are often a part of learning experiences that we construct for our students but the opportunity to connect them with specific courses or experiences is harder to share in our traditional catalog environment.

Slide 14:

Issuer Objects: The Issuer object creates a digital trail to the person or organization issuing the badge. A core feature of the open badge standard is the ability for any entity to create and award badges. Consider the possibility that the machine shop down the road took the time to create these objects and award badges for particular skills and training. How would you receive and understand the value of such a badge? Why is networking and personal referral such an important pathway to career transitions in our modern world? This are questions of trust and trust networks which are what badges are meant to be markers for. Again, we'll walk through the individual elements of the .json file which are also described in the link above.

Slide 15:

Issuer "url" -- because badges create the opportunity for a broader range of badge issuers than merely traditional educational institutions the need/opportunity to explicitly articulate the 'skills lineage' of the issuer is critical. Even for a traditional institution it may merit some clear articulation of the provenance of the issuers right to assert these skills or competencies. How does one argue that trust in your statements is warranted?

Slide 16:

"email" -- I find it instructive to consider that I am putting my personal/professional name on the line by providing my contact information to anyone to whom this badge is presented. It is interesting and alarming how much that makes me consider my action in validating this student compared to giving them an institutional grade in my class. I have, perhaps mistakenly, a much greater sense of personal exposure.

Slide 17:

"revocationList" -- This is another fascinating possibility offered by badges -- I can revoke a badge at anypoint in the future and it takes immediate effect. When a badge is presented to someone as an assertion of skills that specific holder of the badge is checked against the revocation list before it is validated -- more on this in a moment. This one tool to cope with concerns about badge validity.

Slide 18:

Assertion Objects: Now it is time to actually give someone a badge. The assertion object is what does this. The assertion object is the data which actually embedded (baked) into the badge and it contains a range of data relevant to the specific earner. The assertion object represents a particular occurance of the badgeclass. All assertions of this badgeclass will presumably validate the same skill sets or outcomes. The assertion object contains various tools to help verify the badge and support the trust network central to all credentialing systems.

Slide 19:

"uid" -- every actual badge that I issue has a serial number. This serial number is a unique to the person to whom I award the badge that represents the skills documented in the criteria link. At some level this makes the badge trackable.

Slide 20:

"verify" -- embedded in the badge that an earner might present to a potential employer is a link to the file which validates that badge. For the time being I have been doing this by hosting on a webpage the assertion object which documents the issuing of the specific badge (uid) to the student. This information must exactly match the information embedded in the badge for the badge to be deemed valid. IF this assertion object is deleted or otherwise lost the badge has lost it's validity or traceability and is deemed invalid though it is really more of a zombie badge.

Slide 21:

"evidence" -- who hasn't wished to see specific work done by a student in support of the skills they are said to have. This link creates the opportunity to provide that particular student specific information to those who are confronted with the badge. There are important issues of privacy and data management associated which have engendered much discussion within the badge community. Still, it seems like a valuable addition to any tool seeking to validate a particular skill set.

Slide 22:

Validating the Assertion: Because these are all digital objects they are subject to the usual challenges of computer code in that they are rigidly sensitive to tiny errors. To address this the open badge folks have built a web based tool to check the assertion object you have created. Simple copy and paste your assertion object (.json) into the window, say a few prayers, and see what you get back. In this process all of the badge objects are validated including the Assertion, BadgeClass, and Issuer objects, along with your criteria, revocation, images, and organizational web pages. There's a lot riding on this and I have spent a lot of time with the validator....

Slide 23:

What you hope for......

Slide 24:

What happens a lot......sometimes pretty hard to make sense of the feedback.

Slide 25:

Baking the Badge: Baking is the process of embedding the metadata of the assertion object into the data stream of the badge image. Think about our modern cameras and the date, time, and GPS locations that we embed in our images without thinking about it. Same process exactly for baking the metadata into the image for the badge. When the process is completed (mere moments) you have portable image that contains the affirmation of the skills of a particular recipient.

Slide 26:

Unbaking the Badge: Suppose you want to unpack a badge that someone presents to you? Unbaking (same website) is the process that accomplishes this. The badge doesn't look any different when it's unbaked but all the information and documentation that you have created on the way to awarding this badge is available to the person you have shared your badge with. A bit overwhelming but powerful stuff.....

Slide 27:

Open Badge Passport: Here's what an unpacked badge looks like in an application environment. Some, but not all, of the information that is baked in the badge is present in this presentation and it is much more accessible. Not all badge display apps present the same information and there is the question of what happens if the application becomes defunct for some reason --- remember that the baked image of the badge contains all the information regardless of whether it is displayed in some convenient application. Also note that the passport and the baked badge image are carried by the learner and the learner decides when and how to share them....a very different model.

Slide 28:

Big Picture Again: Questions?