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.

School of Open Badges

Over the last couple of weeks a lot has happened with Open Badges and the Peer 2 Peer University. First off I was collaborating with Leah MacVie around what is the follow-on to the P2PU Open badges 101 course. And I was wanting to move my work of putting together a step-by-step into the P2PU as the platform for peer learning around badges. Leah had also done a bunch of great work in developing the first 101 course and had an outline for another... we were wondering how all this would fit together.

I was inspired by Leah's work so I drew on the outlines she had created, added my step-by-step guide outline into the mix and thought a lot about what would be a comprehensive Open Badges curriculum. I created a nine course curriculum and created really brief course descriptions and cane up with a course leveling (beginner, intermediate, expert, and master) approach and gave the courses numbers like 102, 103, 201, 202, etc... I took this work to the Open Badges Community Call to gather feedback. The feedback was outstanding and exemplary in relation to badge systems design, the two highlights were;

1. Don't create a prescribed type journey (get away from beginner, intermediate, 101, 102, 201, etc...) each badge should stand on its own and the related learning should be scaffolded into the single badge challenge (or course). I commented on how difficult this would be as often learning requires previous learning. The feedback persisted and they community challenged me to put down the spoon and think way outside the box. So I did...
2. Creating a nomenclature for naming the courses, but they really don't have to imply any kind of leveling or achievement, they are just names. This made sense to me and as I was reviewing my proposed nine courses I jokingly said... "like a flower with nine petals".

With this feedback I edited the table and leveraged the flower analogy to the point where I fit different parts of the flower into the matrix. And to a small extent I fit the part definitions into the course themes. all good.

A description of this matrix will be in a subsequent post.

To use the flower analogy even further I tried to create a graphic of a nine petal flower. Where each petal represented a course. What I ended up with was quite computer science like... but it worked. And fortunately, I was able to get assistance from Leah and she did her magic and turned what I had created into a beautiful flower. You can view the two versions here, and I'll let your guess who did which.

  

Version 1

  

Version 2

The most meaningful parts to all this are threefold; first, we ended up with a really nice looking curriculum design graphic; second, we determined the p2pu open badges course matrix; and third, we ended up with a working example for badge systems design.

Creating Online Learning Communities

Thank-you Bill Pusztai

My recent work has taken me back to thinking about and discussing the effective creation of technically focused online learning communities. Learning online is something I have been doing for a while. And given both my pedagogical and technical background, I often get into the nuts and bolts (or bits and bytes) of building online learning communities as well as the actual building of the community. Much of my recent reflection has been about engaging and building learning communities, particularly technology (or digital literacy) focused learning communities. This post is mostly about the engagement and pedagogical side of this community building. Another post about the technical side of building online learning community may come, but is well articulated in this slideshare from a while back; http://www.slideshare.net/prawsthorne/building-onlinecommunities

Background
I believe some background information on where I am coming from in my thinking is important. There have been a number of experiences (professional and otherwise) that have set my thinking about building technically oriented online learning communities.

• Being a software developer and working extensively with lean and agile teams - what is important: most developers are self-directed life-long learners and they owe a lot to their peers who have contributed to what they are reading and learning.
• Being an enterprise architect and encouraging enterprise2.0 thinking - what is important: collective intelligence and learning/teaching is knowledge management. being patient.
• The musings of Zuckerberg vs. Poole - what is important: anonymity encourages contribution, nuf said, read my post;  http://criticaltechnology.blogspot.ca/2011/03/ignore-copyright-and-blissfully-create.html
• My time as a early contributor to WikiEducator - what is important: recognizing contribution, doing it in the open, monetize activities wherever possible, and governance can be done exclusively online and in the open. love your volunteers.
• Implementing seven major projects in three years with CLEBC - what is important: open approaches work in closed shops. API's allow distributed approaches. recognizing areas of practice (or communities of practice) is important. Video resources can be long-tailed. love your volunteers.
• My graduate studies were exclusively online - what is important: face-to-face and blended opportunities are worth every moment and should be encouraged if you want greater depth to learning. This may seem against the creation of online learning communities and favoring traditional learning environments, but the point I am making is that if the opportunity to get together in the same physical space with any community member presents itself, seize it!
• Communities can be built in many places by many people - what is important: often communities can fracture into other communities, or seasoned contributors will disengage, move-on or start other communities. Be supporters of this action for it increases the overall size and reach of the subject and its growing content.
• Authenticity can be community policy - what is important: based on an articulated policy the authenticity of the dialogue can be increased. While anonymity can create contribution and authenticity, the community can also set and enforce policy to encourage authenticity.

