Belgian Badge Backpack

[@jeborsel]

Hi all, I am new to the Open Badges Community but would like to inform and ask for some help concerning an initiative we started in Belgium and which is powered by the company I work for Selor.

Selor is a federal government agency which is mainly responsible for the recruitment of Belgian civil servants (approx. 100.000 applicants are screened on a yearly basis, for public and private clients)

We decided to start up an OBI-compliant Belgian Backpack initiative to let candidates share their psychometric test-data with all stakeholders (public/private). 

In this we are also encouraging our stakeholders to share their own 'recognition for learning' data as well. 

And bring shared value to the badges we issue and recognize. 

Some concrete steps we already took:

- we started experimenting with badges and  issued our first badges as proofs of concept (with use of the API & an R script)

- presenting about open badges on different occasions (p.e. also on next EATP-conference) 

- gathering support and buy-in from different stakeholders (in this we also initiated talks concerning an existing authenticated central database of all Flemish educational diplomes issued from 2001 onwards, and for which we are exploring the possibility to open this database up by putting the ownership & control of this data in hands of the respectively diplome-earner and this with the help of open badges)

We also have setup a meetup-group which anyone is free to join, so please do if you are interested in bringing Open Badges to Belgium.

The next step we have initiated (but still seeking help on, that is why I opened this post here):

Hosting an own backpack for Belgian earners and tools for issuers to easily create and manage their badges.

For this we have made some budget available and had some first talks with people who could help us on this.

As with the meetup-group, we want also for the development and implementation part of our Belgian Badgepack from first early release onwards be open to community suggestions and support and will put all code in public github repository.

My questions:

- reading above, if you have suggestions/critics/thoughts, be free to let us know

- anyone who is willing to help us out with any of this or just is interested to know more , please do contact me or make yourself member of our Belgian Open Badges meetupgroup to be able to follow up on our progress and the meetups we organize 

- for the non-Belgians (like 99,5% of this community I guess ;-) ): are there any other already open available existing backpacks besides the Mozilla one?

 I know of Credly,  Pearson's Acclaim and the recently released Open Badge Passport of Discendum (who also made Open Badge Factory)  .. any others?

[Bob Price]

 I know of Credly,  Pearson's Acclaim and the recently released Open Badge Passport of Discendum (who also made Open Badge Factory)  .. any others?

One that is useful is Badger, it's an app that runs on Android and iOS. Links to backpacks or users can upload their own badges directly.

Details here: http://info.badgr.io/

Regards

Bob  

[Nate Otto]

Thanks, Bob --

@jeborsel, welcome to the Open Badges community. I'm excited to hear you've gotten started, and I hope you find many interested partners to work with in Belgium.

There are a number of issuing applications and platforms available. For several of them see https://www.badgealliance.org/badge-issuing-platforms/ . But there are fewer backpacks, especially open source ones. Bob mentioned the Open Badge Passport project, which I think is really close to releasing its first open source version. The others I know of are the Mozilla Backpack and Badgr.

I'm product lead for Badgr at Concentric Sky, and while we've had the iOS and Android apps for a while, we've now released a version for the web (badgr.io). By the end of July, the Android, then iOS mobile apps will get an update to sync with accounts on Badgr web, so you can use Badgr's sharing features. Since the web application is open source and can be installed on anyone's server, users of the mobile apps will have a chance to connect with their online account, no matter whether they prefer to sign up for that account on one of the open source instances or on https://badgr.io itself (our free hosted version of the service). Accounts on Badgr can both issue Open Badges and manage the badges they've earned (Essentially the same features as the Mozilla Backpack). (Today's update -- now you can organize badges into collections and share those via an access token link over email or social media. Our development roadmap is ambitious for the rest of the year (including starting to add translations so it's not just available in English), and we're excited to be adding new collaborators and partners every week). If you like working in Python/Django, feel free to take the Badgr code and use it (under aGPL license terms) as the base for your Belgian backpack, or I'd welcome talking with you if you want to see if we could work together to make sure Badgr meets your needs.

Feel free to reply with more questions about backpacks. This community has built up a lot of shared understanding over the last 3 years about what it means to work with badges as an issuer, earner or consumer. We'd love to have you and others you connect with in Belgium continue to take this understanding to the next level.

Nate Otto, Developer

concentricsky.com

[jeb sel]

Thanks Bob & Nate for this info.

@Nate, I will look into Badgr and the Badgr code and discuss with developers.

Definately interested..

As for our contribution to the Open Badges community. We would like to follow the advice I recently also saw in this literature review:

http://ucselevate.blogspot.be/2015/06/open-badges-trrying-to-see-forward-path.html

