Support ctid and proper links to Credential Engine/Credential Registry

[kayaelle]

Badges may have entries in the credential engine where there may be more details about them and where they are searchable. In the engine, badges may be part of pathways too which are also searchable.

We should discuss how we can more directly link badges to the Credential Engine.

[ottonomy]

The highlight use case for this as I understand it is in the Achievement (BadgeClass) class, but Issuer/Profile may also be in scope.

[debeverhart]

Phil Barker has drafted worked examples to contribute to this discussion, so that OB 3.0 can support CTDL for context and types (within the badge) as well as references to the Credential Registry for additional data external to the badge. It's written up wrt VCs, but applicable to OB and CLR. Let us know what we can do to contribute to the discussion on this topic, and LOD in general. Thanks.
(note, this draft includes CTDL for organizations, credentials, competencies, programs, courses, and assessments)
CTDL_Registry data in VCs_OpenBadges_CLRs.pdf

Here is a public version of this document open for comments: https://docs.google.com/document/d/1Ei7uxTeLs_vQPtMpRPx4KVZ-nQ46ySUlXpF1nzhgJUM/edit?usp=sharing

[philbarker]

@debeverhart is that the document you meant to attach?

Also, I think that the issue here should have two parts: 1) how can CTDL provide terms that are useful in properly describing what an OB asserts; 2) whether this description should be in the payload of the badge or referenced in a registry.

Answer to 1 is that it does lots; answer to 2 will be a balance depending on context -- but it is quite feasible to have some information in the badge and a link to the rest on the registry.

[debeverhart]

@philbarker good catch, I corrected the doc uploaded

[kayaelle]

Thanks for the updates @ottonomy @debeverhart @philbarker

[longpd]

@philbarker @debeverhart Shouldn't this be extended to as a broader discussion about VC content and the balance needed to insure portability and efficiency in sharing VCs (via VPs) while retaining the context and broader meaning of the assertion, assessment, etc. accessible through LOD in the registry that would otherwise add unwieldy bulk to the VC?

[debeverhart]

@longpd yes, the document that @philbarker wrote is intended to cover those important aspects, providing meaningful contextualization for the data within the VC/OB/CLR as well as data available as LOD-- please comment/add to this doc

Here is a public version of this document open for comments: https://docs.google.com/document/d/1Ei7uxTeLs_vQPtMpRPx4KVZ-nQ46ySUlXpF1nzhgJUM/edit?usp=sharing

[amiller-ims]

OB 2.0 and on (CLR 1.0, CLR 2.0, and OB 3.0) use the schema.org AlignmentObject to link achievements, results, result descriptions, and rubric criterion levels to external frameworks including entries in the Credential Registry.

We should discuss how we can more directly link badges to the Credential Engine.

One way (Skill Assertions) is being discussed in issue #339. This work is in scope of the OB 3.0 Charter.

Adding CLR 1.0 Achievement attributes/properties to the new shared Achievement class is also in scope of the OB 3.0 Charter. This was a mostly mechanical process.

Shouldn't this be extended to as a broader discussion about VC content and the balance needed to insure portability and efficiency in sharing VCs (via VPs) while retaining the context and broader meaning of the assertion, assessment, etc. accessible through LOD in the registry that would otherwise add unwieldy bulk to the VC?

No. That is out of scope for OB 3.0/CLR 2.0.

I suggest relabeling this to ob_next. You can also make a formal proposal for a future rev of the spec. There is a template in the proposals folder.