Engagement, engagement, engagement
Contributors are the MOST valuable resource, they are the community! Yes, lurkers are also a huge part of any growing community, and lurkers sometimes convert into micro-contributors. The people who are, or see themselves as, stewards of the community need to engage often and with reckless abandon. They also need to encourage the stewardship to be a shared activity. Engagement should be across social media, and where possible use tagging to bring it all together.

Tagging For Community of Practice from Peter Rawsthorne

Freedom (without scholarly egos, well... all egos)
Its the micro engagements that grow into macro engagements. If people aren't given the freedom and support to make small contributions they will rarely make the larger contributions. And once a contribution has been made facilitating discussion should come from elsewhere (not the contributor themselves) with great encouragement and recognition being given to the initial contributor. An amazing community is grown with many small and meaningful events. People should never be made to feel badly about their contribution... and don't feed the trolls.

Small is beautiful
Encourage contribution in small chunks, build discussion and shared understanding around these chunks. Allow the chunks to coalesce into larger works. Trying to complete a larger works without community engagement, ends up teaching the creator. And the online community becomes passive...

Facilitators are stewards (and need to be tech savvy)
Online learning communities that are technical in nature need to be facilitated by the technically savvy, if they are not this is quickly noticed and the community will lose credibility. The facilitators must eat their own dog-food and be exemplars in engagement and encouragement.

Its all about love!
I know it sounds smoltzy, but building a great online learning community is an activity of the heart... finding people who are deeply committed to the subject matter of the learning community is essential for longevity and depth of learning. People quickly get a real sense of a community (online or otherwise) and if it is not genuine people will recognize this.

Building successful online learning communities has a lot to do with reaching-out and encouraging others. And for technology focused learning communities this includes drawing in people who make small technical contributions who often contribute in small and quiet ways. Surprisingly, it is often these small contributions that have the biggest impact.

1/2 finished posts have been chosen

A month back I was musing about my > 20 half-finished blog posts, I decided to put it out to vote. After three weeks the poll was closed and my next few posts have been chosen. The immediate blogging with cover the following six posts; with injected posts from my work with open badges, building online learning communities, popcorn.js, and other pedagogical subjects I am inspired to write about. The poll results can be found within the original post, and my next few posts will include;

1. Computer Science taught as an art (33% voters)
2. Learning is Knowledge Management (33% voters)
3. Traditionalists, Reformers and Outliers (28% voters)
4. Not everyone is social (28% voters)
5. Learning Platforms for People (28% voters)
6. Using smart phones within a connectivist approach (28% voters)

As of the poll closing day, 21 of 204 viewers voted. And the final results were different than those a week after the poll had opened.

wrapping screencasts in popcorn.js to enhance learning

My work over the last month has been to create screencasts for the Mozilla open badges initiative. I am building screencasts to provide online tutorials describing the different technical aspects of the Open Badges Infrastructure (OBI). There are many scholarly articles discussing the effectiveness of screencasts on learning; a google scholar search on "screencast learning" provides a good listing if you would like further reading. One aspect of the screencasts I have been working on for a while is how to deepen the learning around the screencast. In a number of my previous projects, including CLEBC and AIM language learning, we enhanced screencast learning by including; chat, discussion, in-lined formative questions, and links to related resources. All of these enhancements helped in creating a more complete learning module by providing multi-modalities to learning.

What I believe is the most important is the clustering of resources into a succinct module. The idea being that the screencast is "surrounded" by many resources specific to the subject and contents of the screencast. Another technology currently being released by Mozilla is popcorn.js. This technology allows screencasts to be greatly enhanced by adding resources and screen elements as the video progresses. Popcorn is well described on the related Mozilla site;

"Popcorn.js is an HTML5 media framework written in JavaScript for filmmakers, web developers, and anyone who wants to create time-based interactive media on the web. Popcorn.js is part of Mozilla's Popcorn project."

What popcorn.js provides is the ability create a comprehensive learning module where a screencast is clustered with other related resources. These additional resources can be explored while the video is in progress or referenced after the video is complete. The main point being the resources are available through links and are presented within the context of the progressing video.

To view the use of popcorn.js to enhance learning visit this growing repository of popcorn wrapped screencasts; http://badges.bit.bc.ca/guides/step01.html

Related readings:

