merit, online, image, digital, and open badges

I read a tweet the other day about badges and it got me thinking about all the different types of badges and the names being used for badges. I wanted to capture what I understand to be four different kinds of badges;

• traditional badges - these include merit badges (scouting), awards like ribbons, martial arts belts, and other patches, buttons, and displayed insignia, etc...
• online (or image) badges -These are logos or images that infer participation or membership and are displayed on blogs and websites. These provide links back to the origin site, and, in general, don't provide an acknowledgement of achievement. More used for an affiliation.
• digital badges - achievement and recognition type badges that are digital and awarded by online communities, learning/educational sites, and social networking sites. (Khan Academy, Four Square, P2Pu, and WebMaker are a few).
• open badges - A badge infrastructure to support all of the above badge types with the addition of embedding meta-data into the badge image file. The ability to embed meta-data adds the ability for a badge to be self-describing and link back to why the badge was awarded.

In the end I hope all types of badges support an open meta-data standard describing the badge. This includes the traditional badges. I'd hope any badge earned over the course of a life could be displayed as a part of a persons online profile [wherever a person chooses their profile to be (facebook, linkedin, blog, wiki, etc)].

Badge Clustering

As my digital badges seminar series came to an end I was doing a lot of thinking about badge clustering and what I meant by the term. With a little creative thinking, and some fun, I borrowed and edited three clustering terms and applied them to badges.

Badge Cluster

noun, epistemology:
A bunch of badges (ranging in number from a few to hundreds) which are bound to each other by their mutual knowledge domain as defined by the badge earner.

Open Cluster
noun, epistemology.
a comparatively young, irregularly shaped group of badges, often numbering up to ten to one hundred, and held together by and active learning journey; usually found associated with people who are gaining new knowledge where new ideas are forming on a regular basis. As the open cluster grows domain mastery increases.

Globular Cluster
noun, epistemology.
a comparatively older, spherically symmetrical, compact group of up to a few hundred badges, held together by a shared knowledge domain, that are located in the earners digital badge repository. Globular clusters are often stable with few new badges being added. In general, they show a mastery of a subject domain.

What is a Badge Cluster?
Badge clustering happens as a badge earner groups their badges into knowledge clusters as defined by themselves (the badge earner). This provides an approach for people to deepen their learning through grouping knowledge in ways that make the most sense to them. It also provides visual queues or information organization to identify gaps or holes in their self-directed study. Badge clusters can be compared to personal curriculum maps to identify the gaps in their learning.

Mozilla digital backpack as a badge repository.

Why badge clustering will be important?
As learners gather more badges into their digital badge repositories they will organize the badges into groups for a variety of purposes. The groupings will be for;

• display purposes
• setting public and private display
• identifying personal knowledge domains
• achievement towards a learning goal
• inspiring others toward similar (yet personalized) learning journeys
• organizing badges into micro and macro badges

With the correct number of badge endorsements, badge assertions, verified badge criteria, confirmed evidence, and the ability to analyze a cluster of badges against a known knowledge domain we could get to a persons completed learning efforts being assessed towards the mastery of an identified knowledge domain. I dream!

An Introduction to Badge Systems Design

I believe there are two ways to explore badge systems design;

1. what already exists in badging (and related) systems
2. what innovations could be for awarding badges

Existing badge systems fall into two areas;
1. traditional badge systems
There are a number of proven badge systems. People often refer back to scouting as a solid and proven badge system. The martial arts belts also have much to offer.

• scouting (and similar organizations)

• martial arts (Taekwondo, Karate, Judo, Juijitsu, Etc.)
• university degree, diplomas, etc. (I know, many would not consider this a traditional badge system. For the sake of design, consider the course (with grades and completion) a badge and a collection of courses (degree or diploma) and patch or super-badge.

2. digital badge systems
There are also a number of existing badge systems and these exist in a number of different contexts. A thorough evaluation and a compare and contrast to these different digital badge systems can offer some interesting insights into what is possible with digital badge systems design.

• Khan Academy - http://www.khanacademy.org/badges  
• FourSquare - http://www.4squarebadges.com/foursquare-badge-list/ 
• Stackoverflow - http://stackoverflow.com/badges 
• OERu - http://ask.oeruniversity.org/badges/
• Wikipedia Barnstars - http://en.wikipedia.org/wiki/Wikipedia:Barnstars

Innovations for badge systems design

I believe this falls into two main areas, and where much investigation, innovation and research remains to be done with the emerging badge paradigm. Ah, the journey of a thousand steps...

1. badge systems

• digital badges for the self-directed and life-long learners
• digital badges for peer learning and communities of practice

Badge Clusters

2. meta-badge systems

The systems that form between and among badging systems that allow a person to create their own credential map (or badge clusters) of their accomplishments. Essentially allowing them to create their own credential(s) of proven mastery of their chosen area(s) of expertise. Mapping their own Personal Curriculum!

implementing a really simple badge system

I aspired to create a really simple badge system design so a beginner could implement open badges. I had the following restraints to this implementation;

1. creating the badge images needed to be really simple, and saved as .png files.
2. the badge system design was to be a basic hierarchy where three micro-badges lead to a badge.
3. the tasks to earn each badge were to be simple.
4. the badges needed to be hosted and issued from one of the free services currentlly available.
5. the badges had to easily move over to the Mozilla digital backpack for organization and display.

Scenario: the badge to be earned was by making a cup of tea. I know, not a rigorous amount of learning, but I was wanting to keep it simple. To make a cup of tea you need to prove the following three basic skills; boiling water, finding a teabag, and add the boiling water and teabag to a teapot.

Step 1: decide on the hierarchy of badges and their design
I chose to follow my thoughts on the martial arts for coloring my badges. Making hot drinks can become increasingly complicated and I want to be able to add more complicated tea making badges later. I want to become a tea ninja! The next level up could be to make filtered coffee or tea from dried leaves...
Step 2: create the badge images.
These images needed to be quickly created and contain a simple design. I chose visio to create the badges cause it allowed for transparent background, supported the png and svg file types, was *gak* windows based, and had a few basic shapes. There is no reason why you couldn't use windows paint to create a basic square with a couple of words in it as your badge. just remember to save as a png file.
Step 3: use a simple badge issuing site
I wanted to use a simple badge issuing site that integrated well with the Mozilla Open Badges backpack. I ended up using http://badg.us. This site allowed me to easily add badges and issue them. Once the badges were issued they could also be easily claimed via links in the issuing email.
Step 4: move the badges into the mozilla backpack
Once the earner had claimed their badges from within badg.us they could easily move them into their mozilla backpack by selecting the badge within badg.us click the "Add this badge to your Mozilla Badge Backpack" button.

image attribution
tea bag - http://thenounproject.com/kenset/#
kettle - http://thenounproject.com/Simon%20Child/#
teacup - http://thenounproject.com/CrocodileJock/#

Confessions of a badge addict

I'm fully into moderating a two week seminar series on digital badges. The seminar has far exceeded my expectations, the dialogue is outstanding and the participants are more than I could have dreamed of. 

When I was responding to one of the discussion threads I realized I am a badge addict. I have badges from more sources than anyone I have met during my last eight months of exploring and discussing digital badges.

In my youth I earned badges from at least five different sources. As show here I have badges from; Scouting, YMCA leaders and swimming, Red Cross, Canadian Particip-Action, and Canadian Yachting Association. I always knew what the criteria was and planned out my earning of the badge(s). And I don't recall ever just being given a badge. I looked forward to the events when I received my badges. I think I now know why I am so commited to furthering the idea of digital badges... and most of my efforts are in a volunteer capacity... this is all good!

I also spent time in organizing my badges, at first they remained sewn onto the scout sash or another appropriately wearable piece of clothing. I wore them with pride. When i was in my teens (I was into stitching) I moved all my badges onto a single piece of fabric and displayed it on my wall. I organized them by issuing organization. Now they exist in an old brown leather covered box and they are one of the things that stays with me as I move house, change cities. I'm not a big believer in keeping stuff (IMHO, it just clutters ones life), but the fact that these badges remain as one of the things that stays with me, implies I continue to attach importance to these achievements...

http://scope.bccampus.ca/mod/forum/view.php?id=9010

If you want to join in the two week seminar series on digital badges, feel free to jump in, introduce yourself, add to the discussion or just follow along. You would be very welcome!

The essential tasks for understanding digital badges

Over the next two weeks I will be facilitating a seminar series and two lunch-and-learns focused on understanding digital badges and how they can be deployed and issued to learners of all kinds. The seminar series will take place in SCoPE and begins on December 1st. Feel free to join in...

http://scope.bccampus.ca/mod/forum/view.php?id=9010

Over the first week I will be working through a number of tasks to help build understanding of digital badges and the resources available and required to be able to issue badges to learners (institutional and otherwise).  For an idea of the tasks feel free to review the six described here;

Task 1: The merit badge
1. Identify a merit badge you earned during your lifetime.
What did you have to do to earn it? Did you earn more than one badge? And were they awarded by the same organization?
2. Describe how you displayed the merit badge(s).
If you earned more than one badge, did you display them together? Did you display badges from different organizations together?

Task 2: The digital badge
3. Identify the digital and internet technologies best suited to create a digital merit badge.
How would you create the digital file (image) of the badge? Is it possible to keep people from copying the badge without having earned it?
4. Describe the technologies that could be used to attach (or reference) the learning to the badge.
Is there more than one way of "attaching" learning criteria to a badge? Would this criteria attribute differ from a learners evidence of fulfilling the criteria? Could a badge criteria change through time?

Blooms Rose

Task 3: Identifying the curriculum
5. Identify the completion criteria for any badge you have earned (traditional or digital).
Did you have to complete a series of tasks? Did you have to prove mastery of a skill? How was the mastery described? Was the badge knowledge based, how was the knowledge domain described as a learning criteria?
6. Describe a hierarchy or network of badges.
Does a single badges stand on its own or is it best associated with other badges? Do badges cluster in and around knowledge domains? Do badges exists in hierarchies or networks or both? What other patterns can an collection of badges exist?

Task 4: Go earn some badges already!
7. Identify a variety of sites that issue badges.
Spend some time to find two or more sites that issue badges. Are these event based badges or learning based badges? Do the badges exist on their own or are they a part of a hierarchy or network? Earn some badges and figure out how they are displayed. Were the badges easy to earn? How easily can they be displayed outside of the site where you earned the badges? Display your badges or send the link to a friend.
8. Describe the skills, knowledge and curriculum the badges represent.
Can you easily describe the criteria for earning the badges you just completed? Were they part of a bigger curriculum? Were the badges more commercially oriented? Would displaying the badges attract other to earn the badges or participate in related learning?


Task 5: Building the digital badge(s)
9. Identify the visual elements that best describe the learning represented by a specific badge. 
Does the learning represented by the badge have a de facto standard image. Are there elements of your group, team, organization or institution that also need to be part of the badge? Are there visual elements that are well suited to the badges target learners?
10. Describe the skills and knowledge required to design and create the digital badge(s).
Does your team or organization have resources familiar with creating graphics? Are the resources familiar with the design, branding and layering of images? If your badges start showing up all over the internet do they promote a strong organizational brand? Why does this matter?

Task 6: Defending the digital badge
11. Identify as many objections to digital badges your organization or group may offer that keeps them from further exploring digital badges.
Are the objections focused on current accreditation approaches and why badges shouldn't to be integrated into existing courses, programs, etc? or are they focused on areas of opportunity? Do the objections include new and emerging technologies and pedagogical approaches? or are they focused on the traditional? Where do most objections come from?
12. Describe the different ways badges can be used for the institutional learner, peer-based learner and the self-directed life-long learner.
How do the three learner types described differ when it comes to accreditation. Does each different context / environment offer different opportunities for the issue of badges? What activities outside of courses and programs offer the opportunity to issue badges? Do badges offer things other than just accreditation? How can these be leveraged? Could peer evaluations be represented by badges? Could an independent learner prove competency with a collection of related badges from different sources?

Task 7: Deploying the digital badge(s)
13. Identify the internet technologies required to deploy the digital badge(s).
Think of this in non-technical terms; do you need a location to store descriptions and images? Where / how would you store the association of a badge to each earner? Are there security or information privacy issues you need to consider? Try and describe each of these in non-technical language with as much detail as you can.
14. Describe the skills and knowledge required to develop and administer the software and technical environment required to host digital badges.
Could you be non-technical and successfully deploy digital badges? Can you find any of the self-service digital badge issuing sites? Do any of these free digital badge systems insulate the non-technical person from the technology required to issue digital badges? If technology skills and knowledge are required can they be identified?

A simple three badge system design

I am facilitating a two week seminar series on digital badges and one of the participants suggested issuing badges for the series. Well that seems like a no-brainer, particularly if I build out the badge development as a part of the seminar series. I see value in proposing what I see as the three badge system design and grow the discussion from there. So these are the three badges I am considering issuing, and the basic criteria for earning each badge;

1. Learner badge - person introduces themselves to the group via the discussion forum and contributes to a couple of discussion threads. Mostly, they could be considered lurkers (much can be learned through lurking)
2. Participant badge - person introduces themselves to the group via the discussion forum and actively contributes to 7 of the 12 primary discussion threads, also participates in one of the two lunch-and-learn sessions.
3. Contributor badge - does everything the participant does with the addition of contributing;
   • by designing badge images
   • creating a badge system design for another curriculum
   • blogs about their participation in this seminar series
   • other creative endeavours regarding digital badges

So depending on a persons engagement they will earn a badge. And this recognizes whether a person just "shows-up" or engages deeply. It allows the learner to determine their amount of engagement, and still honors their effort.

OER + OAA² Slide Stack

As an outlier, I still believe the current innovations within education are off target. I think all the disruption is good, but the real innovation is in breaking the emancipation of learning from the institution.

OER + OAA² from Peter Rawsthorne

This isn't to say that institutions aren't still good places to learn, its just an institutional approach should no longer be considered the first or only approach to learning.

federated backpack demystified

What is a federation?

Off the top of my head definition of a federation would be; "A federation is a collection of different and dispersed things that have agreed to (or have been forced to) work together, while also remaining independent within themselves". I also like the definition given from a google search on "federation".

fed·er·a·tion /fedəˈrāSHən/

Noun:

1. A group of states with a central government but independence in internal affairs.
2. An organization or group within which smaller divisions have some degree of internal autonomy.

Ok, so a federation is how things collaborate / work together for a greater good and how a number of things bubble up into a larger collective. Two terms that are have been used within the technology realm are federated search and federated databases. Both these fit well within building an understanding of the federated backpack.

Federated search is a favorite of mine due to a past project where we created federated legal search across eight different content sources. The idea being that when you do a legal search the results should come from different content sources, providing different views or legal positions or sets of information. You really want to get a holistic view when doing legal research and how better than looking into the consolidation of a number of different sources, each which reference a different set on content regarding the same search term. The challenge comes in because, most often, the different content sources don't organize information in the same way. They use different taxonomies, or identify different information elements as important, or the underlying data is stored in different ways. The heavy lifting of federated search is in reconciling these different data (or information) structures so that they can bubble up into a single, well structured, search result. Cool thing was we used open source for the solution. There was a bunch of additions we needed to make, the search engine we used was Lucene SOLR. All good, and the nice thing was it has great features to reconcile the different data structures.

Centralized vs Federated Databases

The federated databases are similar to federated search in that they bring together data from different sources, reconcile the differences and display query results as a single, well structured, result. The accompanying diagram compares centralized database (left-side) with a federated database (right-side). Centralization means that all the data is stored in one database within one model (or a single data structure) for all the data in the database. The federated database transparently maps all the different databases into one single database structure. The mapping will accommodate for any differences in data structure among the different databases. This mapping approach allows autonomy between the databases so they can alter their data structure to better suit their particular needs. Again, the heavy lifting comes in reconciling the data's structural differences and having the technology to provide a single, well structured query result.

Click here is you want a more detailed description of Centralized vs Federated databases.

So there you have it, two good examples of federations within the technology realm. In summary, a federation is the grouping of autonomous sets of data with common elements. When viewing into the federated data it looks to be one set of data where the processes and tools surrounding the federation reconcile the differences of the data sets.

badge is saved in OBI database.

What is the backpack? really.
Important Point 1: Currently the Mozilla digital backpack is a view into your badge data as stored in the Open Badges Infrastructure (OBI). The OBI currently runs on the Mozilla servers that are hosting http://beta.openbadges.org. So when you "store" your badges in your backpack, you are actually storing your badges in the database of the OBI and the backpack is providing the view into that data. Some of the data structures within the OBI are dedicated to the backpack, currently all the data is stored within the OBI database. When it comes to federation the storage location is an important distinction.
Important Point 2: The OBI is open source and can be hosted on pretty much any server that supports the technical requirements of the OBI. This means that many instances of the OBI can exist. Therefore, many backpacks can also exist. This is where the concept of federated backpacks begins.

As the Mozilla Open Badges Infrastructure (OBI) matures and proliferates it will mean badges will be stored in different physical servers and these servers can be distributed through-out the world. People will be storing their badges in these different servers, and be making reference (maybe) to these servers for display of their badges. The idea of the federated backpack allows a consolidated view of all the badges a person has earned, regardless of where the badges are stored.

Why is the federated backpack the holy grail of open badges?
Back in May of 2012 Chris McAvoy (Product Lead for Mozilla Open Badges Project) wrote a post that said that the federated backpack was the holy grail of the open badges infrastructure. So what is meant by the federated backpack being the holy grail of the open badges project. I'd mostly say cause it is the milestone where they could consider themselves finished (well not really). I believe the day when Mozilla could sever its responsibility from hosting an OBI instance is the beginning of when the OBI could truly be released into the public domain.This is also the day when other instances of the OBI are up and running and all these instances openly exchange information about the badges they contain. They become a federation of Open Badges Infrastructure (OBI) instances; or in other words, the federated backpack. This would also mean that Mozilla would no longer have to host an OBI instance and could focus more deeply on making the OBI code base rock solid and continue advocating for an open metadata standard for the digital badge.

Federated Databases (with a digital badges example)

The concept of federation is important when entering into discussions about distributed technology. I like the definition given from a google search on "federation".

fed·er·a·tion /fedəˈrāSHən/

Noun:

1. A group of states with a central government but independence in internal affairs.
2. An organization or group within which smaller divisions have some degree of internal autonomy.

So a federation is how things collaborate / work together for a greater good and how a number of things bubble up into a larger collective. So how does this apply to the idea of federated databases. Federated databases provide technologies to make a collection of databases look like a single database. This is a simplified description that will do for the scope of this post. A good way to describe database federation is to compare it to a centralized database.

Centralized vs Federated databases

 The above diagram puts images of the centralized and federated database next to each other. The left side of the image represents the centralized database where the right side is the federated database. Databases store data and with the centralized model all the data is stored in the single centralized database. With the federated model the data is stored in a collection of related and autonomous databases. Each database within the federated approach may not have the exact same structure. This is both a blessing and a curse. It provides the ability for each database to have a different structure to meet their specific information needs, but it also makes it difficult to merge all the databases into a single common structure. All the databases within a federation have similar elements which provide the ability to link (or map) all the data together. Therefore, providing a single view of data; a federation of data.

Note 1: the amount of "centralized" data stored to link the federated databases together can vary. In some situations there is minimal amount of centralized data storage and all the databases are linked via mix of technology, good design and well managed metadata. The range of differences in how federated databases are implemented is well described in this technical paper on "Federated Database Systems".

Example: a federation of digital badges
Currently there are a number of emerging digital badge systems. Each of these different systems is designed to serve their particular badge issuer needs. Each has both similar and different attributes for what is a digital badge. A basic comparison of their similarities and differences would assist in describing a federation of digital badges. The following five sites issue digital badges, and each of them store user data regarding their earned badges in a database hosted on their respective servers;

• khan academy - https://github.com/Khan/khan-api
• codeacademy - http://www.codecademy.com
• foursquare - https://developer.foursquare.com/
• stackoverflow - https://api.stackexchange.com/
• mozilla open badges - http://beta.openbadges.org

The following differences and similarities come from a shallow analysis of these different badge systems. They serve as an example for this discussion on federated databases.

Data Differences:

• badge criteria - the implementation of badge criteria can vary. It varies from a simple url location (mozilla), a collection of other badges or accomplishments (khan), and a dynamic criteria based on live contribution data (stackoverflow).
• badge evidence - can also vary in its implementation, some of the evidence will follow the format required / specified by the criteria. While other evidence formats include a variety of different media and online contributions.

With these differences each badge system cannot be implemented in exactly the same database because they each use different data types and / or data structures. To overcome these differences when building the federation the data fields need to be mapped to a common data structure so they can be viewed as a single common set of data fields. This information is transformed into a common structure for the data federation. When this mapping occurs something is usually lost due to a systems specific data structure being mapped to a common data structure.

Data Similarities: 

• badge name - the title of the badge
• badge description - the description of the badge
• issuer url - the internet url of the badge issuer
• badge image - the url of the image used
• earner identifier - the unique identifier of the badge earner
• earner email - the earner email address

All the badge systems have these common (or similar) attributes. They are stored in each badge issuers database under different field names, but the data structures are similar enough that they could be merged together into one database without needing to transform the data.

To create a federated database of these different badge systems all the data would be merged. The similar data fields could be easily merged for the format is the same and would require no transformation. The different data fields could also be merged with some transformations, though it is likely some detail would be lost having the differences conform to the similar structure. If all goes well from a merge and data transformation perspective you would end up with a single view into all the different badge systems.

Note 2: Federated systems can have different amounts of merge and transform. In some situation the data is copied and moved into a new database that contains the federated data. In other situations technology sits on top of all the different databases and the merge and transform occurs in real-time and no data is moved or copied.

Note 3: This is a simplified discussion of federated databases. There are many design and technical details that have been simplified for this discussion. Feel free to email me if you would like to engage in a deeper discussion about database federation.

credentials, population and education

So after some research, some thought and a weeks reflection I believe I have come up with the data set I need to begin my discussion about where, I believe, the focus of badges should be. The data I require comes from the follow three sources;

1. tertiary education levels - I want to know the education levels being achieved / persued throughout the world.
2. global population - I want to determine the approximate number of people being educated beyond a grade 10 level.
3. credentialing - how saturated with credentialing the different segments from the above two data sources have become.

I believe that the current set of digital badges projects (open or otherwise) are focused on populations that already have adequate credentialing systems. And for digital badging to be successful they may want to focus on the areas where little or no credentialing currently exists, yet also have access to the internet. More on this to come... stay tuned.

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).

Looking for data

This is the first time I have done this. I am making a request for data... I know its got to be out there. I've looked at gapminder and I can get some of it there, I've queried Google scholar and have found a couple of documents where I can harvest some data. The question I am trying to answer is;

From a global perspective (and as percentages) how many adults go to university, how many go to college, how many develop trade skills, how many are unskilled labour, and how many have no known level of education?

The three graphs I am wanting to complete are found below. The data I have so far is from my readings from the previously mentioned sources. If you know of a document or data set that can provide me this information it would be most appreciated.

Integrating with Open Badges

I have been thinking about how best a project or organization can integrate with open badges. This isn't the bits and bytes type of thinking, but the technical project management thinking required for the near-term (6 -12 months) success of the OBI and all projects that integrate with the OBI. Keep in mind this is a list of what I would focus upon as you work toward success. It is my approach as a technical architect and senior project manager and not Mozilla's or the OBI teams. I see these tasks as a benefit to the Open Badges project, as they will bring further insight into the design of the project, provide further requirements, and put the OBI through is paces before it is considered a production release.

1. Figure out the data model of your badge system design
This may require some technical skills and knowledge (and I suggest you find them at this time) to understand the data requirements of your badge system design. Do this without making reference to the existing OBI metadata specification, for that may compromise the vision of your badge system design. And you should stay true to your badge system design without restraining it by the existing Mozilla OBI specification. Keep in mind the OBI is in pre-release and really needs rubber-hits-the-road insights into how people want to implement badges. Once you have this data model try and map it to the OBI metadata specification for issuing a badge. If it doesn't fit, let the OBI team know via the google group, this could kick off an interesting discussion.

2. Start loading (and deleting) data
I see two kinds of badging systems. Those that already exist; like girl guide badges, khan academy badges, stackexchange badges or military badges. And the badges systems that don't yet exist. These existing badge systems have a huge number of badges already stored within them. If these badges are to make it into Mozilla Open Badges, we need to start loading them into the OBI now. This attempt to mass load badges into the OBI should come as a gift to the OBI team. Better they start dealing with the issue of thousands of badges showing up while still in pre-release than having them show up once Open Badges is officially released and bringing the whole OBI to a halt. If you are going to load data, you should also be able to delete the same data. The ability to load data should be a feature available within the OBI. A test environment should also be available, so partners can test their data loads, and delete the data that was loaded. The testing of data loading is a blog post in itself and beyond the scope of this particular tome.

Keep in mind that manually entering badges (one by one) is also a good idea as it will utilize the same process as the earners will use for adding badges to their backpack.

3. Build an automated testing approach
If you have already started working with the Mozilla Open Badges Infrastructure (OBI), or are considering it in the next short while, you should consider yourself an early adopter. And given this type of role expect things to change within the OBI, as it is currently a pre-release version. Given this early release things can change that may break the code at your end of the integration. Building an automated testing approach will yield great benefits as it will reduce the downtime of your system, increase the quality of your code, and provide early warning if the system elements beyond your control have changed. These automated tests could be built for both your internal system and the API calls you make to the OBI. Once these automated tests are built, it would also be beneficial to run them against the OBI at scheduled times to ensure the programatic assumptions made by your system are still valid against the OBI.

