Convergence on Open Badges v 1.1 context w/ w3id.org redirects

Credentials Community Group,
(cc: Badge Alliance Standard WG)

Open Badges <http://specification.openbadges.org> are converging with other
open credential specs using the credentials vocabulary. The draft 1.1
specification has issuers publish badges as linked data

Manu pointed out two issues with a pull request to reference the Open
Badges context from the redirect service that was suggested for use,
w3id.org

Pull request: https://github.com/perma-id/w3id.org/pull/70
Open Badges draft 1.1 context:
http://specification.openbadges.org/1.1/context.json

The Badge Alliance needs to move forward with publishing a context file
soon so we can release products that use linked data and can make new
features available to badge issuers and consumers. There is one particular
feature, endorsement, that is in high demand in the community and is
waiting on this release.



The first issue with this context file that Manu mentioned was the "v1.1"
URL. He said the LD community likes to have only major version numbers
represented in contexts. New properties may be added, but the community
pledges to support existing 1.x properties until a v2 is created, even as
specs relying on the context may go through several minor versions.

This might be tricky for Open Badges 1.x though, because though the Badge
Alliance does intend to use contexts in this way (no breaking changes
through the 1.x series), the BA decided to use the context file for an
additional feature, one that intentionally would separate minor versions.
That is a JSON-schema based validation feature, where a context file
corresponds to a specific version and may provide one or more JSON-schema
that validate nodes by their class @type. Between 1.1 and 1.2, if new
properties are added to the context, they might be added to both 1.1 and
1.2, but if those properties represent a new requirement, it would only be
required in the JSON-schemas linked from the 1.2 version.

This approach to JSON-LD and JSON-schema is experimental, and it has an
unknown level of utility. It may fall by the wayside before the next major
version of Open Badges. Nevertheless, using the context to link to
validation schema is part of the proposed Open Badges 1.1 specification.
Alternatives such as forcing implementers to use an array of multiple
contexts (one for v1 and one for the minor version validation schema)
suffer from their own downsides, including that there are still
minor-version-named context files. The Badge Alliance is open to
alternative suggestions for a very short amount of time before the 1.1 spec
is frozen.



The second issue Manu identified with this pull request is that there is
already a https://w3id.org/openbadges/v1 context file which represents one
implementation of credentials and is incompatible with all versions of the
Open Badges specification. There are production systems relying on this
context being discoverable from that w3id.org URL, so a new context
representing the Open Badges spec cannot overwrite it. It may be confusing
to users who would look at a /v1.1 context and assume it was compatible
with a /v1 context when they actually came from different development
histories.



I'm looking for a solution that will be the best for Open Badges as linked
data in the short term (1.x series), as well as the long term, meaning I
want to settle on some term IRIs to use for the classes and properties that
make up badges that are stable until the point when a proposed Credentials
Working Group produces a recommendation. At that point, I would hope to do
what I can to push the Open Badges spec to full compatibility with that
recommendation.

I'm interested in the community's thoughts.

Looking forward to a bright future of standardized credentials,

*Nate Otto, Developer*
concentricsky.com