• Farley, S., Breck, J,. (n.d.). Finding Knowledge in the Global Golden Age of Learning. Retrieved from http://globalknowledgeinitiative.org/news/judy-breck.html
• Mestrea, L. (2010). Matching Up Learning Styles with Learning Objects: What's Effective? Retrieved from http://www.tandfonline.com/doi/abs/10.1080/01930826.2010.488975
• Oehrli, J.A., Piacentine, J., Peters, A., & Nanamaker, B. (2011). Do screencasts really work? Retrieved from http://www.ala.org/acrl/sites/ala.org.acrl/files/content/conferences/confsandpreconfs/national/2011/papers/do_screencasts_work.pdf

Open Badges 3.3 - Hashing the recipient attribute

The last of three screencasts on the basic requirements for setting-up a server to be a badge issuer. In this screencast I look at hashing the earners email address with the slat value. This hashed value is then used in the recipient attribute of the json file. This screencast is a part of a step-by-step guide built to support the onboarding of the non-technical OBI implementer.

Reflective Activity: Do you feel confident with a server side programming language like PhP or Python? If not, do you have access to programmer resources to assist?

Open Badges 3.2 - Configuring for the json content-type

The second of three screencasts on the basic requirements for setting-up a server to be a badge issuer. In this screencast I look at configuring the web server to support the json content-type. This screencast is a part of a step-by-step guide built to support the onboarding of the non-technical OBI implementer.

Reflective Activity: Do you feel confident with your basic server administration skills? If not, do you have access to server administration resources to assist?

Open Badges 3.1 - Importance of a stable URL

The first of three screencasts on the basic requirements for setting a server to be a badge issuer. In this screencast I provide an overview of the basic server and configuration needs to issue a badge manually, and discuss the importance of a stable URL for the origin, criteria and evidence json attributes. This screencast is a part of a step-by-step guide built to support the onboarding of the non-technical OBI implementer.

Reflective Activity: Manually issuing a badge is not the only approach to accomplish this task? Can you think of one (maybe two) other ways to issue a badge using the OBI?

Inquire, Paraphrase, Acknowledge, Advocate

So I was reading through the information streams created around this years OSCON. And it looks to be an outstanding event... focused on the impact the open movement has had at many levels and in many realms. All good! I am so happy to be a part of it and grateful to be a part of the Open Badges initiative with Mozilla Foundation. A lot of my current activity is with building community in and around the implementation of the Open Badges Infrastructure (OBI). So what really resonated with me are the four traits for a good community as lifted by Tim O'Reilly from David Eaves keynote. The four traits are; Inquire, Paraphrase, Acknowledge, Advocate. But what does all this mean to community building? So I looked up each and what could each community member do to assist in building a strong sustainable and healthy community.

http://www.flickr.com/photos/roland/7436172034/

• Inquire - To seek information by asking a question; curious; probing.
  Always be asking questions and seek information to understand each community member and their positions and context.
  
  
• Paraphrase - A restatement of a text or passage in another form or other words, often to clarify meaning; clearness; rewording.
  Confirm that you have understood, add strength to another community members words by showing your understanding as it related to a particular issue within the community. Even restate within a different context as it relates to the community.
  
  
• Acknowledge - to show or express appreciation or gratitude for. to acknowledge a favor. To express thanks or gratitude for. To admit the existence, reality, or truth of.
  Let people know they are welcome in the community by acknowledging their contribution, engagement and presence. Confirm their contributions by tying them back to current and emerging truths within the community and its shared knowledge.
  
  
• Advocate - to support or recommend publicly; plead for or speak in favour of. to speak or write in favor of; support or urge by argument; recommend publicly.
  Speak out for all the good work the community is doing. Choose the topics of interest to you, within the community, and speak passionately of them. Assist in keeping all things moving forward; network, engage, understand, promote, and share. Be positive... advocate.

References:
http://www.thefreedictionary.com/
http://dictionary.reference.com/
https://twitter.com/timoreilly/statuses/225622408231534592
http://www.oscon.com/oscon2012/public/schedule/detail/24859

Open Badges Step 2.3: Technical Prerequisites - Server Infrastructure

The last of three screencasts on the technical prerequisites for integrating with the Open Badges Infrastructure. In this screen cast I discuss the server infrastructure required for each of the three roles of; issuer, earner, and displayer. I mostly spend my time describing the server needs of the issuer, where the displayer is quite similar to the issuer, especially if it becomes a fat displayer. And by fat I mean it offers a lot of displayer services related to badges and their earners. Again, the earner requires the least infrastructure, but can require more if we begin down the road of federated backpacks. More on the federated backpack in a later screencast.This screencast is a part of a step-by-step guide built to support the onboarding of the non-technical OBI implementer.

