Skip to end of metadata
Go to start of metadata

Specificatie 1.1

Wanneer we hier over Badges spreken, dan hebben we het over Open Badges, volgens de specificatie die initieel door Mozilla is ontwikkeld en nu verder wordt ontwikkeld door de Badge Alliance.

De huidige actieve, dus in gebruik zijnde, versie is 1.1 (Published: 1 May 2015) en is te vinden op: https://openbadgespec.org/history/1.1-specification.html

Specificatie 2.0
https://www.imsglobal.org/sites/default/files/Badges/OBv2p0/index.html

Op 31 december 2016 is de nieuwe versie 2.0 specificatie gepubliceerd. Deze nieuwe specificatie zit momenteel in de pre-implementatie fase. Dit wil zeggen dat er nog geen producten beschikbaar zijn die deze 2.0 specificatie ondersteunen. Wanneer dit wel het geval zal zijn is moeilijk te zeggen. Waarschijnlijk pas tegen het eind van 2017. Ondertussen wordt de 2.0 specificatie nog gefinetuned. Zie ook https://openbadgespec.org/

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.


De ontwikkelingen van deze 2.0 specificatie kunnen via GitHub gevolgd worden: https://github.com/openbadges/openbadges-specification

What has changed in version 2.0?

The following optional new features have been added:

  • Endorsements (#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)

 

De 2.0 specificatie is niet geheel compatible met de 1.1 versie. Dwz dat sommige functionaliteiten zullen breken en dus aangepast zullen moeten worden door de ontwikkelaars. Zelf zeggen ze dat dit minimaal is en dat dit voornamelijk optionele functionaliteiten zijn.

Is 2.0 backwards compatible?

Open Badges 2.0 contains a minimal set of breaking changes. 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. This is a summary of the 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)


Historie

In de praktijk zien we verschillende versies in gebruik: 0.5, 1.0, 1.1. Er zijn nog geen producten die de 2.0 specificatie ondersteunen. De commerciële producten ondersteunen over het algemeen de 1.1 specificatie, terwijl de open source producten slechts de 0.5 versie ondersteunen.

Zie voor de verschillen tussen de verschillende versies de volgende links:

  • No labels