4. Determine where and how you want to encourage the display of your badges
Once you have badges "loaded" into the OBI and have viewed these badges in the earners backpack it becomes important to display the badges in a variety of locations. There is a growing number of widgets built for badge display and with the variety of methods for display you never know where your badges will show up. It is important to test these different display approaches and as a part of your issuing site encourage people to use specific displayers. You may also want to build or integrate your own displayer. What is important here is that you have displayed your badges in a number of different locations for testing purposes.

5. Advocate for other attributes to be added to the OBI metadata specification
Learning rarely occurs in isolation and learning is always related to other or previous learning in some way. The current metadata specification has a badge standing on its own. There is currently no attribute within the badges metadata that allow for it to link-to, be the detail of, or cluster-within another badge or set of badges. The OBIs' criteria attribute is being extended to allow blobs of data, so you could store this badge inter-relationship and linkage data in this criteria attribute. I believe this approach will store this information in the wrong place, for issuing systems would then have to store and maintain the data about these relationships of interest. A badge should know for itself if it exists in relationship to other badges.Erin Knight has created a great blog post describing the webmaker badge system design.

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

6. Encourage the completion of badge validation
Over the last year there has been much discussion regarding badge assertion or validation. The idea being that it can be determined if a badge is still valid through time. A number of approaches have been tabled, and agreement to the value and approach to implementation of this feature has yet to be agreed upon. I believe it is an important feature, for it would be nice to click on a badge from within the backpack or a displayer site and be notified if the badge is still valid.