Reflective Activity: If the server infrastructure for the issuer is mostly about storing and managing earner, evidence, criteria and badge information, what information needs to be stored and managed by the displayer? Compare and contrast the server infrastructure needs of the issuer and the displayer.

Open Badges Step 2.2: Technical Prerequisites - Technology Stack(s)

The second of three screencasts on the technical prerequisites for integrating with the Open Badges Infrastructure. In this screen cast I discuss the technology stack(s) required for each of the three roles of; issuer, earner, and displayer. This discussion is more of a logical view of the technologies you need. The idea being we are building on ideas from the non-technical perspective. Getting deeper into the technology will come in later screencasts.This screencast is a part of a step-by-step guide built to support the onboarding of the non-technical OBI implementer.

Reflective Activity: Why does the issuer require the most technology? Can the earner get away with having no technology beyond internet access and a facebook account? Can you think of a reason why a displayer would require more technology than the issuer?

Open Badges Step 2.1: Technical Prerequisites - JavaScript

The first of three screencasts on the technical prerequisites for integrating with the Open Badges Infrastructure. In this screen cast I discuss the basic javascript you need to know to manually issue badges. I also touch upon the prerequisites if you move beyond manually issuing badges and integrate with an LMS or other server application. This screencast is a part of a step-by-step guide built to support the onboarding of the non-technical OBI implementer.

Reflective Activity: If you are going to integrate badge issuing with your learning management system (LMS) or other server application, do you need more than just JavaScript?

WebGL Interview 2

My learning in the open journey in building learning resources for the Mozilla Ignite initiative continues. 8 days back I had the amazing opportunity to speak with Mozillians Benoit Jacob, Ben Moskowitz and Bobby Richter, the conversation created the following pocast. This podcast was a discussion about some of the ideas forming from the Ignite challenge and we discussed what would be required to implement these ideas using WebGL within the superfast-superwide GENI network. The purpose of this podcast was to further identifying technologies and approaches so we can create focused learning labs, and set up experiments that others can follow and use as learning resources.

WebGL Interview 1

My learning in the open journey in building learning resources for the Mozilla Ignite initiative continues. 10 days back I had the amazing opportunity to speak with Mozillians Ben Moskowitz and Bobby Richter, the conversation created the following pocast. This podcast was a blue-sky discussion about using WebGL within the superfast-superwide GENI network. The purpose of this podcast was to start identifying technologies and approaches so we can create focused learning labs, and set up experiments that others can follow and use as learning resources.

Open Badges Step 1: Claim your first badge

In this screencast I look at some of the technical resources available for introducing someone to the open badges infrastructure (OBI). The screencast is a part of the Introduction to Open Badges Step by Step guide. The main theme of this screencast is to claim a couple of badges and to look at a number of badge issuers.

Reflective Activity: Once you have earned, claimed and displayed a few badges take some time to reflect upon the three main roles of open badges; the issuer, the earner and the displayer.

Open Badges Step 0.4: P2Pu Open badges 101

In this screencast I look at Peer 2 Peer Universities Open badges 101 course. The screencast is a part of the Introduction to Open Badges Step by Step guide. The main theme of this screencast is to encourage people to familiarize themselves with and complete the course.

Reflective Activity: How could Peer 2 Peer University issue badges. Should they give badges for completing individual challenges or for complete courses? What other badges within peer based learning could P2Pu issue?

The followers have spoken

Well it looks like my poll asking for assistance on which half-finished blog post I should complete next has provided me adequate results. Other than the injection of posts regarding open badges and ignite learning labs I will spend my next while completing the following posts, in this order;

1. Traditionalists, Reformers and Outliers - 54% voters
2. Computer Science taught as an Art - 45% voters
3. Digital Me (Mozilla + Life-Long Learning) - 36% voters
4. Using smart phones within a connectivist approach - 36% voters

What fun!!!

Help me complete my half-finished blog posts

After reading a couple of posts on Boris Mann's blog, in particular; "The Posts That You Don't Write". I got thinking about all the half written blog posts I have. My blogging style is to write down ideas for blog posts as unpublished blog posts. As the ideas pop into my head I create the post, add notes and references, loop around, and often finish them off. This can take months, sometimes over a year... most of the time they get finished (or deleted). Currently, I have over 20 blog posts like this, some are almost finished some are not. So I wondered, what would happen if I put this out to vote.

 Which of these half-finished blog posts should I complete?