Re: The world of credential engine

Thanks alot for this feedback guys! Helps alot!

Im well versed in the VC and DID space, its just when it comes to a valid
structure of the education credential I have no one to discuss with :D
Its worth mentioning that im working on the African continent and we need
to provide learning as well as insight on how things can work.

All these works with standardization, Im trying to find examples of how
people have used the data models, in complex ways but all I find is this:
https://w3c-ccg.github.io/vc-ed-models/. Which dont hold that complex
models that I potentially want. Because examples explains how certain
combos have been used to build up the credentials.

F.ex right now, im trying to represent a simple course accreditation. What
that holds is some course info which is straight forward, but it also holds
certain modules that they have gone through.
These modules are not standardized as of now, but is something the issuers
have control over and I want to represent as flexible building blocks.
But from https://credreg.net/, I cannot deduct clearly how this can be
built up.
I have looked at: https://credreg.net/ctdlasn/terms/#CompetencyFramework,
with modules as https://credreg.net/ctdlasn/terms/#Competency.
But it was not clear to me how one build this up into a valid structure.
Also, what types of classes: https://credreg.net/ctdl/terms#classes that
can contain this framework.

If anyone has an example using https://json-ld.org/playground/ that would
be great!

Will the guidebooks help out increasing my learning around this?
https://credreg.net/ctdl/handbook

On Tue, Jan 11, 2022 at 5:59 PM Phillip D. Long <phil@rhzconsulting.com>
wrote:

> Dear Snorre: these are great questions, and you can see from the responses
> there are really knowledgeable people on this list who can help!  I have
> one comment to offer in reference to your question about what constitutes a
> verifiable credential and who defines them. There is the technical
> structure of a VC in JSON-LD format that the data model for VCs describes
> from the work done by W3C VC community (VC Data Model v1.1
> <https://www.w3.org/TR/vc-data-model/>). It describes what you can do,
> not necessarily what should do, for an educational VC.
>
> The data standards organizations like IMSGLOBAL (in the US primarily) or
> W3C VC-EDU, are working to apply the VC data model to the representation of
> credentials for the education community. IMSGLOBAL is currently working to
> represent the single assertion badge, OBv2.x, as a verifiable credential
> through their OBv3 Workgroup, of which Kerri and I on this thread are
> members.  Similarly they are working to move the Comprehensive Learner
> Record (CLR) that is intended to replace the structure of a transcript for
> a degree program, and extend it to enable it to carry information about
> single assertion accomplishments (aka badges), along with competency
> framework descriptors, into a structure that follows the W3C VC data model
> v1.1 rules. That effort is underway in the CLRv2 workgroup, and it
> leverages the single assertion OBv3 as an atomic building block for the
> CLRv2 transcript, as well.
>
> These standards bodies are providing a template for the more traditional
> expressions of credentials they issue, e.g.,  a degree, a certificate, or
> license, in interoperable representations that can be cryptographically
> signed to make them tamper evident. But as you noted, if you follow the
> general guidelines for the VC data model, you can create a VC of your own
> design, if there isn’t already a suitable existing domain-based standard to
> use.
>
> The VC-EDU task force of the W3C VC CCG is where this work is underway for
> education related credentials. IMSGLOBAL wants to be the standard for
> educational credentials and has filled that niche in the US prior to the
> emerge of VCs.  The ability to contribute to their standards development or
> even see the work in progress they do in their development requires that
> you pay to become a member of their organization. VC-EDU, on the other
> hand,  is open to anyone with an interest and their work is freely
> accessible and available during the development process, as well as
> thereafter. As Kerri Lemoie is the chair of that task force, and doing a
> great job the chief technical “cat herder”, I’m sure she along with all of
> us sharing thes interests would welcome you’re joining the effort underway
> there (https://w3c-ccg.github.io/vc-ed/)
>
> Cheers,
>   Phil
>
> *Phillip Long, Ph.D*.,
> T3 Innovation Network, LER Network Facilitator
> e:  <phil@rhzconsulting.com>phil@rhzconsulting.com,
> SNS: Twitter/Telegram @RadHertz
> LinkedIn: https://www.linkedin.com/in/longpd
> —
> *Senior Scholar, Georgetown University*
> Center for New Designs in Learning & Scholarship (CNDLS)
> e: pl673@georgetown.edu
> —
> *Open Software Fellow*
> Concentric Sky
> e: plong@concentricsky.com
> https://concentricsky.com/  <https://www.concentricsky.com/>
> —
>
> *RHz Consulting, LLC.*Inquire-Listen-Design-Prototype-Analyze-Repeat
> e:phil@rhzconsulting.com
> LinkedIn:http://www.linkedin.com/in/longpd/
> <http://www.linkedin.com/in/longpd/>
>
>
>
>
>
>
>
>
> On Jan 11, 2022, at 7:38 AM, Snorre Lothar von Gohren Edwin <
> snorre@diwala.io> wrote:
>
> This is fantastic feedback! Thanks.
> What is the best fora for similar questions to be discussed?
> Does it exist github foras or any discussion foras for VC edu space? Or
> just credential engine?
>
> I have some follow up questions on this now, if that is alright!
>
> On Tue, Jan 11, 2022 at 1:07 PM Phil Barker <phil.barker@pjjk.co.uk>
> wrote:
>
>> Yes, it should. One factor to be aware of is that there is a difference
>> in what is covered by Credential in Credential Engine compared to
>> Verifiable Credentials. Credential Engine describes the credentials (and
>> related things like learning opportunities, skills...) offered by
>> educational institutions, training organizations etc, whereas Verifiable
>> Credentials are about the credentials that an individual has. They are
>> closely related, and totally complementary, like different sides of the
>> same coin. You can think of VCs as equivalent to the piece of paper that
>> says someone has a degree, lots of people can have such a piece of paper
>> for the same degree; Credential Engine will provide a description of that
>> degree, of which there is only one. If you know the Open Badge standard,
>> Credential Engine aligns with the Badge Class, not the assertion that
>> someone has been awarded to badge.
>>
>
> Thanks for sharing, yeah that was why I was asking that they might go
> together as hand in a glow. But thanks for detailing.
>
>>
>> I have an example micro credential here in JSON playground:
>> https://tinyurl.com/3czurwnm
>>
>> Is this technically valid or who decides that?
>>
>> No, that's not valid. You have used ceterms:MicroCredential as a property
>> when it is defined as a class (so it must be used as a value for type).
>>
>> You need something more like:
>>   "credentialSubject": {
>>     "id": "did:web:matthew's_did",
>>     schema:hasCredential: {
>>       "type": "ceterms:MicroCredential";
>>       "ceterms:name": "Test micro",
>>       "ceterms:description": "This will describe the credential"
>>     }
>>
>>   }
>>
>> (NB: the merits of using of schema:hasCredential in a VC is the sort of
>> thing we need to discuss in this group)
>>
>
> Yeah I have seen that and was hoping it might be a fluke that it was used.
> To me it does not make much sence that a VC contains another container for
> a credential they have.
> The VC itself is a credential of a credential I have, I believe.
> So from my JSON-LD understanding, i can type something inside the
> credentialSubject, and it will understand what is the type, plus the parent
> type, credentialSubject fields.
> But since alot of these other data points have ID, we have a conflict, and
> need to wrap them into a container.
>
> But this example dont have a conflict and could technically be type
> defined at the root level of this credentialSubject, just as this example:
> https://tinyurl.com/2p9cydzp
>
> Or what is the history of hasCredential?
>
>
>>
>> Why do I have to use ceterms:name, infront of name when it is wrapped in
>> a micro credential type?
>>
>> Is that becaus the JSON-ld of https://credreg.net/, might not follow
>> same format when doing schema.org?
>>
>> I am not quite sure I understand your question properly. Do you mean why
>> do you need the "ceterms:" prefix? That identifies the namespace, so that
>> we know you mean the CTDL version of name not the schema.org or FOAF
>> version of name (not that there any real difference in this case). It's a
>> common requirement when JSON-LD builds on more than one vocabulary, see
>> section 4.1.5 of the JSON-LD spec,
>> https://w3c.github.io/json-ld-syntax/#compact-iris Often this is hidden
>> in the JSON-LD context file.
>>
>
> Yeah my questions might come from my lack of JSON-LD knowledge. So this is
> more JSON-LD question
> Again this example: https://tinyurl.com/2p9cydzp
> I thought by typing the credentialSubject, it would be possible to use the
> "childrens" types directly, like email and identifier.
> But that might be a flat hiearchy, and since email and identifier is
> directly available on schema.org, it has no relation to its type?
> And that everything comes from context, and if I want to have flatter
> attributes, I would have to explicitly define them like this example:
> https://w3c.github.io/json-ld-syntax/#example-using-vocabularies?
>
>
> --
>
> *Snorre Lothar von Gohren Edwin*
> Co-Founder & CTO, Diwala
> +47 411 611 94
> www.diwala.io
> <http://www.diwala.io/>
> *Stay on top of Diwala news on social media! **Facebook
> <https://www.facebook.com/diwalaorg>** / **LinkedIn
> <https://www.linkedin.com/company/diwala>** / **Instagram
> <https://www.instagram.com/diwala_/>** / **Twitter
> <https://twitter.com/Diwala>*
>
>
>

-- 

*Snorre Lothar von Gohren Edwin*
Co-Founder & CTO, Diwala
+47 411 611 94
www.diwala.io
<http://www.diwala.io/>
*Stay on top of Diwala news on social media! **Facebook
<https://www.facebook.com/diwalaorg>** / **LinkedIn
<https://www.linkedin.com/company/diwala>** / **Instagram
<https://www.instagram.com/diwala_/>** / **Twitter
<https://twitter.com/Diwala>*

Received on Wednesday, 12 January 2022 08:40:53 UTC