".. progress straight to a large scale pilot with top level institutional support."

We have used, and are still using our time this year for building up this institutional support in Belgium. Our network of both government, established universities as private players are involved in introducing this concept to the Belgian job market as a whole.

We will focus our efforts on bringing value to badges by accepting them as proof of skills and achievement,  like we now accept diplomas.  

Building up the critical mass, hoping to launch a 0.1 version in November and go from there further in 2016 on a large scale.

So will look into Badgr also and be in touch soon .

--
You received this message because you are subscribed to a topic in the Google Groups "OpenBadges" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/openbadges/_Bv1YHzigos/unsubscribe.
To unsubscribe from this group and all its topics, send an email to openbadges+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Charles Schultz]

Today I received a badge from Oracle via Acclaim (Pearson). My understanding of an "open badge" is that it is transportable, yet I am having trouble taking my badge with me - right now it seems my only option is to display it on Acclaim's website. Has anyone else had experience with Acclaim?

[Mark Mercury]

Hi Charles,

 

The idea behind badging technology is that all the information contained is valid / can be verified. For example, a badge should be able to tell you who it was issued to, when it was issued, when it expires, that it has not been revoked, etc. 

 

Currently, the Mozilla backpack does not offer "real-time" verification of the status of the badge. What this means is that Mozilla validates the badge when it is uploaded, but does not do so after the fact. As a result, if anything is updated on the badge (additional tags, evidence, expired, revoked etc..) after sharing to Mozilla, it is possible that people would not be aware of this. 

 

Real-time verification is essential for the clients we work with who are invested in building trust networks with their badge earners and other issuers. We fully expect the market to mature such that services like Mozilla will address this, but until then, we are not offering export / integration.

Mark Mercury

Product Lead - Acclaim

https://www.youracclaim.com 

[bernar...@gmail.com]

Charles,

Would you be willing to share a little more detail about the usage scenario and your client's needs? I think there might be a different design solution.

Regards,

Bernard 

Sent from my iPhone

You received this message because you are subscribed to the Google Groups "OpenBadges" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openbadges+...@googlegroups.com.

[Nate Otto]

Thanks for replying, Mark

Let's set up a call or event to talk about this. At MozFest next month, DigitalMe will be leading a session on maturing the Backpack. If the Backpack and associated validator are not serving the needs of issuer stakeholders.

The Badge Alliance would love to collaborate to ensure that all BA partners are indeed issuing Open Badges to recipients in their system. Especially those who promote their programs with use of the Open Badges brand. I agree with Bernard. We can solve this with targeted improvements to badge validation and display technology.

Nate Otto

Interim Director, Badge Alliance

badgealliance.org

[Nate Otto]

A technical note:

The Mozilla Backpack currently does record in its database the date a badge assertion was last checked for verification purposes, but it doesn't make this information available to viewers of the page (because there is no existing mechanism to trigger a re-validation, so it would only ever show the date a badge was added to a user's backpack.) 

Suggested feature:
1) Show the validation date in public-facing views of shared collections

2) Allow a viewer to trigger a re-verification if it's been more than 24 hours since the last verification date.

If this feature were implemented in the Backpack by mid-December, would Pearson be ready to allow export of Acclaim achievements as Open Badges?

Nate

[Charles Schultz]

First, my thanks to Mark Mercury for engaging us in this discussion. As Nate indicates, there is certainly room for more discussion. :)

Bernard,

I do not have a client. I earned a badge from Oracle Corp, which is handled by Acclaim. To be clear, I see myself as still learning about badges in general, and Open Badges in particular. So my questions are more because I am curious and trying to figure out how they are supposed to work.

Here is the badge in question (why talk about hypotheticals *grin*):

https://www.youracclaim.com/badges/8cdcf27d-b810-44ce-bd21-f7cfe034a612/public_url

There are a few interesting things about this badge.

For one, the badge itself was not issued in 2005; I passed a test which allowed me to be awarded the Oracle Certfiied Professional certificate in 2005. That certificate is the one and only "criteria" for the badge. The badge was awarded to me on October 20, 2015 (which I do not see mentioned on the badge webpage).

Another thing that is odd, the "skills" are basically keywords; however, the links link to labor market data, nothing about the skill itself. What skills are comprised in "DBA"? Heck, what skill is "Oracle"? :)

Next, as Mark implied (and as I learned via private email from another Acclaim representative), I cannot share the badge outside Acclaim. I cannot download the baked badge, nor import it into other systems. The points that Mark raise about a "trust network" are very good, and I would love to see more people talk about that.

