search

w3c-ccg / vc-ed-models

https://w3c-ccg.github.io/vc-ed-models/
Other
9 stars 5 forks source link

Base Structure for activity/competence/achievement/involvement #38

Open anthonycamilleri opened 3 years ago

anthonycamilleri commented 3 years ago

Proposed base set of fields for any concept: conceptbasemeta

philbarker commented 3 years ago

I would like to have another go at explaining what I think is the problem with instance here (and why Concept and instance should be swapped).

Say Li and Nina both have Badges in Information Technology Life Cycle Support, but from different years. The badge is described in Credential Engine and has @id https://credentialengineregistry.org/resources/ce-4abc087a-1d38-42d0-a335-d9f55d24112 which being a 5* linked data bod I use in the VC. Making up some property names based on the model @anthonycamilleri suggests, the two graphs look like: Untitled Diagram-Li has a Credential + Nina has a Credentials

If I load these data into a graph in an RDF datastore, it stores triples not records, and it will recognize that the two credentials have the same ID, they are the same credential, and being nicely normalized it recognizes that it only needs one instance for data per entity, so it stores the data as: VCModels-Li and Nina have a Credential

This data is perfectly valid, nothing has changed, but there is no way of saying who get their Badge when. I have lost data.

One solution is to change the model so that the credential earned is an instance: VCModels-Li has instance of Credential

When this data is normalized by a triple store: VCModels-Li and Nina have instances

kimdhamilton commented 3 years ago

Resolutions:

kimdhamilton commented 3 years ago
Screen Shot 2021-04-19 at 8 40 59 AM

Guide:

kimdhamilton commented 3 years ago
Screen Shot 2021-04-19 at 8 30 35 AM
ottonomy commented 3 years ago

@kimdhamilton this latest diagram looks much more like "Option 2" from https://github.com/WebOfTrustInfo/rwot6-santabarbara/blob/master/final-documents/open-badges-are-verifiable-credentials.md rather than a structure more like "Option 1" which we were previously working from.

I am concerned somewhat that almost everything in the "Credential Instance" is duplicative of properties at the Credential level. Why bother adding this extra layer to the onion if we can express these properties at the Credential level without it?

kimdhamilton commented 3 years ago

@ottonomy: not sure if you heard my commentary, but credential instance may (will probably) go away entirely. This is a placeholder

I should repeat from the above: everything italicized is conceptual placeholders while working through the concepts

AdamJLemmon commented 3 years ago

A quick follow up from the 4/19 W3C call... it sounds like we are wanting an outer container structure to contain many credentials, where a credential may be a VC, OB, text string, pdf, etc. which I don't know VCs were designed for? Perhaps something closer to CLR or LER?

Otherwise perhaps a less duplicative claim name could work in the VC? Ie. the hasAchieved: []... transcript: []... arrayOfAccomplishments: [] being an array of the above credentials... or similar that maybe just doesn’t include the word credential and could still be stuck into a single VC containing an array of things about the subject or that the subject has completed… this may be overloading the use of a VC, curious to learn of other perspectives.

ottonomy commented 3 years ago

@kimdhamilton apologies if I pulled the discussion into any unproductive territories by discussing directly whether or not there should be an intermediate "Credential Instance" model that is part of the claim. This is the fundamental question that I have been wrestling with for a few years, but I see your point that separately, it is also useful to outline what the core necessary concepts are to each the "Credential Instance" and "Concept Definition" (whether or not we decide to use at times the Credential itself as the Credential Instance).

On that point, I don't see the need to have a separate "name" at the Credential Instance level. And I hope that we can together discover that there is not a need to ever distinguish between:

But there may be some use cases that make it useful to have a distinction here sometimes, justifying the inclusion of an additional onion layer in the model, at least in some circumstances.

Here's a summary of some use cases reduced to a single sentence. We may choose some of these to support explicitly through one or more credential schemas. We don't necessarily need to support them all through exactly the same schema, but I'd love to see us tackle the simplest first and solve them in a manner as close as possible to the VC Data Model base.

kimdhamilton commented 3 years ago

resolutions from 4/19 meeting