add ceasing to credential status

[jeannekitchens]

WGU needs to be able to identify ceterms:ceasing with ceterms:credentialstatus.

https://credreg.net/ctdl/terms#lifeCycle_Ceasing https://credreg.net/ctdl/terms#CredentialStatus

[philbarker]

Long discussion about TeachOut vs Ceasing in issue #835, but so long as the credential ceasing through some other process that is not covered by teach-out then, yes adding ceasing CredentialStatus makes sense.

[siuc-nate]

How does WGU define it? I think this would be covered by TeachOut

[jeannekitchens]

Per WGU, they define it per the existing definition of ceterms:Ceasing - Resource is no longer active, current, ongoing, offered, operational, or available, except for participants who are already engaged with it.

[siuc-nate]

Long discussion about TeachOut vs Ceasing in issue https://github.com/CredentialEngine/Schema-Development/issues/835, but so long as the credential ceasing through some other process that is not covered by teach-out then, yes adding ceasing CredentialStatus makes sense.

What would an example be? I still don't see any practical difference between "TeachOut" and "Ceasing" - they both mean "this thing is ending, but people already doing it can finish"

[jeannekitchens]

Need to add https://credreg.net/ctdl/terms#lifeCycle_Ceasing and https://credreg.net/ctdl/terms#lifeCycle_Ceased to https://credreg.net/ctdl/terms#CredentialStatus. We constantly get complaints about "deprecated" being the only option for Credentials. There's a strong preference for "ceased." Let's look at the defintion for Deprecated and tweak it in away that we don't have to deprecate it. The issue is that deprecated, by defintion, means disapproval. We must make changes for Florida and SNHU has also requested to be able to use ceased.

Deprecated - Awards of the credential have ceased. Ceased - Resource is permanently no longer active, current, ongoing, offered, operational, or available.

[siuc-nate]

The issue is that deprecated, by defintion, means disapproval.

This surprised me. I have never seen it used in that way. Looking at the definition for it, I suppose that is technically true. However, I would counter that all of the usage examples when googling the term refer to the software/information technology usage (ie our usage) where it doesn't mean "disapproval" but rather "old, don't use it" (which is probably why I've never seen it used the way it's defined):

Anyway, the only definition that technically matters is our own: "Awards of the credential have ceased." Which covers "ceased" about as explicitly it possibly can.

We must make changes for Florida and SNHU has also requested to be able to use ceased.

No, they do not control our schema, or our definitions. We do. It would be rather chaotic if we left our terms up to all of our partners to control/manage/define/etc for us.

We need to remind our partners to look at the term definition, not the term label or URI, as the definition is the only part they should pay attention to when deciding what to use.

[philbarker]

Yes, "Deprecated" definitely has overtones of disapproval (it is the antonym appreciate in that sense):

Much as I would like to, we cannot expect everyone reading Registry description to read our definition of every term on the page, so we cannot expect people to understand terms in our special way. This is going to be really important if someone uses the Registry to check on what someone else's credential means. Which would you prefer, that they see your degree labelled as "Ceased" and understand it has stopped or that they see it labelled as Deprecated and understand it is disapproved of?

We should deprecate Deprecated and replace it with Ceased

We can make "Ceased" a synonym for our current Deprecated term and translate previous data accordingly by changing the prefLabel for Deprecated to "Ceased".

[siuc-nate]

Should we consider just throwing out the entire credential status type concept scheme and use the lifecycle status type scheme instead? Because if we make that change, then they are effectively the same scheme at that point.

[siuc-nate]

we cannot expect everyone reading Registry description to read our definition of every term on the page,

It seems like this justification comes up every time someone has a problem with one of our labels. We're not asking them to read every term on the page, we are asking them to read the definition for one concept, or at most, the handful of concepts in the credential status type concept scheme.

Either the definitions matter more than the labels or they don't. We need to decide which of the two matters more and stick with it.

[philbarker]

we are asking them to read the definition for one concept, or at most, the handful of concepts in the credential status type concept scheme.

Either the definitions matter more than the labels or they don't. We need to decide which of the two matters more and stick with it.