Based on the Open Badge chats that I have participated in, there is quite a difference of opinion about who should be able to earn and issue badges. And trust is a huge part of the transaction.

I am confused about one point Mark made, though. What circumstances would cause a badge to be revoked? Forgery? If we are talking about recognizing accomplishments, then one does not lose an achievement. Or do they?

Again, I am not trying to be antogonistic. I truly want to learn.

--

Charles Schultz

[Mark Mercury]

Bernard,

The issue date that is shown in your badge is supposed to show the date when you were certified, not the date the badge was created. This way we're accurately reflecting the status of your certification and providing context to anyone viewing your badge. 

Some examples of why a badge would be revoked:

- earner was found cheating and the credential is no longer valid

- the wrong badge was issued to an individual

- the earner did not meet the criteria to maintain accreditation for the credential that is represented through their badge

Examples of replaced badges:

- badge earner name changes

- the effective dates of the credential are wrong

- additional evidence was added to the badge

These are also  examples of how instant, real-time verification can help provide trust and convenience for employers who need to verify credential status.

The skill tags are used to provide badge viewers a high-level understanding of the types of skills your badge represents. This falls in line with the open-standard which supports tags within the badge metadata. Te real-time labor market data is to show how those skills are being demanded in the labor market. this is new feature in Acclaim. The badge criteria section does support additional information URLs that the badge issuer can use to provide links to external pages that provide detailed descriptions of the programs and learning outcomes represented in the badge. this also something the open-standard supports.

[@jeborsel]

Hi Charles,

The issue that you are adressing about your open badge being transportable , is a recognasible issue and in my eyes maybe even essential for the succes of the Open Badges format.

I will try to explain my view on this. 

This is maybe a personal view, but at this moment it reflects the view of the project team and network who we are building a Belgian Badge platform with.

We are facing the same issues that Mark of Pearson's Acclaim describes.

Trust is an important factor for our network and stakeholders that are involved in this. This was even the main reason for us to decide to build a platform of our own.

Being a governmental organisation, there are even other aspects to that than the ones Mark describes.

Thus, although I differed personally from opinion, we decided to build a platform of our own (in stead of building together/further on others).

This for me raises another issue, with us building 'yet another platform'.

Are all of these platforms competitors to eachother ("trying to get the likes and badges of the most earners/issuers") or are they part of the same goal to "Badge the world" and build a big ecosystem of Open Badges?

Well if I look at the current state of the Badge Ecosystem, all of the platforms (Acclaim, Credly, OpenBadgefactory/OpenBadgespassport, Bestr, Badgr,...) they are all doing (maybe with different approach and to a different extent) great efforts for working together on that same goal.

They all add with their individual approach and effort to the wider spreading of the format of Badges.

Are they all perfectly interconnected? No, they are not (yet). Most of them are even very proprietary about their information and data (for which good reasons can exist)

Do they need to be perfectly interconnected? Well, I don't know but would like to cite some words of Chris McAvoy back in 2012: "We need a system for making all the backpacks in the world act like one giant backpack for the purposes of aggregation and discovery. This is a tricky one, but it will be super awesome when we’re done with it. Super awesome."

How do we in Belgium are planning to tackle the problem between building the trusted badge network (like Mark mentions) and being fully transportable (like Charles questions):

From a UI perspective we will have a webadress on which earners and issuers will have all the functionalities they need to build a trusted Badge network.

Like Pearson's Acclaim, both issuers and earners (and also the broader (Belgian) Job Market) will know that when seeing/earning/issuing badges on that webadress, they are verified by us.

We have a level of 'control' on the badges that are coming from, or are imported in our platform as long as they are in our platform.  So we can give trust levels to them, needed for our network to be able to adapt a system of Badges.

(in a way comparable of the needs of Acclaim and the clients they work with)

So from an UI perspective we are also building our platform like this. 

Both issuers as earners, are encouraged to use our platform and UI to create and store their badges.

And if they share them with others, we will encourage them to use public links (like the one from Acclaim that you posted Charles) or share them on Social Media (FB, Twitter LinkedIn) via our platform.

But that doesn't make the badge transportable yet.

Transportable is when you can take the badge out of our platform and put it in another platform (or just store it locally since the metadata is embedded in the file)

For us this is about ownership of data. 

In our philosophy the ownership of the badge (and the data linked to it) is a sort of shared ownership of the issuer, earner and platform it resides in.

Let me compare it with what Facebook does:

if you put a picture on Facebook, it still is your picture, but as long as it is on Facebook, there are things in Facebook's disclaimer that you should know about because it is maybe no longer only your picture.

You shared the ownership of the picture in a way with Facebook.

