Roadmap and Maintenance

Roadmap and Maintenance of the Edubadges Metadata Model

This page explains who maintains the Edubadges Metadata Model, how changes are decided and what is planned.

Ownership and roles

Role	Who	Responsibility
Owner	SURF, Edubadges team	Publishes the specification, contexts and schemas; keeps them online; implements the model in Edubadges server; chairs the steering group.
Decision body	Metadata Steering Group — representatives of MBO, HBO, WO, the HO and MBO microcredentials pilots, and SURF	Approves, rejects or defers proposed changes to the model and to related functionality.
Contributors	Anyone: institutions, suppliers, standards specialists	Propose changes, review drafts, report errors. See Contributing.
Contact	[TBD: name/role or shared mailbox]	First point of contact for questions about the model.

Change process

Proposal ──► Triage ──► Steering Group ──► Draft spec ──► Review ──► Publish ──► Implement
 (issue)     (SURF)       (decision)      (wiki + JSON)   (public)  (new version) (server)

1. Proposal. Someone opens an issue with label metadata-change (template in Contributing).
2. Triage (SURF, within [TBD: e.g. 4 weeks]). SURF checks completeness, alignment with OB3/ELM/EU microcredential elements, and impact. Editorial issues are fixed directly.
3. Steering Group decision. Proposals are discussed at the next meeting. Outcome: accepted, rejected (with reasons), or deferred. The decision is recorded in the issue.
4. Draft specification. SURF drafts the change for pages 2 and 3 and the context, schema and example files, in a pull request or a draft wiki page.
5. Public review. The draft is open for comments for at least [TBD: e.g. 4 weeks].
6. Publish. The change is published as a new model version following Versions and Changelog, with migration guidance.
7. Implement. Edubadges server supports the new version in a release that is linked from the changelog.

Meetings. The Metadata Steering Group meets [TBD: e.g. quarterly]. Decisions are summarised [TBD: where — e.g. on this page under Decision log, or in the issue].

Roadmap

Items below are plans, not commitments. Dates are indicative and are reviewed by the Metadata Steering Group.

Now

• Adoption of v2 in Edubadges server and by institutions; migration of stored BadgeClass and Issuer metadata from v1. [TBD: target date]
• OB3 profile of the metadata model: finalising the mapping of the 17 extensions to native Open Badges 3.0 fields plus one Edubadges OB3 extension (draft).

Next

• ELM / Europass alignment: documented mapping from the Edubadges extensions to the European Learning Model, so that edubadges can be expressed as European Digital Credentials.
• eduCredentials: the metadata model as the content basis for eduCredentials, which supports OB3 and ELM and will replace Edubadges.
• Wallets: requirements from the Npuls eduWallet project, DC4EU outcomes and the EUDI Wallet.

Later

• Further alignment with sector agreements on microcredential quality and recognition (Npuls microcredentials programme).
• Review of the OB2-based model once Edubadges no longer issues OB2 credentials.

Lifecycle and maintenance commitments

• Edubadges and OB2. Edubadges keeps issuing Open Badges 2.1 with the v2 metadata model until [TBD: transition milestone to eduCredentials]. After that the OB2 model is frozen: no new versions, but contexts and schemas stay online.
• Availability of contexts and schemas. All published versions under https://api.edubadges.nl/extensions/ and the namespace https://w3id.org/edubadges/terms# remain resolvable for at least [TBD: e.g. the validity period of issued badges, or a fixed number of years]. If the host changes, the URLs are redirected.
• Namespace. The w3id.org/edubadges redirect is maintained by SURF via the w3id.org repository. [TBD: confirm]
• Errors in published versions are recorded as known issues on Versions and Changelog and fixed in the next version, because published files are immutable.

Decision log

Date	Issue	Decision
[TBD]	[TBD]	v2 of the metadata model approved