json-ld/cbor-ld-spec

Add Open Badges v3 context

davidlehn opened this issue · 6 comments

The 0x32 code added to cborld library in digitalbazaar/cborld#67 need to be added here.

cc: @dmitrizagidulin

@davidlehn - ah, right, forgot about that part.

The latest spec now points to a revision:

The one in cborld lib is:

Compare:

diff -u <(curl -s https://purl.imsglobal.org/spec/ob/v3p0/context.json) <(curl -s https://purl.imsglobal.org/spec/ob/v3p0/context-3.0.2.json) | less

There are important differences. What's the policy here? 0x32 and that mapping may have been used in practice, so likely should be added here. However, this table will get out of control if authors need a new id for every revision of their contexts. It may be that "3.0.2" is more like "4" in this case, so we can lock the older one and if a new id is requested for 3.0.2, then allocate it.

Submitted #22, but there's clearly a discussion to be had here given how versioning is currently done by OpenBadges--i.e. a new context file per minor point release.

There's a related open issue on the implementation side as well, fwiw: digitalbazaar/cborld#69

but there's clearly a discussion to be had here given how versioning is currently done by OpenBadges--i.e. a new context file per minor point release.

Yeah, the situation with @context versioning in general (OpenBadges is one of the first to run into it, but others will as well) is a bit rough. Specifically - there ARE no minor or patch releases, with contexts. Each change is a breaking change, and needs a separate URL (and sadly, separate CBOD-LD tag).

And now there's a 3.0.3. I think before too many changes go in we need more discussion on the plan and processes for handling ids. I think the original idea was the registry ids would be aimed at long lived resources. That's hard to know ahead of time, and we're already seeing obsolete ids here, and attempts to redefine them.

Agreed. This needs more than just a wee update. I mostly posted it to get this exact conversation started. 😁