- From: Snorre Lothar von Gohren Edwin <snorre@diwala.io>
- Date: Tue, 11 Jan 2022 13:38:53 +0100
- To: Phil Barker <phil.barker@pjjk.co.uk>
- Cc: public-vc-edu@w3.org, Deb Everhart <deverhart@credentialengine.org>, Stuart Sutton <stuartasutton@gmail.com>, Jeanne Therese Kitchens <jkitchens@credentialengine.org>
- Message-ID: <CAE8zwO0RkGcNbCVJwNB-Q-1LZmcYvcp7aUph4NWKuffgjNkx7g@mail.gmail.com>
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>*
Received on Tuesday, 11 January 2022 12:39:19 UTC