I believe that (even if it was Facebook itself that helped you create that picture of yourself), the individual always should have at least an equally control over his/her data as the organisation he/she choose to share his/her data with. 

(don't want to open a discussion on that one, but I guess everyone is aware of the fact that people don't read disclaimers and sometimes give organisations more control over their data as they would have liked to)

To get back to our Badge platform:

although it can give issues of reducing trust in our badges (because we loose 'control' over them), we will allow our earners to both import and export badges in and out of our platform.

(as also is integrated in the Mozilla Open Badge Backpack itself)

We haven't decided yet in what way we will interconnect with other 'backpacks' (via API's that exists) , but in any way, earners can download their badges with the metadata baked in, and like such they will be transportable to any platform that follows the OB standard and specifications. 

I agree fully with Mark that this can bring an issue of trust and I fully understand the decision of Pearson in this. 

But in-between solutions that we want to bring to the Belgian Job Market to tackle this, are:

-  bringing the verification process to the organisations self that are 'accepting' badges. (via API they can check if a Badge is valid , at the very moment that they want to 'validate' the badge in their process e.g. in a hiring process, a badge verification is included just before the interview phase)

-  giving  different 'values' to badges that are inside or outside of our platform. This can be the same badge, that is a 'trusted' badge when residing on our platform (on our URL), but we don't give the same trust to that same badge when it is not residing in our platform.

Would like to hear the remarks of the community on these 2 possible solutions.. because I guess these are also not without any problems.

But for us ,being able to import/export the badge , is essential to an ecosystem of Open Badges. 

Giving this control of the data to the earnes is in my eyes one the big strengths of Open Badges, compared with a system that uses plane certificate repositories with unique id, like e.g. Coursera does: https://www.coursera.org/signature/ .

Because what does Open Badges add to such certificate repositories:

- it brings standardisation to the format of constructing those certificates

- it brings interconnectability (and transportability) to them by the use of machine readable JSON-LD and API

To end this post (that has become longer than I planned to) I would like to give a link to a superb blogpost of Chris McAvoy, that gives a more broader view on the issue of transportability than mine which needs to take limitations of our local implementation into account (that blogpost also explains me mentioning Facebook here ;-) ):

http://chrismcavoy.org/2014/06/23/simplifying-open-badges-federation/

[Anh Nguyen]

Excellent post.

One thing I would point out though is as the issuing platform, you never really lose the value or control over your badges when they are hosted.  While other platforms make a copy of the data, they still know your platform is the source.  If we consider a high value use case like a employment badge verification service (== resume background check), such a service could and should verify against the original data from your system and not anywhere else in near real-time.  The transferability is more so the badge earner can use badges in ways not possible in your system, it shouldn’t be that the copy is stale and never synchronize again.

If we take this just a little bit further, it wouldn’t be all that difficult to create a push notification type service where 3rd parties could register endpoint and interests with you, and then you can notify them of updates if an assertion they synchronize with is revoked or changed. Hmm, now that I typed it, that probably should be an avenue of exploration for synchronizing data across the ecology...

Its only when badges are baked that it become static.  I haven’t really seen any reasonable use cases for baked/offline badges made by anyone yet.

Sincerely,

Anh Nguyen

@BadgeDiscovery

[Nate Otto]

Thanks for a thoughtful reply. I've highlighted the two possible approaches you suggest. The first of these two, portable badges that may be verified at any moment by a consumer are what the Open Badge specification promises. As Mark points out, some of our software doesn't yet deliver on that promise, which creates a disincentive for Acclaim's issuing platform to use the Open Badges specification. The solution to this inadequacy in consumer-facing software is to improve that software to make real the potential of Open Badges, not to reproduce the fragmented system of closed "digital badges" that exists outside our community.

Because the Backpack is an important piece of consumer-facing software in this ecosystem, let's act swiftly to implement a change that will allow Pearson to open its Acclaim platform to deliver the Open Badges functionality it advertises. (The Backpack's role gets slightly complicated because it is primarily a earner-serving piece of software but there is a lack of consumer-serving platforms, so many of the features required by consumers must be performed by the backpack. As Anh says, with Open Badges, verification is available to any consumer who has the right tools, but those tools have not proliferated widely enough in the community. Often, consumers only have the tools that the badge earners present to them, wrapping the badges -- in this case the Backpack's "collection" view.)

Mark, 

If the Backpack is updated to show the date of last verification and offer the ability to re-verify the badge on the spot to update any properties that may have changed, would Pearson then see any obstacles to turning on the Open Badges download or export features? We have an opportunity to make some significant changes to the Backpack in the next month, and your input could help it become the right thing.