ceterms: Certification

[lfaulkner0328]

Through working with various partners around certifications for the retail and hospitality credentials initiative, there have been some questions about modifying/improving the definition of certification to include "revocation if not renewed" as a defining feature.

We'd want to explore further if this is commonly accepted across the certification community, but we know that NCAA/ICE/ANSI include revocation as an element of personnel certification when accrediting credentialing bodies against the ISO/IEC 17024 and NCCA’s standard. When you visit the website of certification bodies, you will see that many have a section on revocation or reference the ISO/IEC 17024 standard.

This post by Cynthia Woodley of Professional Testing was also referenced (as someone that is well respected in the certification and licensure community): https://www.proftesting.com/blog/2015/10/21/20151021what-is-certification/ In this post, she states: "certification belongs to the certifying body and can be taken away from the person if the person ceases competent performance, or for a host of other reasons (violation of code of ethics, failure to maintain certification requirements, failure to recertify, etc.)"

Examples of certifying bodies that clearly spell out revocation in their code of ethics: CompTIA: https://certification.comptia.org/testing/test-policies/continuing-education-policies/candidate-code-of-ethics Page 34 of PMI's certification handbook: https://www.pmi.org/-/media/pmi/documents/public/pdf/certifications/project-management-professional-handbook.pdf

I wanted to relay that this specific definition change was proposed for consideration: Time-limited, renewable credential awarded by an authoritative body to an individual for demonstrating the designated knowledge, skills and abilities (competencies) to perform a specific occupation, specialty or skill and can be revoked if not renewed, for a violation of a code of ethics (if applicable) or proven incompetence after due process.

Wanted to share this, I'm sure more research will be needed to confirm the adoption of revocation as a part of the definition.

[siuc-nate]

It's worth considering. However, we do want to keep the definitions fairly broad and rely on data published to define individual credentials more closely.

Of particular note here would be Revocation Profile, which specifically exists to cover all of the details of things someone can do (or fail to do) that result in having a credential revoked, and Renewal Profile, which covers the conditions (via ConditionProfile) one must meet in order to renew a credential.

Between these two profiles, we intend to capture anything that must be done (or avoided) in order to "keep" a credential. Any credential that has such requirements should be published with data in one or both of these profiles, and anything published without such data will be interpreted as not having such requirements - that enables us to cover certifications that do or don't strictly meet the definition you propose.

It also means that if we keep our current definition, we can still cover the cases where such certifications do have stricter requirements by ensuring that the relevant data is published via one or both of those profiles.

That's my two cents anyway.

[stuartasutton]

I agree with Nate above; however, if there is strong feeling here that this needs to be present, I'd suggest that it be included in a comment accompanying the definition:

DEFINITION: Time-limited, renewable credential awarded by an authoritative body to an individual for demonstrating the designated knowledge, skills and abilities (competencies) to perform a specific occupation, specialty or skill.

COMMENT: Certifications can be revoked if not renewed, for a violation of a code of ethics (if applicable) or proven incompetence after due process. Description of revocation criteria for a specific Certification should be defined using Revocation Profile.

Note: Error noted by Laura below corrected

[lfaulkner0328]

[This error corrected by Stuart]

I think that comment would be helpful to include as there is a strong feeling from the folks that I've been speaking with about revocation being a key component.

Our outreach and engagement with certification bodies will include an emphasis on including properties like renewal and revocation, but I think having it more front and center would really help those who aren't sure if they have a certificate or a certification be able to make a more informed decision that aligns with how the community is thinking about differentiating the two.

[siuc-nate]

+1 to Stuart's suggestion - I agree that we want to keep things that only might describe a given "thing" out of the definition for that thing. That's what the comments and usage notes are for.

We have "time-limited, renewable" in the definition for Certification because, in terms of how we conceptualize them, the only difference between a Certificate and a Certification is that a Certification is explicitly time-limited and renewable whereas a Certificate is (more or less) permanent.

[lfaulkner0328]

Seems like the comment beneath the definition would be sufficient.

[lfaulkner0328]

What would be the next steps for formally adding this comment to the definition?

And to follow up with Nate, I think what's being said here is that the other difference that people in the field are noting beyond "time-limited, renewable" is that it can be revoked or taken away, something unique to a certification and not a certificate (you can't revoke a certificate). That's why this is being raised.

[stuartasutton]

After discussion is complete, it needs to be scheduled for the next available release. The update will be in pending and go out to the TAG and others for review 2 weeks prior to finalization (i.e., off pending).

[lfaulkner0328]

We need to make a small but important edit to the comment @stuartasutton: COMMENT: Certifications can be revoked if not renewed, for a violation of a code of ethics (if applicable) or proven incompetence after due process. Description of revocation criteria for a specific Certification should be defined using Revocation Profile.

That previously said "certificate" instead of "certification"

[siuc-nate]

Action to be taken:

Add:

Subject: ceterms:Certification Predicate: dct:description Object: Certifications can typically be revoked if not renewed, for a violation of a code of ethics (if applicable) or proven incompetence after due process. Description of revocation criteria for a specific Certification should be defined using Revocation Profile.

Any objections?

[lfaulkner0328]

Can you share your thinking on adding the word "typically"?

Does this still mean that the addition is going to be as a comment?

[siuc-nate]

Yes, the change is to add a comment.

As for "typically", I am okay with leaving it out - but that means we're saying that all certifications, ever, can be revoked if not renewed (etc). - and if this is true, then there's no problem removing "typically". I am just weary of describing things too strictly, as that has bitten us before.

[stuartasutton]

I think "typically" should be included for the following reason. If a distinguishing characteristic of a certification is that it is valid for a specific period of time and then needs to be renewed for the person to remain certified, then there is no need for a revocation action since validity ends as a matter of law at the end of the prescribed timeframe. That does not mean that there isn't a custom of issuing a revocation. But why would there be a need to revoke if the validity of the certification ceased at the close of the prescribed period? So, leave in "typically".

[lfaulkner0328]

Makes sense to me! Do we need input from others more broadly?

[ParosGroup]

I might be late to the party here, but better late than never.
I think the issue is more, for me, about having consistency in the field about the actual definition, so as to ensure that we have things published as "certifications" that the major QA bodies who oversee them and the providers of certifications would also recognize those credentials as certifications. If we are making changes here to have alignment with the large field, I'm not sure why we wouldn't want to drive to a common definition of certification that could/would be used by us, ANSI, ICE, GeMENA, BLS, NBER, Census, etc.
I'd like to propose that CE co-convene a working group of experts on certifications to come up with a common definition, and get this universally resolved and consistent.

[jeannekitchens]

@ParosGroup you're not late to the party; you're just in time... See the Credential Engine namespace policy http://credreg.net/page/namespacepolicy and CTDL Review Process PPT at the top of the CTDL History page http://credreg.net/ctdl/release.

The Credential Engine has advisory group members with expertise in this domain who provided input to the proposed definition update, including members representing ANSI. The basis for terms related to "certification" is the International Standard ISO/IEC 17024. The terms map to common definitions used by other organizations such as those you listed.

Credential Engine organizes working groups around domains. Currently, we've convened a Pathways Work Group composed of subject matter and technical experts. Other current Credential Engine work includes development of best practices for CTDL based on types of credentials (e.g., certification). This work may provide the opportunity your suggesting for a working group, not just to look at one definition, but a best practice for a larger set of CTDL data to describe certification. Other team members may add their comments as well. Thanks for posting!

[siuc-nate]

Is the previously-indicated action still valid? https://github.com/CredentialEngine/vocabularies/issues/544#issuecomment-421162239

[lfaulkner0328]

We are holding on any changes to this definition until we involve a few others from advisory groups in the conversation.

[siuc-nate]

@lfaulkner0328 @stuartasutton @siuc-nate @cwd-mparsons @jkitchensSIUC @ParosGroup, per our 1-8-2019 meeting, this is a follow up to the indepth discussion for the purpose of addressing the need to have the best long-term solution for:

1. credentials issued to people
2. credentials issues to organizations for quality assurance

The request to have a new certification class for QA certifications issued to organizations caused the team to take a much closer look at the long-term need to ensure that as additional credentials for people and additional credentials for organizations for the purpose of QA are easily identified by publishing and consuming systems.

The discussion led to two diagrams with legends that show two potential paths forward. At the close of the meeting.

The technical team is going to re-review these options and use GitHub to refine the proposal.

These diagrams are saved in Google Drive https://drive.google.com/drive/folders/1DATSy7tFptB_7hQv1DePaqAEKBBLwJct

Option 1

Option 2

[stuartasutton]

I prefer option 2 since it makes the person/organization distinction explicit. The labeled arrows in both options define class and subclass relationships only and do not carry any other notions such as "For Individuals" or "For Organizations" (i.e., unlike arrows representing properties).

[jeannekitchens]

@stuartasutton when I posted the diagrams initially, I had to rename them and numbered the options. Take a look at the update I made. I may have messed up the intent of your reply. I think you're referring to the updated naming and numbering, option 1.

[stuartasutton]

@siuc-nate & @jkitchensSIUC:

To be a bit more explicit in my comment, switching from a hierarchy to tree structure, Option 1 actually looks like the following image where there is nothing hinting of the person/organization distinction.

Option 2 looks like the following and clearly (and formally) indicates the person/organization distinction.

[stuartasutton]

Jeanne, our posts here this morning crossed in transit :-). Yes, I did not notice the option numbering change :-(. SO, yes, your Option I here is correct as to preferred choice.

[jeff-grann]

Agreed we should update the certification definition to NOT reference organizations, but the proposed options seem a little heavy handed. Wouldn't these options necessitate a root-level change to all credentials to differentiate individual vs organizational? Could we instead support organizational certification by following the existing QA pattern of accredits, approves, regulates, & recognizes with a new "certifies"?

[stuartasutton]

No, Jeff, it would require no changes to any data...except perhaps a search of the current Certifications to gather up those that are organizational and changing their class reference.

[jeff-grann]

Ok, this is good news on the registry data and I see what you mean.

@stuartasutton What do you think about my "certifies" suggestion? I think we'd want to have consistent QA sub-class definitions so that every QA action could result in a corresponding QA credential, right? Also, in practice should QA organizations publish both a QA action and a QA credential?

[siuc-nate]

That may create ambiguity in terms of whether it refers to a ceterms:Certificate or a ceterms:Certification.

It's also possible that an Action class could simply point to the type of credential that it is an action for/about, e.g.

{
  "@id": "https://credentialengineregistry.org/resources/ce-thisActionRecord'sURI",
  "@type": "ceterms:CredentialingAction",
  "ceterms:instrument": "https://credentialengineregistry.org/graph/ce-theQACredentialApplied",
  "ceterms:instrumentType": "ceterms:Certification"
  "ceterms:object": "https://credentialengineregistry.org/graph/ce-orgReceivingTheQA",
  "ceterms:actingAgent": "https://credentialengineregistry.org/graph/ce-qualityAssuranceOrg"
}

Though one could argue that the type could also be determined by fetching the graph pointed to by ceterms:instrument in the above example. That would probably stick closer to the principles of linked data.

[stuartasutton]

Agreed..."stick closer to the principles of linked data"

[jeff-grann]

Ok, so are you saying that we do NOT need a corresponding QA action such as "certifies" for the proposed Quality Assurance Certification? I guess QAOrgs could just use the existing "approves".

[stuartasutton]

Jeff, as far as I am aware, we have used none of the "action" classes or properties for any purpose. We can afford to hold on this one.

[siuc-nate]

Per our 1/15/2019 meeting:

• Given a successful conclusion with the certification team on January 28th, we might schedule the changes to the definition for the February release. This would not include any changes to the model.

[siuc-nate]

What was the conclusion with the certification team? Per the post above, I need to know whether or not to do anything with the definition for this release.

[stuartasutton]

Nate, that group is meeting this AM (2019-02-08). There were 2 (good) comments on the names of the organization classes. Here's my take after the only 2 comments. (ignore the placeholder for military...they didn't see that). They will be advised this AM that changes to the credential classification model is a separate conversation from their task on refining the definition of Certification (for people).

[siuc-nate]

A quick googling suggests that "Industry Certification" is also used for credentials that people (among other things) can receive.

[siuc-nate]

I still don't understand why the type of entity that a credential is intended for should be encoded into the credential's class and not just made to be another property of the credential (perhaps a pseudo-vocabulary in the vein of ceterms:credentialType where the values are existing classes - likely subclasses of ceterms:Agent), e.g.:

{
  "@type": "ceterms:Certification",
  "ceterms:name": "Official QA Cert",
  "ceterms:intendedRecipientType": [
    "ceterms:CredentialOrganization"
  ]
}

{
  "@type": "ceterms:Certification",
  "ceterms:name": "Welding Certification",
  "ceterms:intendedRecipientType": [
    "ceterms:Person"
  ]
}

This allows for future expansion (credentials awarded to products, programs, assessments, learning opportunities, etc.) without doing anything to complicate the tree of credential types.

There is also no difference in complexity when it comes to querying for the data. Under the current proposal, you'd look for an industry certification like this:

{
  "@type": "ceterms:IndustryCertification"
}

Under the proposal I'm suggesting, the query would instead look like this:

{
  "ceterms:intendedRecipientType": "ceterms:CredentialOrganization"
}

[stuartasutton]

So, people have to fill in a property every time they handle this issue instead of handing it at the classification level...which makes as much sense as repetitively using a property.

[siuc-nate]

Just make it a required property.

[siuc-nate]

People have to fill in a property any time they want to define any aspect of a Credential - I don't see the issue.

[stuartasutton]

Ah, and that lessons the burden of repeated entry...

[siuc-nate]

Also, what happens when someone wants to publish a credential that isn't strict about who or what it's awarded to - say a badge for environmental responsibility or something? Any case where the publisher wants to offer a credential to both people and organizations, for whatever reason - we are gating them off from being able to do so by encoding that information into the type. Using a property (or even just leaving that property off for cases where it doesn't matter) would enable such a scenario.

[lfaulkner0328]

The Certification Working Group has expressed their support of the following revised definition of "certification."

Certification: Time-limited, revocable, renewable credential awarded by an authoritative body for demonstrating the knowledge, skills, and abilities to perform specific tasks or an occupation.

Meeting notes can be found here: https://docs.google.com/document/d/1hbEkd5oovGrTSiFVepdRLrA715W4kSPQOyNFt2Oig3I/edit

[lfaulkner0328]

Has this definition revision been incorporated into the next release? I thought this was moving forward but do not see it as "pending."

[siuc-nate]

Change to be made in the 3-1-2019 CTDL Release:

Remove:

URI: ceterms:Certification rdfs:comment: Time-limited, renewable credential awarded by an authoritative body to an individual or organization for demonstrating the designated knowledge, skills, and abilities to perform a specific occupation.

Add:

URI: ceterms:Certification rdfs:comment: Time-limited, revocable, renewable credential awarded by an authoritative body for demonstrating the knowledge, skills, and abilities to perform specific tasks or an occupation.

[siuc-nate]

These changes have been made and noted in the history tracking.