Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ceterms: Certification #544

Closed
lfaulkner0328 opened this Issue Sep 11, 2018 · 43 comments

Comments

Projects
None yet
6 participants
@lfaulkner0328
Copy link

lfaulkner0328 commented Sep 11, 2018

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

This comment has been minimized.

Copy link

siuc-nate commented Sep 11, 2018

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

This comment has been minimized.

Copy link
Contributor

stuartasutton commented Sep 11, 2018

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 comment has been minimized.

Copy link
Author

lfaulkner0328 commented Sep 11, 2018

[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

This comment has been minimized.

Copy link

siuc-nate commented Sep 11, 2018

+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

This comment has been minimized.

Copy link
Author

lfaulkner0328 commented Sep 11, 2018

Seems like the comment beneath the definition would be sufficient.

@lfaulkner0328

This comment has been minimized.

Copy link
Author

lfaulkner0328 commented Sep 12, 2018

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

This comment has been minimized.

Copy link
Contributor

stuartasutton commented Sep 12, 2018

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

This comment has been minimized.

Copy link
Author

lfaulkner0328 commented Sep 12, 2018

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

This comment has been minimized.

Copy link

siuc-nate commented Sep 13, 2018

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

This comment has been minimized.

Copy link
Author

lfaulkner0328 commented Sep 13, 2018

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

This comment has been minimized.

Copy link

siuc-nate commented Sep 13, 2018

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

This comment has been minimized.

Copy link
Contributor

stuartasutton commented Sep 14, 2018

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

This comment has been minimized.

Copy link
Author

lfaulkner0328 commented Sep 14, 2018

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

@ParosGroup

This comment has been minimized.

Copy link

ParosGroup commented Sep 19, 2018

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.

@jkitchensSIUC

This comment has been minimized.

Copy link

jkitchensSIUC commented Sep 19, 2018

@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

This comment has been minimized.

Copy link

siuc-nate commented Oct 16, 2018

Is the previously-indicated action still valid? #544 (comment)

@lfaulkner0328

This comment has been minimized.

Copy link
Author

lfaulkner0328 commented Oct 16, 2018

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

@siuc-nate

This comment has been minimized.

Copy link

siuc-nate commented Jan 8, 2019

@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
credential classes option 1 of 2

Option 2
credential classes option 2 of 2

@stuartasutton

This comment has been minimized.

Copy link
Contributor

stuartasutton commented Jan 9, 2019

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).

@jkitchensSIUC

This comment has been minimized.

Copy link

jkitchensSIUC commented Jan 9, 2019

@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

This comment has been minimized.

Copy link
Contributor

stuartasutton commented Jan 9, 2019

@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.
2019-01-09 core_entity_model_1

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

2019-01-09 core_entity_model_2

@stuartasutton

This comment has been minimized.

Copy link
Contributor

stuartasutton commented Jan 9, 2019

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

This comment has been minimized.

Copy link

jeff-grann commented Jan 9, 2019

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

This comment has been minimized.

Copy link
Contributor

stuartasutton commented Jan 10, 2019

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

This comment has been minimized.

Copy link

jeff-grann commented Jan 14, 2019

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

This comment has been minimized.

Copy link

siuc-nate commented Jan 14, 2019

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

This comment has been minimized.

Copy link
Contributor

stuartasutton commented Jan 14, 2019

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

@jeff-grann

This comment has been minimized.

Copy link

jeff-grann commented Jan 15, 2019

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

This comment has been minimized.

Copy link
Contributor

stuartasutton commented Jan 15, 2019

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

This comment has been minimized.

Copy link

siuc-nate commented Jan 15, 2019

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

This comment has been minimized.

Copy link

siuc-nate commented Feb 8, 2019

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

This comment has been minimized.

Copy link
Contributor

stuartasutton commented Feb 8, 2019

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).

2019-02-08 core_entity_model

@siuc-nate

This comment has been minimized.

Copy link

siuc-nate commented Feb 8, 2019

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

@siuc-nate

This comment has been minimized.

Copy link

siuc-nate commented Feb 8, 2019

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

This comment has been minimized.

Copy link
Contributor

stuartasutton commented Feb 8, 2019

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

This comment has been minimized.

Copy link

siuc-nate commented Feb 8, 2019

Just make it a required property.

@siuc-nate

This comment has been minimized.

Copy link

siuc-nate commented Feb 8, 2019

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

This comment has been minimized.

Copy link
Contributor

stuartasutton commented Feb 8, 2019

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

@siuc-nate

This comment has been minimized.

Copy link

siuc-nate commented Feb 8, 2019

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

This comment has been minimized.

Copy link
Author

lfaulkner0328 commented Feb 8, 2019

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

This comment has been minimized.

Copy link
Author

lfaulkner0328 commented Mar 1, 2019

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

This comment has been minimized.

Copy link

siuc-nate commented Mar 1, 2019

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

This comment has been minimized.

Copy link

siuc-nate commented Mar 1, 2019

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

@siuc-nate siuc-nate closed this Mar 1, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.