Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open Badges 2.0 #99

Merged
merged 35 commits into from Jan 1, 2017

Conversation

@ottonomy
Copy link
Contributor

commented Dec 31, 2016

This is a preliminary pull request to merge the 2.0 draft (see on staging server here) into master to publish it as the final recommendation of the Badge Alliance to hand over to the IMS Global Open Badges Working Group in 2017.

The Badge Alliance has collected feedback and proposals from over two dozen stakeholder organizations and compiled a number of desired use cases in mid-2016.

These use cases were prioritized by organizations and individuals who wanted to contribute to standardizing solutions to them in the Open Badges Specification and advanced to issues on this repository.

I worked with members of the BA Standard Working Group to draft a recommendation containing minimal breaking changes and a robust set of new features, putting Open Badges on a firm foundation for years of improvements to implementations as well as clearing the way to a better ability to experiment with the vocabulary and providing the tools for future updates to avoid breaking changes for even major improvements. For issuers, it will take minimal effort to move from v1.1 Open Badges to v2.0, as almost every change is optional, leaving the previous option intact. Issuers may then take advantage of the large number of new features as they fit with internal development roadmaps.

Optional new features:

  • Endorsement (#73, #76, #79)
  • Embed Criteria into a BadgeClass, including a rich (Markdown) text field, narrative. (#74)
  • Embed Evidence metadata into an Assertion, and connect multiple pieces of evidence through a narrative in Markdown text. (#84)
  • Embed Image information into Badge Objects, enabling greater accessibility of Open Badges. (#82)
  • Internationalization and multi-lingual badges are now available (#1)
  • Version control and references to previous/other versions of Badge Objects, specifically BadgeClasses. (#53)
  • Embed metadata about badge images (#85)
  • Award badges to identity types other than email with more explicit instructions (note: backpacks will continue to primarily support email, but we can move the market forward together with this framework) (#77)
  • Improved alignment to external frameworks and objectives (#81)

Breaking changes:

  • Linked Data in JSON-LD is now the official data model and syntax of Open Badges. This minimally affects issuers, who were already publishing v1.1 badges in JSON-LD, but all verifiers, backpacks, and displayers of badges must now explicitly perform a JSON-LD expansion/contraction operation to guarantee data integrity before further analysis of any object in the Open Badges context. This is a simplification from the hybrid approach introduced in v1.1 that required issuers to both use valid linked data properties and specific property names.
  • The AlignmentObject has been updated to use different terminology. Displayers will be asked to handle the new terms, which is now explicitly based on the schema.org/AlignmentObject class. "description" -> "targetDescription"; "url" -> "targetUrl"
  • BadgeClasses may now be embedded into Assertions, Issuers into BadgeClasses, and JSON-LD representations of Criteria, Evidence, and Images may now be embedded into fields that previously expected a URI string value. These new vocabulary classes improve portability, expressiveness, and accessibility of Open Badges. Optional for issuers.
  • VerificationObjects have been improved (#87, #80, #78). Hosted verification uses the id property, so verify.url duplication is no longer required or expected (#78). Signed badges are no longer required to discover a key from a url in the Assertion that signs them, closing a security hole. Instead, keys must be linked from the issuer Profile (#89).
  • RevocationList documents (used by less than 1% of issuers) are now published under an improved Linked Data class (#33)
  • Timestamps should appear in a consistent format (#86)

Timeline:

  • Minor adaptations to the 2.0 branch to reincorporate v1.1 in the history section for reference.
  • Pull request merged and 2.0 recommendation published to openbadgespec.org
  • January 2017: IMS Global officially adopts the Open Badges Specification as announced in October and uses this 2.0 Recommendation as the starting point of discussions in their new working group. The Badge Alliance activities pass the baton over to IMS Global and other organizations to carry Open Badges forward
  • Verifiers, backpacks and issuers begin to be updated to support the 2.0 Recommendation. Once 2 open source verifiers, 2 open source backpack providers, and at least 2 issuer platforms or applications are updated to support 2.0, we expect adoption to be considered final and 2.0 to be the official version of Open Badges.

Nate Otto
Director of Technology, Badge Alliance

ottonomy added 30 commits Dec 7, 2016
…ild" to create a build for local development and production. _config.yml adjusted for publishing of drafts on GitHub Pages.
…ocabulary:

* Add reference to IMS Global taking over the spec (still in progress)
* Update data classes
* Improve ordering of document structure
…ress. We'll use gh-pages to accommodate automatic publishing on Github instead of the 2.0 branch.
…ple, add favicon, add draft space for v2 context
…ll pass through all the data classes to update to 2.0 linked data assumptions
…sections) into alphabetical order
…anations for use in Issuer and Assertion
…cription of resources related to the spec.
…pts and terms. Not all references to v1 context have been removed at this time, because the semantic value of those extensions has not changed. Some further cleanup could be effected later.
… and provide examples.
…plest use cases. Includes compatibility warning for more complex uses. #1
…ting to a previous version.
@ottonomy ottonomy deployed to github-pages Jan 1, 2017 Active
@ottonomy ottonomy merged commit de9b7b5 into master Jan 1, 2017
1 check passed
1 check passed
github/pages GitHub Pages successfully built your site.
@ottonomy ottonomy referenced this pull request Jan 4, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
1 participant
You can’t perform that action at this time.