In the previous post, we looked at the relationship between trust, Open Badges and blockchains. To paraphrase George Bernard Shaw, one could say: Open Badges and blockchains are two technologies separated by a common idea [trust].
To explore how Open Badges and blockchains could merge into a new technical object, my reasoning will pass through several stages. We will start with a BadgeChain that does not make any reference to the blockchain technology, then, step by step, we will describe the mutation of this initial object through the incorporation of new genes into its DNA — hoping that we will not have created a chimera!
BadgeChain take one: everything is a badge
To create something that looks like a BadgeChain, we need to link badges together; there are multiple ways this can be achieved:
- Indirectly: badges are “connected” through each individual issuer and earner. The issuer is a kind of “connector” between all the badges issued (and their earners), the earner is a kind of “connector” between all the badges received (and their issuers). Badges can also be connected through the alignment metadata, a list of objects describing educational standards — a property of the version 1.5 of the standard that has not been widely exploited.
- Directly: badges are literally linked to other badges. For example, an endorsement badge could use the address of the badge being endorsed as the identification for the earner of that badge.
As a chain invokes the image of a direct connection between its constituents, we will focus our attention on creating an environment where everything is a badge. There is a legitimate reason to use badges for everything: once we understand that a badge is a relationship (between an issuer and an earner), saying everything is a badge is not different from saying everything is relationships. Making everything a badge should make it as easy to play with them as it would be with Lego™ blocks.
NB: while I often use the Lego™ metaphor to describe the simplicity of Open Badges and how it makes it possible for educators to practice bricolage, if I am honest, in the depiction of the state of the badges as a Lego blocks, I should write:
- it is not possible to plug them together: square tubes do not match round studs (there are also oblong studs on half of the top and half the bottom is flat with no hollow parts)
- if you insist on building something with them, do not sneeze, or you’ll have to restart from scratch!
- when you discover that there is not much you can do with them, you read the manual and understand why there was a bag, a kind of backpack: it’s to carry them with you wherever you go to show your collection, to a[n] (probably uninterested or condescending) audience…
The next Open Badge standard should bring us closer to the conditions for Lego™ block-like badges, with matching tubes and studs. This should open the Open Badge ecosystem for some serious and rich play to take place (*).
In a world where everything is a badge, we could use badges for many different purposes: creating personal identifiers, linking to evidence, setting criteria for issuing or receiving a badge, etc. Some of these options are described in the table below.
In the picture above, the arrows elicit the links between the components of a badge. The green and purple badges are identifiers with the green badge being self-issued (self-referential). The Issuer of the yellow badge at the centre is the purple badge so the content of the Issuer metadata of the yellow badge contains the address of the purple badge. The Evidence metadata links to a blue badge that was issued by the issuer identified by the purple badge — it could be an observation of the learner’s performance, and the Evidence of the blue badge could be a video of the observation and the Criteria the narrative of the observation by the issuer.
There are probably better ways to connect badges together, but what we want at this point is not to decide on what is the best possible way to connect badges together but to explore the properties of chaining badges together: what are the properties of chained badges that badges placed in a bag do not have?
The properties of chained badges
Chained badges change the topography of the Open Badge landscape where issuers are currently at the summit of their Open Badge dominions. Chained badges are a means to put an end to the strong asymmetry between issuers and earners implemented in the original version of the Open Badge Infrastructure — surreptitiously underpinned by the formal education credentialing model.
By connecting badges together, we are creating interwoven threads of data, so starting from one person’s identifier in the network we are able to follow multiple paths that connect this person to all the other participants in the network, their relationships, knowledge and the artefacts produced. Chained badges create one global distributed database from where one can pull different threads, creating multiple narratives, from different points of view: individual, community, organisational, city and region.
Moreover, when looking at the picture above, we are looking at something that might speak to the ePortfolio practitioner. By connecting together pieces of information we are creating meaning and assembling the elements of a new artefact: a portfolio. Most of us are familiar with the action verbs associated with ePortfolios: collect, select, connect, reflect — BTW, those verbs do not describe a “sequence” as the collection could be the result of a reflection and conversely! Open Badges are a means to simultaneously collect and connect, while creating meaning providing the fuel for further reflection (and action!).
Until now, the understanding of the link between ePortfolios and badges is dominated by ePortfolios as a place to display Open Badges and the use of ePortfolios to earn a badge — this is particularly clear when practitioners oppose ePortfolios and Open Badges or see them as “complementary.”. In this perspective, the link between ePortfolios and Open Badges is mainly functional, not organic; they are treated as two different objects.
bee-badges for hive-portfolios
My proposal is that Open Badges and ePortfolios are not “complementary” loosely connected objects , but Open Badges are the substratum from which ePortfolios can grow organically, like a beehive out of the activity of the bees — bee-badges for hive-portfolios!
By providing a space where everything is a badge, we have also resolved the issue of interoperability: we render obsolete standards like IMS ePortfolio (hardly used) and LEAP2A (slightly more used) that are based on a fragmented vision of information systems, in particular the storage of data, something that is now challenged with the increased adoption of distributed ledgers (blockchains).
(*) Nate Otto commented on this point: “the Learning Pathways data vocabulary allows a data format that enables this. See https://usecanvas.com/ottonomy/learning-pathway-models-api/47JdBeSCqzKJ1v3H8Oswlo — which shows some “report style” syntaxes using this proposed vocabulary. The context is not build yet, but it is a data model that allows us to build nested hierarchies of the legos, and then to each lego, you may specify a relationship to suggested badges, earned Badge Assertions, etc.”
Follow Us