If you have further questions or require assistance please do not hesitate to contact me. I will be very happy to assist. 

Curiosity, patience and grit

I've been following Doug Belshaws' work around defining digital / web literacies and I admire his persistence and broadness with this endeavour.

• https://etherpad.mozilla.org/skills2
• http://dougbelshaw.com/blog/2012/09/18/mozilla-web-literacies-v0-7
• https://etherpad.mozilla.org/skills3

I have found his taxonomy / matrix / domain missing the required pre-beginner / prerequisite information. And thankfully, this has now been added to the discussion. I have been teaching digital literacies to kids, youth and adults for over 20 years. Mostly, it started with my wanting to be a teacher and working for small computer stores and giving volunteer workshops to the parents of my (now 16 year old daughters) school. Since this beginning I have taught in many places online and off, at many different levels including workshops for faculty and graduate student with Memorial University; Teaching digital literacies at these different levels taught me the importance of encouraging people to let go and develop curiosity, patience and grit in their approach. I honestly believe if people can't develop this kind of a mind set when approaching their digital literacy, they won't be successful.

The essential foundational capabilities for developing your personal digital literacies are;

• have the curiosity to figure out how something works by taking it a part, moving things around, breaking it and getting it working again.
• have the patience to stick with it until it is done, when something (an experiment) doesn't work out you need the patience to try again and again without losing focus through frustration.
• have the grit to see the bigger picture and stick with it. Many things will push you away from being successful in developing digital literacies. Have the grit to stay with it long term. Digital literacy is an ongoing practice. As new technologies and approaches emerge, remaining literate will require an ongoing practice.

Open Badges FAQs

Over the last few months I have been working on updating both the General and Technical FAQs for the Mozilla Open Badges project. My process was as follows;

1. Read all the document sources regarding Open Badges I could find. This included;
• openbadges.org
• mozilla open badges wiki
• github open badges site
• google group
• monitoring of social media
• attending the weekly community calls
• listening to the Mozilla IRC
2. With all this reading I began to identify trends in discussion and frequently asked questions
3. I harvested these trends into the Mozilla wiki as new FAQ entries
4. I continued my work and moved my work over to general and technical etherpads until I completely reviewed the google group in its entirety.
5. I then edited these etherpad entries and put them into a staging area for review. Once the review period was over I moved them back out to respective wikis.
6. These two wikis can be found at the following two links;
• Github technical wiki;  https://github.com/mozilla/openbadges/wiki/FAQ
• Mozilla general wiki;  https://wiki.mozilla.org/Badges/FAQs
7. Now I look for new FAQ entries as I continue to monitor all the Open Badges community sites and resources.

Highlights and Trends

What do I see as the highlights and trends (or lack thereof) within the discussion around the beta release of Open Badges?

1. Most technical questions are with implementing the issuer role.
2. Non-technical people seem to struggle with the technical issues. This would seem obvious, I do believe the Open Badges partners and community are a less technical and a more pedagogical crowd. This should be expected due to Open Badges playing more in the educational space. The technical challenges should also not come as a surprise given the beta release. I have every faith the open badges platform will become easy for the non-technical badge implementer.
3. Badge integrity and validation (assertion) is important to people.
4. Badge systems design is important and still at its early stages. I believe this is due to the broad variety of learning situations badges can be issued.
5. People are wrapping there heads around badges both from a skills and knowledge perspective and a resume, cv and job search perspective.
6. People are really interested in how open badges are going to work and be displayed within the whole social media landscape.
7. Life-long learning seems to be the largest consideration for where badges will be utilized and hold most benefit.
8. Discussion around assessment and alternate accreditation hasn't yet materialized in force.
9. Project seems to be trending toward higher education and academia. Its an attractive place to play. I'd hope it would stay focused on the more common places of life-long learning.
10. Not every FAQ entry harvested needs to have an audience, particularly some may disappear due to open badges being beta.

Community Engagement

Tuesday September 4th at 10 am EST and again at 8 pm EST I will be hanging out in Google+ and discussing Community Engagement approaches of the Open Badges team. I am going to use the following slide deck to prompt discussion. If you are new to open badges or want to listen in on an introductory discussion on open badges, message me. This hangout will also be live broadcast on YouTube and can be viewed via my Google+ profile.

The open badges team uses a collection of online tools and approaches for community engagement. This collection of tools is used for a number of different contexts. They range from open community engagement with a large number of participants to small one-on-one engagements. The tools offer both synchronous and asynchronous approaches.

Open Badges Engagement from Peter Rawsthorne

An introduction to Open Badges

Tuesday August 25th at 10 am EST and again at 8 pm EST I will be hanging out in Google+ and discussing Open Badges. I am going to use the following slide deck to prompt discussion. If you are new to open badges or want to listen in on an introductory discussion on open badges, message me. This hangout will also be live broadcast on YouTube and can be viewed via my Google+ profile.

You need to be in one of my Google+ circles to view the slides and engage in the discussion. So please go to my Google+ Profile and add me to a circle, I will reciprocate. Again, if you don't have an invite you can still watch along as each session will be broadcast via YouTube.

Mozilla Open Badges from Peter Rawsthorne

I have also added the audio track from the first Google+ Hangout to this slide deck. So if you have an hour of time please take a listen.Or just quickly take a view of the slide deck to get a sense of the session.

Open Badges Case Study 1 - Wikiversity, part 3

This case study is the last in a series of case studies created to help people learn about open badges. This case study describes the manual issuing of Mozilla Open Badges from within a Wikiversity course. This screencast discusses the claiming of the badge, and how it is stored in the earners backpack.

Reflective Activity: What needs to be similar in both the open badges backpack login email address and the json file?

Open Badges Case Study 1 - Wikiversity, part 2

This case study is the second of a series of case studies created to help people learn about open badges. This case study describes the manual issuing of Mozilla Open Badges from within a Wikiversity course. This screencast discusses the technology required to implement the manual issue of the badge. It also describes how the criteria and evidence to manually issue badges can be stored and assessed.

Reflective Activity: Do you understand enough programming to hash the learners email address with the salt value? If not, where would you get access to this resource or skill?

Open Badges Case Study 1 - Wikiversity, part 1

This case study is the first of a series of case studies created to help people learn about open badges. This case study describes the manual issuing of Mozilla Open Badges from within a Wikiversity course. This screencast discusses the scenario for the case study and touches upon how to design a badging system. It also describes how the criteria and evidence to manually issue badges can be stored and assessed.

Reflective Activity: What would you consider the best way to issue badges? For milestones within a course or for the course as a whole? Or would you issue both? What are the strengths and weaknesses for each approach?

Open Badges, LRMI and OER

Over the last few months I have immersed myself in Open Badges. As I explore this technology I can't help but reflect upon my past experiences as an educational technologist, software developer, OER content creator, project lead and solutions architect. And yes, all these apply as I fold LRMI into the mix. My reflection points include;

• Open Badges as educational resources
I believe that the criteria and evidence attributes of an open badge can also be learning resources. I see the badge as the destination, where the criteria and evidence are the learning journey. Exploring a badges criteria and, many earners, evidence can provide valuable learning resources.
• Everything online is an OER for the independent learner
I've spoken about this for years... the Internet is the platform and as an independent self directed learner all Internet resources should be considered educational resources. Particularly, when you consider fair-dealing / fair-use.