Especially when it comes to people consuming data from the registry we cannot expect them to read any definitions. We always seem to think of publishers supplying data, but more and more (I hope) we are going to have think about someone looking at data from the registry to, say, understand a credential that someone else is claiming. Labels and definitions both matter, what we cannot afford is labels that are easily misunderstood. What would an employer who knows that common dictionary definition think if someone applying for a job presented a credential that we say is "deprecated"?

We would throw out the entire CredentialStatus scheme. There is no need for a separate lifecycle scheme for Credentials. The main problem would be existing data. It would be far less problematic to change the prefLabel for credentialStat:Deprecated to Ceased:

Delete: credentialStat:Deprecated skos:prefLabel "Deprecated"@en-US .

Add: credentialStat:Deprecated skos:prefLabel "Ceased"@en-US .

And possibly, Add credentialStat:Deprecated skos:altLabel "Deprecated"@en-US .

[stuartasutton]

Phil's suggestion to change the skos:prefLabel is a good one as long as there is no assumption that the URI of a term is generated by concatenating the prefLabel to the base. This is one reason (probably among many) that very large vocabularies with lots of subtle conceptual variations (e.g., Library of Congress Subject Headings ([LCSH]))(https://id.loc.gov/authorities/subjects/sh90000352.html) use opaque URIs about which data generators moan and groan since no meaning can be read into the URI.

[siuc-nate]

We always seem to think of publishers supplying data, but more and more (I hope) we are going to have think about someone looking at data from the registry

I agree with this, and bring it up often. I am concerned we are making the schema too complex, but that is beyond the scope of this thread.

Labels and definitions both matter, what we cannot afford is labels that are easily misunderstood.

It would be far less problematic to change the prefLabel for credentialStat:Deprecated to Ceased

Unless the consumer is treating the property URIs as labels (as Stuart gets at), the HTTP lookup that gets them the actual label will also get them the definition (and the comment, and the usage note, and so on), so there is no difference in the work necessary (short of a few more eye movements I suppose) to read one vs the other (or both).

What would an employer who knows that common dictionary definition think if someone applying for a job presented a credential that we say is "deprecated"?

I don't know. What would an employer who knows the common IT-related usage of "deprecated" think when seeing that on a credential? If "deprecated" was the wrong term to use, how did none of us catch it when it was proposed?

We would throw out the entire CredentialStatus scheme. There is no need for a separate lifecycle scheme for Credentials. The main problem would be existing data.

Yes. @mparsons-ce what do you think of that idea? What kind of impact would it have on our publishing/importing/etc systems?

Changing the label to be different from the URI in a meaningful way such as this would break the pattern we've used across the rest of CTDL so far. I would rather deprecate the term and create a new one, but then that gets into the above issue of having two functionally identical concept schemes (which I would argue is a bigger complexity-related problem than needing to read a definition for one term).

[philbarker]

Unless the consumer is treating the property URIs as labels (as Stuart gets at), the HTTP lookup that gets them the actual label will also get them the definition (and the comment, and the usage note, and so on), so there is no difference in the work necessary (short of a few more eye movements I suppose) to read one vs the other (or both).

You're missing the point. I'm not talking about developers retrieving the definition files, I'm talking about users of sites and apps built to use that data. Look at what the Credential Finder displays for Credential Status: the label only. Realistically, no Finder user gets to see more than the label.

BTW, changing the label of credentialStat:Deprecated does not exclude introducing a new concept for Ceased and using that instead in the future or switching to a different concept scheme. It's just a way of dealing with what gets displayed for the current data.

[jeannekitchens]

Change the definition of ceasing with LifeCycleStatus and add Ceasing to CredentialStatus.

From: Ceasing - Resource is no longer active, current, ongoing, offered, operational, or available, except for participants who are already engaged with it.

To: Ceasing - Resource is in the process of becoming no longer active, current, ongoing, offered, operational, or available.

[siuc-nate]

The above changes have been made in pending CTDL and noted in the history tracking.

We will still need to review both the Credential Status and Life Cycle Status vocabularies to determine whether or not we should merge them, and if so, how to go about it.