Add OpenBadges v3.0.0 context URL to registry.

[BigBlueHat]

Pulling from https://github.com/digitalbazaar/cborld/blob/main/lib/codecs/registeredTermCodecs.js#L30

---

Preview | Diff

[dmitrizagidulin]

Suggested change

	<td>https://purl.imsglobal.org/spec/ob/v3p0/context.json</td>
	<td>https://purl.imsglobal.org/spec/ob/v3p0/context-3.0.3.json</td>

I highly recommend we point to the latest.

[davidlehn]

From #15, it's unclear how we handle this situation. Which is why I only put in "reserved". I'd suggest holding off on this change for now until we have a better plan and process in place.

[BigBlueHat]

@dlongley @wes-smith is this the correct way to be handling these updates these days? or is there a better approach to take going forward?

[w3cbot]

This was discussed during the #json-ld meeting on 12 February 2025.

View the transcript

json-ld/cbor-ld-spec#22

<gb> Pull Request 22 Add OpenBadges v3.0.0 context URL to registry. (by BigBlueHat)

bigbluehat: this PR adds a context URL in the CBOR-LD registry
… Dmitri suggested to change from the version-less URL to the versionned one.

dlehn: aren't we moving away from the registry, for CBOR-LD?
… People may continue to use the old stuff, though...
… We need to refine how it is supposed to work.

bigbluehat: I'll ask Wes dans Dave Longley (who are most active on CBOR-LD these days) what they think of it.
… This should be a more general discussion.

pchampin: I'm uncorfortable with CBOR numbers pointing to URL with changing content.
… But we need to discuss this with Wes and Dave Longley.

---

[dlongley]

@BigBlueHat,

@dlongley @wes-smith is this the correct way to be handling these updates these days? or is there a better approach to take going forward?

I recommend we close this PR because the old global "Term Codec Registry" has been removed from the spec. The way to do this has changed and become more flexible and self-describing. The new spec includes a separate registry section that allows for the independent registration of entries that include fully customizable tables of URLs, contexts, and types for controlling semantic compression:

https://json-ld.github.io/cbor-ld-spec/#registry

These registration entries get an ID that is present in the CBOR-LD itself, identifying which entry is used with a particular payload, and creating a namespace to allow for reuse of small integer identifiers across entries.

We might add back an appendix in the future for legacy CBOR-LD implementations that used the old global table, but this would not include the change in this PR anyway.

[dmitrizagidulin]

The new spec includes a separate registry section that allows for the independent registration of entries that include fully customizable tables of URLs, contexts, and types for controlling semantic compression:

Er wait, so what does that mean for our use case? How do we add https://purl.imsglobal.org/spec/ob/v3p0/context-3.0.3.json to this new registry?

[dlongley]

@dmitrizagidulin,

Er wait, so what does that mean for our use case? How do we add https://purl.imsglobal.org/spec/ob/v3p0/context-3.0.3.json to this new registry?

Yeah, that's right (you use the new registry) and you just open a PR to pick an entry there. You can have an entire registry entry to yourself with whatever values you need for extra semantic compression for your particular use case. Of course, there's a goal to keep the registry small so if entries can be shared in certain domains / market verticals that's a good thing.

We'll be developing registry rules where we expect lower-level registry IDs (under some threshold, we're currently estimating 10,000) to be based on public specifications or similar (this is how the CBOR tag registry works), and higher numbers can be very flexible. The design is such that the registry IDs can large enough to accommodate more entries than can be sensibly created, but obviously we want a sane outcome. So there's some more governance here to be worked on.

So, opening a PR to grab a "provisional" entry somewhere in the 10K+ range would be fine right now I'd say.