Hi there, if you read this blog it’s probably for one of three things,
1) my investigation of the life of Isham Randolph, the chief engineer of the Chicago Sanitary and Ship canal.
2) you know me and you want to see what I’m doing but you haven’t discovered Twitter or Facebook yet.
3) Open Badges.
This is a quick update for everyone in that third group, the Open Badges crew. I have some news.
When I joined the Open Badges project nearly three years ago, I knew this was something that once I joined, I wouldn’t leave. The idea of Open Badges hits me exactly where I live, at the corner of ‘life long learning’ and ‘appreciating people for who they are’. I’ve been fortunate that my love of life long learning and self-teaching led me down a path where I get to do what I love as my career. Not everyone is that fortunate. I see Open Badges as a way to make my very lucky career path the norm instead of the exception. I believe in the project, I believe in the goals and I’m never going to not work toward bringing that kind of opportunity to everyone regardless of the university they attended or the degree hanging on their wall.
This summer has been very exciting for me. I joined the Badge Alliance, chaired the BA standard working group and helped organize the first BA Technology Council. At the same time, I was a mentor for Chicago’s Tech Stars program and served as an advisor to a few startups in different stages of growth. The Badge Alliance work has been tremendously satisfying, the standard working group is about to release the first cycle report, and it’s been great to see our accomplishments all written in one place. We’ve made a lot of progress in a short amount of time. That said, my role at the Alliance has been focused on standards growth, some evangelism and guiding a small prototyping project. As much as I loved my summer, the projects and work don’t fit the path I was on. I’ve managed engineering teams for a while now, building products and big technology architectures. The process of guiding a standard is something I’m very interested in, but it doesn’t feel like a full-time job now. I like getting my hands dirty (in Emacs), I want to write code and direct some serious engineer workflow.
Let’s cut to the chase – after a bunch of discussions with Sunny Lee and Erin Knight, two of my favorite people in the whole world, I’ve decided to join Earshot, a Chicago big data / realtime geotargeted social media company, as their CTO. I’m not leaving the Badge Alliance. I’ll continue to serve as the BA director of technology, but as a volunteer. Earshot is a fantastic company with a great team. They understand the Open Badges project and want me to continue to support the Badge Alliance. The Badge Alliance is a great team, they understand that I want to build as much as I want to guide. I’m so grateful to everyone involved for being supportive of me here, I can think of dozens of ways this wouldn’t have worked out. Just a bit of life lesson – as much as you can, work with people who really care about you, it leads to situations like this, where everyone gets what they really need.
The demands of a company moving as fast as Earshot will mean that I’ll be less available, but no less involved in the growth of the Badge Alliance and the Open Badges project. From a tactical perspective, Sunny Lee will be taking over as chair of the standard working group. I’ll still be an active member. I’ll also continue to represent the BA (along with Sunny) in the W3C credentials community group.
If you have any questions, please reach out to me! I’ll still have my email@example.com email address…use it!
Earning an Open Badge is easy, there’s plenty of places that offer them, with more issuers signing up every day. Once you’ve earned an open badge, you can push it to your backpack, but what if you want to include the badge on your blog, or your artisanal hand crafted web page?
You could download the baked open badge and host it on your site. You could tell people it’s a baked badge, but using that information isn’t super easy. Last year, Mike Larsson had a great idea to build a JS library that would discover open badges on a page, and make them dynamic so that a visitor to the page would know what they were, not just a simple graphic, but a full-blown recognition for a skill or achievement.
Since his original prototype, the process of baking a badge has changed, plus Atul Varma built a library to allow baking and unbaking in the browser. This summer, Joe Curlee and I took all these pieces, prototypes and ideas and pulled them together into a single JS library you can include in a page to make the open badges on that page more dynamic.
There’s a demo of the library in action on Curlee’s Github. It shows a baked badge on the page, when you click the unbake button, it takes the baked information from the image and makes the badge dynamic and clickable. We added the button to make it clear what was happening on the page, but in a normal scenario, you’d just let the library do it’s thing and transform the badges on the page automatically. You can grab the source for the library on Github, or download the compiled / minified library directly.
There’s lot’s more we can do with the library, I’ll be writing more about it soon.
First things first, what do we mean when we say “Open Badges Infrastructure?” Infrastructure is a bit of a loaded term, you can interpret it as servers, you could interpret it as software, or both hardware, software, internet…all the things. We’ll make this easy and say that the Open Badges technical Infrastructure is all the things that make it possible to earn or issue an Open Badge.
“All the things” is an easy answer to the question, “what is the open badges infrastructure?” but it doesn’t help much when we’re trying to push the infrastructure forward, when we’re trying to grow the ecosystem. Given a technical infrastructure need, how does the Badge Alliance, and the Open Badges community, figure out the best way to address the need? If the OBI is “all the things,” who could support it without turning the OBI into a silo’d badge system?
When we asked what role the Badge Alliance would play in the OBI, we knew that the OBI needed a shepherd organization that could help the members of the OB community coordinate their efforts maintaining the long-term health of the OBI. So how do we decide what actions fit into that model? What parts of the OBI are fair game for the BA to directly touch, which parts can we influence, which parts should we stay away from entirely?
We built a three-tier model that represents all the pieces of the OBI,
The first layer of the tier is the Open Badges standard. If you’re issuing an Open Badge, you’re relying on the standard to make the badge interoperable, transportable and verifiable. It’s the layer that all the other layers of the OBI rely on.
The second layer is libraries and tools that interact with the standard. Badge issuing libraries, validation libraries, badge bakers, tools that you download and install on your machine, or use as a dependency to build a bigger tool, fit in this layer.
Lastly, the top layer is userland. The marketplace. All the hosted services that interact with badge earners, with badge issuers and with badge consumers. It relies on the layers below it, and covers them up. A student earning a badge never knows that layers one and two exist, they just know that they received a badge and are storing it in their backpack.
Given the three layer model of the OBI, the Badge Alliance realized that it’s absolutely vital that we take a very active role in the maintenance of the first layer – the OB Standard, a less active role in the library layer, and a purely advisory role in the top userland layer.
Like all frameworks, it’s possible to find edge cases that break the model, but for most cases, it’s a solid way to judge what actions the BA should take in the maintenance of the OBI. Sunny and I will write more over the next couple of weeks about exactly how the BA will play in the three tiers.
The BA standard working group has had adding extensions to the OB assertion specification high on its roadmap this summer. We agreed that before we could add an extension to an assertion or Badge Class, we needed to add machine readable schema definitions for the 1.0 standard.
We experimented with JSON-Schema, then JSON-LD. JSON-LD isn’t a schema validator, it’s much more. It builds linked data semantics on the JSON specification. JSON-LD adds several key features to JSON, most of which you can play around with in the JSON-LD node module.
- Add semantic data to a JSON structure, link the serialized object to an object type definition.
- Extend the object by linking to multiple object type definitions.
- A standard way to flatten and compress the data.
- Express the object in RDF.
- Treat the objects like a weighted graph.
All of which are features that support the concept behind the Open Badges standard very well. At its core, the OB standard is a way for one party (the issuer) to assert facts about another party (the earner). The assertion (the badge) becomes portable and displayable at the discretion of the owner of the badge.
JSON-LD is also quickly becoming the standard method of including semantic markup on html pages for large indexers like Google. Schema.org now lists JSON-LD examples alongside RDFa and Microdata. Google recommends using JSON-LD for inclusion in their rich snippet listings.
We’ve been talking about JSON-LD on the OB standard working group calls for a while now. It’s starting to feel like consensus is forming around inclusion of JSON-LD markup in the standard. This Tuesday, September 2nd 2014, we’ll meet again to collectively build a list of arguments for and against the move. We’ll also discuss a conditional rollout plan (conditional in that it will only be executed if we get the thumbs up from the community) and identify any gaps we need to cover with commitments from the community.
It’s going to be a great meeting, if you’re at all interested in JSON-LD and Open Badges, please join us!
We’ve had “Backpack Federation” on the Open Badges roadmap for a long time. It’s always been the next thing we’re going to work on, but it continually gets pushed down the list by other high priority items. My goal in this post is to remove the “Federation” project from our roadmap entirely and focus on the features we mean when we say federation. Those features are absolutely within our reach, some of them are being worked on now, some of them are complete and in production.
What does “Federation” mean?
“Federation” just means distributed, with no central service that’s solely responsible for the maintenance or governance of the service. The internet is arguably the greatest example of a federated network. There’s minimal central authority; anyone can add a node to the network. Facebook is the opposite, a single entity controlling a large network of users and services. Facebook allowing users to post Tweets to their timeline counts as federation under some definitions of the word, but for our purposes, we’re talking about distributed systems without a central authority.
What do we mean by “Federation?”
We pack a lot of meaning into open badges federation, what we really mean is “distributed badge storage that gives users choice and opportunity to be discovered for their achievements.” Federation means more backpacks, more user choice and more user benefit. I’ve written more about federation in past blog posts, and even more about a world with more backpacks.
Some brief user stories help illustrate what we mean by federation,
- I earn a badge at my local public library and can put it into the Mozilla Open Badges Backpack, or onto my school’s backpack, or my backpack on my phone.
- A researcher gathers anonymous data through the distributed network of backpacks about the amount of time it takes to learn skills equal to an undergraduate math degree via free online courses.
- I want to learn how to research my genealogy, I find resources and badges online through a search in my backpack.
- A teacher can see the badges her students have earned over the summer, and associate them with common core standards she needs to teach this year.
- A teacher can find content and badges for his classroom that maps to common core standards.
- A teacher can associate a badge they didn’t create with a common core standard; letting her colleagues know that it’s a great alternative to the canon curriculum.
Let’s stop saying Federation
Let’s break down the scenarios above and give a rough idea of what needs to be built to satisfy the need.
I earn a badge at my local public library and can put it into the Mozilla Open Badges Backpack, or into my school’s backpack, or my backpack on my phone.
Our first pass at this feature was a prototype of a issuer api shim that stored your backpack of choice in the browser. It’s still viable, but we’re also thinking a lot about badge baking. A badge that includes metadata about what the badge represents inside the badge graphic, a “baked badge”, is a super portable badge. The current backpack concept requires that the earner “push” their badges into a backpack. By contrast, for years we’ve had an idea for a backpack that ‘pulls’ badges from an issuer; let’s pursue that. With a “pull backpack”, a lot of the burden of the Issuer API is taken from the Issuer. If they give a baked badge on their site, a “pull backpack” can suck it right up. Pinterest for badges!
We’re working on a prototype of a badge directory which focuses on indexing BadgeClasses (the definition of an earnable badge, instead of the BadgeAssertion, which defines an earned badge). If we extend the directory to allow for indexing of BadgeAssertions, backpacks could report earned badges to directory services. The directory services could share feeds of their indexed objects, acting as supernodes in a network of badge indexers.
A researcher gathers anonymous data through the distributed network of backpacks about the amount of time it takes to learn skills equal to an undergraduate math degree via free online courses.
Also solved by a network of badge directories.
I want to learn how to research my genealogy, I find resources and badges online through a search in my backpack.
The Mozilla Discover prototype demonstrates how we can use a directory service that includes explicit machine readable learning pathways to make it easy for learners to create their own learning opportunities. Just like the idea of indexing BadgeAssertions in addition to BadgeClasses, we should create a specification for a BadgePathway and index it in the network of Badge Directories. That specification work will happen in the Badge Alliance Open Badge Standard Working Group.
A teacher can see the badges her students have earned over the summer, and associate them with common core standards she needs to teach this year.
By creating “pull backpacks” (backpacks that gather badges instead of waiting for issuers to push them to them) we’re opening the door for specialized backpacks that cater to specific users – like school age children that need additional checks on their internet usage from guardians and school officials. Allowing a school to host a backpack makes it easier to tie out of classroom achievements with in classroom learning.
A teacher can find content and badges for his classroom that maps to common core standards.
The Badge Alliance Endorsement Working Group is considering methods to allow third parties to add information to a badge, without needing the badge issuer to change their BadgeClass definition or a badge earner to change the issued BadgeAssertion. Badge directories will play a key role here too, indexing these kinds of endorsements and making them available to badge consumers.
A teacher can associate a badge they didn’t create with a common core standard; letting her colleagues know that it’s a great alternative to the canon curriculum.
While it’s great to create an endorsement for a broad audience, we shouldn’t lose site of instances where metadata could be added a badge and shared inside a private group for a specific purpose. Directory services need to scale big, but there are use cases that need small specialized private directories as well.
So, what’s this all mean?
Kind of like the parable of the boiling frog or less gruesomely, my parable of getting a full meal out of a bunch of small plate appetizers, we’re going to meet the goals of federation without a specific project named “federation”. Federation is dead, baked badges, backpacks that pull badges, badge directories, pathways discovery and endorsement are the new distributed federation.
Lot’s of input for this post came from John and Carla. Thanks! Feel free to comment on this post below, or get involved with a Badge Alliance Working Group to keep the conversation going!
The specifications that make up the Open Badges Standard form the basis for the Open Badges Infrastructure; the collection of platforms and tools that make Open Badges possible. While the infrastructure has continued to grow, the standard has remained pretty stable over the last year. That’s not necessarily a bad thing, standards are standards because they’re stable. Despite its growth and reach, Open Badges is still a young project, there’s plenty of work to be done, so it’s time to start looking at the standard with a critical eye. Is it complete? What does it need?
Badge Alliance Standard Working Group is made up of organizations and individuals that ask those questions. We’ve worked together to evaluate the existing specifications and look for opportunities to improve and extend their reach.
The first issue we tackled was largely administrative. How do we function as a group? The Alliance built each working group with a chairperson, an Alliance liaison, and a cabinet the chair and liaison assemble. The Standard WG is a bit different, because we’re maintaining technical standards, we also decided we needed a more formal charter that explained how changes to the standard would be proposed, evaluated and accepted or rejected. We based the first draft on similar charters written by the W3C, and the Python Enhancement Proposal process the Python community created. The first draft of the BA-Standard WG charter is here.
The first task the group took on was to go back through the discussions on openbadges-discussion and pull out features that would make good candidates for discussion in the group.
It was pretty clear that the number one addition we all wanted to see added to the specification was a formal way to extend the assertion, both as a way to add information and as a way to experiment with future ideas.
We posted draft proposal to the openbadges-discussion, discussed, updated, discussed, iterated, and discussed some more.
We found that it was difficult to extend the schema if we couldn’t describe the schema in a machine readable way. We’ve put the extension specification on hold until we have a full json-schema representation of the 1.0 specification. After that, we’ll represent schema extensions in json-schema, most likely taking advantage of the json-schema ability to extend json-schema.
We expect the json-schema-fication of the 1.0 specification / schema by June 24th, and the extension specification by July 8th. After that, we need to sync up with the Endorsement Working Group and ask the difficult question, “After you issue a badge, is it mutable? Can we add information to it?”
How to get involved
If you’re an organization that relies on the Open Badges Standard, or if you’re just interested in schemas and specifications, we’d love your comments on all the above! Join the discussion on the BA-Standard WG Mailing List or join one of our bi-weekly calls.