• LRMI is an important standard for educational resources
Great search results increase access to learning resources. The faster you can get to the resource, the better. Particularly, if the resource is close to within the learning context you are working. LRMI is going to help greatly with increasing access to educational resources, especially when search facets allow for resource exploration clustered around a search term (or context).
• The vocabulary is as important as the schema
The vocabulary populates some of the fields of the LRMI schema. These fields describe the resources user role, type, etc. Take a look at the LRMI specification if you want more. Having a consistent and well thought-out vocabulary will help greatly in putting learning resources into context. It is the vocabulary that will classify resources and allow the building of search facets.

So how do I see Open Badges, LRMI and OER working together?

• The OER should include metadata to increase searchability (LRMI works well here). OER should also be referenced within a course outline, learning challenge, book, course material, badge criteria, etc, etc...
• OER search results should provide a listing of learning resources, assessment resources, and accreditation resources (open badges works here). The search facets should cluster around subject domains, themes, keywords, available taxonomies, etc. The facets should also include assessment and accreditation resources related to the keywords / subject domain of the search.
• The criteria and evidence resources found within the json attributes of the open badges specification should point to educational resources and it should become a best practice to embed LRMI within these resources. 
• The LRMI vocabulary should include "badge" as a learningResourceType. This would also assist in building the search facets. The badge, and its criteria and evidence, also needs to expose this attribute to be picked up by search indexing.

Webmaking and telling stories

Today we had our first webmaking session where we are developing the skills to create a documentary about community food production. On Bowen Island we have a week long event called BowFeast, the idea is you eat locally grown food wherever possible. It is an event that really brings the community together and celebrates all the gardens and people who grow their own food. This week of BowFeast also culminates in the farmers market.

Our first webmaking session was mostly a discussion of storytelling, citizen based journalism, interview techniques and the privacy issues around interview, photography and video. All good!

From a scaffolding perspective this first session was quite non-technical and really got into interviewing using a camera and the way to ask open questions, follow (and lead) a thread of discussion during the interview and how to close it all down and summarize, give thanks.

For further inspiration we all watched the popcornified video about urban farming in Oakland, California. This is a great video, for it tells a great story, provides a historical perspective and also investigates food production.

WebMaking on Bowen Island

Two main themes to my webmaking over the next six weeks. Citizen based journalism with youth involved with localized food production and the creation of a rock-umentary with my teen daughter and her friends.

Citizen based journalism
The localized food production webmaking event got some local publicity in the island newspaper, which was great to read and increased my excitement about this event. It is likely this event will span three workshops where the first two will take place in the island information centre (shown in photo) and the last one in the community school. The first two sessions are mostly about skills development for journalism. Interview skills, videography, photography, storyboarding, music selection... that kind of stuff. The last session is going to be building all this into a small documentary with the Mozilla Popcorn Maker.

Rock-umentary
My teen daughter and her friends are totally into music, photography, and video production. So I set a challenge for them to create a rock-umentary about Ana Rose's music career so far. And when we are done it will be fully enhanced using Mozilla popcorn maker or maybe just popcorn.js. Looks to be an exciting six weeks...

formative and summative events, popcornjs, and screencasts

Another round of enhancements and the addition of summative events completes step 0 of my open badges step by step guide. I have been building a step by step guide for open badges where I have been creating a number of open educational resources. All this work (and other peoples contributions) is destined to become a part of the School of Open Badges on the P2PU. One of the main elements I have been working on is how to enhance screencasts for learning. Just watching a video screencast can be good for learning, particularly when you think about having the ability to stop and start the screencast to view something more than once. The main enhancement I have been working on is to add formative events to the screencast, so the learner can focus on important information and have immediate links to the subject being described. This allows the learner to pause, read deeper, reflect, and then continue with the screencast.

click this image to view the enhanced screencast.

Formative events:
Formative events enhance learning by providing further opportunities to learn during the overall learning experience. The formative events are immediate and occur as skills and knowledge are forming. The idea of formative events is often used with the idea of a formative assessment, that is in-lined with the learning module and the assessment become a part of the learning. Within my enhanced screencasts I have used popcorn.js to inject links, popups and learning outcomes while the screencast is running. When the learner clicks the link it is opened in a new tab or window, this allows the screencast to continue (or be paused) and the learner to further explore the concept via the linked information (this is not possible with current screencasting technology). The popups highlight important pieces of information. The learning outcomes identify during the screencast.

Summative events:
The summative event(s) are via a link once the screencast is complete. It provides a complete summary of the screencast with links to the following;

1. the youtube instance of the screencast
2. the popcorn.js enhanced version of the screencast
3. a listing of all this links presented during the screencast
4. a listing of the learning outcomes identified during the screencast
5. a reflective activity to deepen learning

The idea of the summative event is to provide something to go back to and use as an educational resource to reflect and deepen learning. Feel free to enjoy and learn from the growing repository of these enhanced screencasts made specifically to learn about and implement Mozillas Open Badges.