Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add Open Badges v3 context #15

Open
davidlehn opened this issue Nov 3, 2022 · 6 comments
Open

Add Open Badges v3 context #15

davidlehn opened this issue Nov 3, 2022 · 6 comments

Comments

@davidlehn
Copy link
Member

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

cc: @dmitrizagidulin

@dmitrizagidulin
Copy link
Contributor

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

@davidlehn
Copy link
Member Author

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.

@BigBlueHat
Copy link
Member

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

@dmitrizagidulin
Copy link
Contributor

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).

@davidlehn
Copy link
Member Author

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.

@BigBlueHat
Copy link
Member

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants