Base Structure for activity/competence/achievement/involvement

[anthonycamilleri]

Proposed base set of fields for any concept:

[philbarker]

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:

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:

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:

When this data is normalized by a triple store:

[kimdhamilton]

Resolutions:

• Flip relationship per @philbarker's comments above
• Similarities/diffs withs Open Badges (Person, BadgeClass, etc)
• Status/expiration: at the outer layer, provide examples (change of status, types)
• Mutability of BadgeClass (hashlinks, inline data, etc)
• Duplicate terms at different levels
• Using "credential status" as pointer to latest version

[kimdhamilton]

Guide:

• Bold: required field
• Italic: conceptual or TBD

[kimdhamilton]

[ottonomy]

@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]

@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]

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]

@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:

• Credential.id and CredentialInstance.id
• Credential.issuer and CredentialInstance.organization
• Credential.evidence and CredentialInstance.evidence

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.

• As an issuer, I want to recognize achievement of the requirements of a Defined Concept/Defined Achievement that I have also authored. (This Defined Achievement may align to a skill, thus recognizing achievement of the skill indirectly)
• As an issuer, I want to recognize achievement of a skill (in a binary sense), where I have not defined the skill.
• As an issuer I want to recognize achievement of a Defined Concept/Defined Achievement that has been created by a different creator (for example a school is authorized to assert achievement of certain concepts that have been defined by its parent District)
• As a school district, I want to issue a transcript to a student, including many assertions of individual achievements that are also individually verifiable (and maybe I want to include some "structure" information about how these achievements relate to one another, making it more expensive to build a system that consumes this data in its full richness)

[kimdhamilton]

resolutions from 4/19 meeting

• flip relationship per @philbarker comments
  (Base Structure for activity/competence/achievement/involvement #38)
• discuss similarities & difference with OpenBadges (person,
  badgeclass, etc)
• status & expiration: at outer layer, provide examples
  (change of status, types)
• discuss mutability of BadgeClass (hashlinks, inline data,
  etc)
• duplicate terms at different levels
• using "credential status as pointer to latest
  version"