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

Credential Status #568

Closed
jkitchensSIUC opened this issue Jan 17, 2019 · 42 comments

Comments

@jkitchensSIUC
Copy link
Contributor

@jkitchensSIUC jkitchensSIUC commented Jan 17, 2019

Currently, the options for "Status" are active, deprecated, superseded, and probationary. The Indiana Commission for Higher Education uses "active, eliminated, and suspended." Can we add eliminated and suspended as options? Related to Trello card https://trello.com/c/xqaPyJ1w/16-currently-the-options-for-status-are-active-deprecated-superseded-and-probationary-the-indiana-commission-for-higher-education-u

@siuc-nate

This comment has been minimized.

Copy link
Contributor

@siuc-nate siuc-nate commented Jan 17, 2019

At least one of "eliminated" or "suspended" may be the same thing as one of our non-active terms. Do they have definitions for these terms we could compare to the definitions for our terms?

@erafal10

This comment has been minimized.

Copy link

@erafal10 erafal10 commented Jan 18, 2019

Here's more information with definitions.

Jillian also pointed out that eliminated degrees might not have a URL; we may need to allow inactive/eliminated/superceded credentials not to have a link.

Suspended v Eliminated.pdf

@stuartasutton

This comment has been minimized.

Copy link
Contributor

@stuartasutton stuartasutton commented Jan 18, 2019

@erafal10, that's not possible. If an existing degree has been assigned the status of "eliminated", it must still exist (i.e., be referenceable by URI), since there will be resources that were link to it before it was "eliminated". Therefore, it can be denoted as eliminated in status and even point to what replaced it (if anything), but it can never simply be literally eliminated as a discoverable resource.

@erafal10

This comment has been minimized.

Copy link

@erafal10 erafal10 commented Jan 18, 2019

@stuartasutton I know the reference/URI in the Registry would still exist and be discoverable. But, credentialing organizations usually get rid of the information on their own websites when they eliminate credentials, so how would we handle data for this term (which is currently required): https://credreg.net/ctdl/terms/subjectWebpage. I think it would be confusing/misleading to point to a different credential, even if it's been replaced by something similar.

@stuartasutton

This comment has been minimized.

Copy link
Contributor

@stuartasutton stuartasutton commented Jan 18, 2019

Since we've not had to cross that bridge yet, I can only tell you what I assume an interface to the data would do. It would check the status of credentials and if one has been eliminated, it would be suppressed in it public views.

@stuartasutton

This comment has been minimized.

Copy link
Contributor

@stuartasutton stuartasutton commented Jan 18, 2019

@erafal10, sorry, I didn't answer all of the question. You are correct that the likelihood (whether good practice or not) that an organization will delete a page from the website when it eliminates a credential (or assessment or learning opportunity etc.). My take on the ceterms:subjectWebpage property in such a case is two-fold:

  1. the fact that the ceterms:subjectWebpage no longer points to an active/existing page should be automatically caught in scheduled, automatic link checking (we do do systematically link check, don't we?); and
  2. a page that shows us up in such a check as broken could be checked against the credential's status and the page automatically updated by removing the ceterms:subjectWebpagelink when the page has an "eliminated" status. If it does not show up in such a check, that means that the page is still live and should remain.
@siuc-nate

This comment has been minimized.

Copy link
Contributor

@siuc-nate siuc-nate commented Jan 18, 2019

I think the question @erafal10 is getting at is, since subjectWebpage is a required property, what do we do when there is no subjectWebpage to point at?

@stuartasutton

This comment has been minimized.

Copy link
Contributor

@stuartasutton stuartasutton commented Jan 19, 2019

Another reason the the minimum data requirements will ultimately have to take into account the fact that there are legitimate “exceptions”.

@siuc-nate

This comment has been minimized.

Copy link
Contributor

@siuc-nate siuc-nate commented Jan 21, 2019

Should subjectWebpage be required if available?

From the perspective of the system, the only factor that matters is whether or not something is required - that's where all the enforcement is. We do have some cases where one property or another from a set of properties is required; is there an alternative that could be used instead of subjectWebpage where that property or subjectWebpage could be required?

@stuartasutton

This comment has been minimized.

Copy link
Contributor

@stuartasutton stuartasutton commented Jan 21, 2019

(Sigh)...@siuc-nate are you suggesting that we go through a policy review process to change ceterms:subjectWebpage from "required" to "required if available"? Recall that we have a required data policy where any changes whatsoever trigger Board review.

@siuc-nate

This comment has been minimized.

Copy link
Contributor

@siuc-nate siuc-nate commented Jan 21, 2019

Wouldn't that be required anyway if we do anything to change the notion that subjectWebpage is 100% required in all cases? I am trying to work within the established system/patterns we use for other properties, but I'm open to suggestions.

@erafal10

This comment has been minimized.

Copy link

@erafal10 erafal10 commented Jan 23, 2019

I want to loop back to the question about adding "eliminated" and "suspended" to status. I added information about Indiana's definitions above. Is there anything else you need to know?

@siuc-nate

This comment has been minimized.

Copy link
Contributor

@siuc-nate siuc-nate commented Jan 23, 2019

Do you have direct definitions for those properties? The PDF compares them but does not define them.

For convenience, the text of the PDF is:

The two statuses are similar in that in both cases:

  • Students are no longer being admitted into these programs; and
  • Enrollment and degrees conferred data can still be reported for these programs in the annual CHEDSS submissions

The two statuses differ in that:

  • Students can be re-admitted into a suspended program after the institution submits, and the Commission approves, a request to change the status of the program through routine staff action from “suspended” to “active”
  • Students can no longer be admitted into an eliminated program; a full new program proposal must be submitted for a successor program to be re-instated under that CIP code and level

I would suggest that their "eliminated" is the same as our "deprecated":

credentialStat:Deprecated: Credential is no longer awarded.

We don't have a 1:1 analog for "suspended" as they appear to define it, though. The closest we have would be "probationary" but it isn't really a match.

So, unless their direct definitions suggest otherwise, let's add something like this:

URI: credentialStat:Suspended
Label: Suspended
Definition: Credential is not currently available, but may become available at some future point.

I am keeping the definition deliberately broad to avoid problems with over-specificity down the road.

@erafal10

This comment has been minimized.

Copy link

@erafal10 erafal10 commented Jan 23, 2019

That's all of the information I have about how Indiana defines the terms. Your solution seems right to me @stuartasutton. Can we perhaps add language to "deprecated" that indicates that it covers credentials that are eliminated? If not in the definition, perhaps in a comment or usage note?

@siuc-nate

This comment has been minimized.

Copy link
Contributor

@siuc-nate siuc-nate commented Jan 23, 2019

In my opinion, "Credential is no longer awarded" already covers credentials that are eliminated.

@erafal10

This comment has been minimized.

Copy link

@erafal10 erafal10 commented Jan 23, 2019

@siuc-nate Yes, I'm saying that eliminated and deprecated are synonymous (so, not saying we should add eliminated as a separate term) but that we should include a comment or usage note to "deprecated" saying that it includes eliminated credentials. The more precise we can be the better, and adding that information will help people publish accurately.

@siuc-nate

This comment has been minimized.

Copy link
Contributor

@siuc-nate siuc-nate commented Jan 23, 2019

I would caution that being too precise leads to schema bloat, as more terms must be added to cover cases that are outside the scope of overly-precise terms. That said, comment is non-normative, so as you suggest, we could add something there. I don't have a strong opinion on that either way.

Something like this perhaps?

URI: credentialStat:Deprecated
Comment: This also covers credentials that have been "eliminated", "removed", "terminated", etc.

@erafal10

This comment has been minimized.

Copy link

@erafal10 erafal10 commented Jan 23, 2019

That seems right to me.

So at this point the consensus is that we should propose adding the above comment to "deprecated" and adding

URI: credentialStat:Suspended
Label: Suspended
Definition: Credential is not currently available, but may become available at some future point.

I'll flag this for Scott and we can determine a review process for the change.

@siuc-nate

This comment has been minimized.

Copy link
Contributor

@siuc-nate siuc-nate commented Jan 23, 2019

The definition of suspended and comment for deprecated could probably use some wordsmithing - @stuartasutton do you have any thoughts on that?

@stuartasutton

This comment has been minimized.

Copy link
Contributor

@stuartasutton stuartasutton commented Jan 23, 2019

Sorry, this conversation got ahead of me. No, "elimination" and "deprecation" are not the same; and, if that is not clear, then we need to clarify deprecate. A good, straight forward definition of "deprecated" is (yes) Wikipedia:

In several fields, deprecation is the discouragement of use of some terminology, feature, design, or practice, typically because it has been superseded or is no longer considered efficient or safe, without completely removing it or prohibiting its use. It can also imply that a feature, design, or practice will be removed or discontinued entirely in the future.

So, I can have a deprecated credential that has set a warning to the public that it may not be considered in the future.

@siuc-nate

This comment has been minimized.

Copy link
Contributor

@siuc-nate siuc-nate commented Jan 23, 2019

That may be a more accurate definition of the word "deprecated", but our definition of deprecated (setting aside the word itself), goes well beyond "discouragement of use":

Credential is no longer awarded

In essence that means that it does not define (or matter) why the credential is no longer awarded - it simply states that it is not. Eliminated credentials are no longer awarded, whether data still exists for them or not.

@stuartasutton

This comment has been minimized.

Copy link
Contributor

@stuartasutton stuartasutton commented Jan 23, 2019

That why I said our definition needs consideration as incorrect.

@siuc-nate

This comment has been minimized.

Copy link
Contributor

@siuc-nate siuc-nate commented Jan 23, 2019

So something like this?:

URI: credentialStat:Deprecated
Definition: Credential may be awarded, but is not considered to be adequate, useful, and/or worthwhile to pursue, and may be eliminated in the future.
Usage Note: Deprecated credentials that have been superseded should use credentialStat:Superseded.

URI: credentialStat:Superseded
Definition: Credential may be awarded, but has been superseded by another credential.

URI: credentialStat:Eliminated
Definition: Credential is no longer awarded.

URI: credentialStat:Suspended
Definition: Credential is not currently awarded, but may become available in the future.

Notes:

  • I changed the wording to use "awarded" instead of "available" since our current definitions use "awarded"
  • I am including here an update to the definition of superseded in order to loosen it up and make it work with the updated definition/usage note of deprecated (specifically, I am removing the limitation that a superseded credential is "no longer awarded")
  • I am including a usage note for deprecated to clarify its usage:
    • We already have a "superseded" property
    • Stuart's wikipedia definition mentions that deprecated covers superseded, so this is an adaptation of that notion
@stuartasutton

This comment has been minimized.

Copy link
Contributor

@stuartasutton stuartasutton commented Jan 23, 2019

Getting close, Nate.

Slightly tangential, Superseded status leads me to wonder why we've not created a supersededBy property.

@siuc-nate

This comment has been minimized.

Copy link
Contributor

@siuc-nate siuc-nate commented Jan 23, 2019

I believe that functionality was covered, more or less, by ceterms:latestVersion - compare your credential's data to data returned by the latestVersion URI (specifically, compare the @id properties) and if it doesn't match, you know your credential is outdated and you know that it has been superseded by the data that was returned. If I remember right, we did it that way to avoid needing to update all past credentials any time a new credential was uploaded (latestVersion was intended to be a redirect like a PURL)

@stuartasutton

This comment has been minimized.

Copy link
Contributor

@stuartasutton stuartasutton commented Jan 23, 2019

The definition of Suspended needs to reference Active...i.e., a Suspendedcredential is one whoseActive` status has been discontinued for cause but may be reinstated when that underlying cause has been addressed.

@stuartasutton

This comment has been minimized.

Copy link
Contributor

@stuartasutton stuartasutton commented Jan 23, 2019

As for #568 (comment) Nate, no, a supersededBy property points to something next in a chain while latestVersion always points to the end of such a chain. In your example, the conclusion can be computed but is not inherent in the data (i.e., linked data).

@siuc-nate

This comment has been minimized.

Copy link
Contributor

@siuc-nate siuc-nate commented Jan 23, 2019

Apologies for the following open can of worms:

Consider the following situations:

  • The credential is still being awarded (active)
  • The credential is still being awarded, but isn't worth it (deprecated)
  • The credential is not being awarded, but could be in the future (suspended)
  • The credential is not being awarded, and never will be (eliminated)

In each of the above (arguably even "active"), the credential may also be superseded. This isn't a problem for systems that permit multiple statuses to be selected (e.g. a credential is both "deprecated" and "superseded") - which is also something beyond the scope of the schema, but which leads me to the following:

If we assume that a credential can have more than one status, we can simplify our definitions:

  • credentialStat:Active - Awards of the credential are ongoing (unchanged from the current definition)
  • credentialStat:Deprecated - Credential is not considered to be adequate, useful, and/or worthwhile to pursue, and may be eliminated in the future.
  • credentialStat:Suspended - Credential is not active due to some cause, but may become active once that cause has been addressed.
  • credentialStat:Eliminated - Credential is no longer awarded.
  • credentialStat:Superseded - Credential has been superseded by another credential.

Then a credential can be:

  • both "active" and "superseded"
  • both "eliminated" and "superseded"
  • both "active" and "deprecated"
  • both "deprecated" and "superseded"
  • all of "active", "deprecated", and "superseded"
  • just "active"
  • just "eliminated"
  • just "deprecated"
  • etc.

This does not preclude also adding a supersededBy property - though that leads me down yet another tangent: We should probably make an adjustment to the definition of previousVersion in order to clarify that it refers to versions of the same credential:

From "Version of the credential that immediately precedes this credential."
To "Version of the credential that immediately precedes this version."

Otherwise that would suggest that "supersededBy" should really be "nextVersion", e.g.:
"Version of the credential that immediately follows this credential" - which is somewhat confusing.

In other words, I want to avoid a graph that looks like this:

Credential A.1 -supersededBy-> Credential A.2 -supersededBy-> Credential B.1
Credential A.1 <-previousVersion- Credential A.2 <-previousVersion- Credential B.1 

and instead have a graph that looks like this:

Credential A.1 -nextVersion-> CredentialA.2 -supersededBy-> Credential B.1
Credential A.1 <-previousVersion- Credential A.2 <-supersedes- Credential B.1

where it's clear that "version" means "version of the same credential (same CTID)" and "supersedes/supersededBy" refers to "distinct, entirely different credentials (different CTIDs)"

The usage of "version" as outlined above will be largely irrelevant in the registry, but could be useful elsewhere (e.g. URIs that have a datestamp attached to them, as seen in CASS).

Some of this should probably be separate github issues, but it all does kind of go together.

@stuartasutton

This comment has been minimized.

Copy link
Contributor

@stuartasutton stuartasutton commented Jan 23, 2019

Nate, before we go any further, I (we) need some clarification around the current "version" properties and their relationships to a credential's ctid:

latestVersion: Latest version of the credential.
previousVersion: Version of the credential that immediately precedes this credential.

How are these being used by CER technical and data infrastructure (envelop etc.)?

@siuc-nate

This comment has been minimized.

Copy link
Contributor

@siuc-nate siuc-nate commented Jan 23, 2019

@cwd-mparsons and @science can answer this better than I can, but I don't think we do anything special with them in terms of the registry. They're treated like any other normal URL properties in the editor, and the registry infrastructure uses a mechanism entirely separate from CTDL to handle version management for a single CTID.
image

Take a look at the node_headers property here: https://credentialengineregistry.org/envelopes/35deafa0-e5de-4747-96a3-631f18f5dde1
Within it you'll find a revision_history property that is an array of references to previously-published envelopes for this record's CTID. Within each reference is a url property that will let you pull that specific envelope. The head property will show true for the record that is the latest one.
image

If I recall correctly, this was done for a few reasons:

  • To ensure a clean separation between payload data (the stuff in CTDL) and registry infrastructure data (the stuff in the envelope)
  • To avoid confusion about what data goes where and allow the envelopes to work independently of CTDL if and when needed.
  • To enable the envelope's URL to always be present, accurate, well-formed, and up to date (without relying on the publisher of the data to do anything extra) by updating the revision_history data any time a new record for that CTID was published (doing this in the envelope avoids the issue of modifying the payload and breaking the signatures)
  • To enable publishers to put their own values into those "version" fields in the payload to point at their own PURLs or other such URLs.
@stuartasutton

This comment has been minimized.

Copy link
Contributor

@stuartasutton stuartasutton commented Jan 23, 2019

Nate, a few starting points:

  1. The superseded type should be dropped as a status (it's not);
  2. A credential can have only one status;
  3. A supersededBy property should be added; and
  4. A nextVersion property should be added;
  • Remove superseded type: Superseded is not a status of a credential but rather an indication of a relationship that holds between it and another credential.
  • Single status: None of the examples you give above of a credential with multiple states make sense. First eliminate all those with a second status of superseded since it is no longer a type but rather a relationship between two credentials. A credential can't be both active and deprecated because the two notions are orthogonal. That exhausts the options.
  • Add supersededBy: You rightly distinguish between a (currently non-existent) nextVersion property and a (currently non-existent) supersededBy property which indicates a superseding entity that replaces, but is not a next version of that which it replaces.
  • Add nextVersion: We should be able (via links) to advance forward and backward from a credential versions.

This issue now has 2 different threads: (1) changes to properties; and (2) changes to concepts in the credential status concept scheme.

@siuc-nate

This comment has been minimized.

Copy link
Contributor

@siuc-nate siuc-nate commented Jan 23, 2019

My intent with combining "active" and "deprecated" was to handle this part of the wikipedia definition:

without completely removing it or prohibiting its use.

by enabling you to express that "The credential can still be earned, but it will go out of use soon, so earning it is not recommended" (active and deprecated - which only makes sense using the simplified definitions I outlined above, where the only ones that indicate whether or not a credential can still be earned are "active" and "eliminated", hence the need to combine statuses). Without superseded being a status, the justification for that whole tree of thinking does fall flat.

So, if I am correct, this is where we are at in terms of our goals:

Create ceterms:supersededBy

URI: ceterms:supersededBy
Label: Superseded By
Definition: Credential that replaces this credential.
Comment: For example, a credential that outright replaces the credential being described, and is not simply a newer version of the same credential (the two credentials have different CTIDs).
Domain: ceterms:Credential (and subclasses)
Range: ceterms:Credential (and subclasses)

Create ceterms:supersedes

URI: ceterms:supersedes
Label: Supersedes
Definition: Credential that this credential replaces.
Comment: For example, the credential that is outright replaced by the credential being described, and is not simply an older version of the same credential (the two credentials have different CTIDs).
Domain: ceterms:Credential (and subclasses)
Range: ceterms:Credential (and subclasses)

Create ceterms:nextVersion

URI: ceterms:nextVersion
Label: Next Version
Definition: Version of the credential that immediately follows this version.
Domain: ceterms:Credential (and subclasses)
Range: ceterms:Credential (and subclasses)

Update the Definition of ceterms:previousVersion

From: Version of the credential that immediately precedes this credential.
To: Version of the credential that immediately precedes this version.

Create credentialStat:Eliminated

URI: credentialStat:Eliminated
Label: Eliminated
Definition: Credential is no longer awarded.
In Scheme: ceterms:CredentialStatus

Create credentialStat:Suspended

URI: credentialStat:Suspended
Label: Suspended
Definition: Credential is not active due to some cause, but may become active once that cause has been addressed.
In Scheme: ceterms:CredentialStatus

Update the definition of credentialStat:Deprecated

From: Credential is no longer awarded.
To: Credential may be awarded, but is not considered to be adequate, useful, and/or worthwhile to pursue, and may be eliminated in the future.

Deprecate credentialStat:Superseded

From: vs:term_status vs:stable
To: vs:term_status vs:deprecated

The end result of which will be:
4 properties related to connections between nodes:

  • previousVersion (updated)
  • nextVersion (new)
  • supersededBy (new)
  • supersedes (new)

A revised credential status concept scheme:

  • Active (unchanged)
  • Probationary (unchanged)
  • Deprecated (updated)
  • Eliminated (new)
  • Suspended (new)
  • Superseded (removed)

I'm open to suggestions for wordsmithing and whatnot, particularly for the comments (which might be better as usage notes?) on supersededBy/supersedes.

One slight RDF question regarding our policy of not breaking systems and how definitions relate to URIs: in the above example, the definition for credentialStat:Deprecated is being dramatically altered, and its existing definition is essentially being moved to a new URI (credentialStat:Eliminated). Does this present a problem we need to worry about? I suspect that few if any published credentials will already have a deprecated status - but I did want to mention it in case someone asks about it later.

@philbarker

This comment has been minimized.

Copy link

@philbarker philbarker commented Jan 24, 2019

On the definition of credentialStat:Deprecated, I would not emphasise that the credential may still be awarded by putting that information upfront. I think it would be better to switch the order:

credentialStat:Deprecated

Credential is not considered to be adequate, useful, and/or worthwhile to pursue. It may still be awarded, but may be eliminated in the future.

@jeff-grann

This comment has been minimized.

Copy link

@jeff-grann jeff-grann commented Feb 11, 2019

Credential Engine's Higher Education Advisory Group discussed this issue on 2/8/2019. The documented consensus from the group was to "Replace deprecated with the term eliminated. +2". One person mentioned that it would be confusing to choose between these 2 terms. No additional credential status concepts were identified.

@siuc-nate

This comment has been minimized.

Copy link
Contributor

@siuc-nate siuc-nate commented Feb 11, 2019

@jeff-grann Thanks, but we still need to accommodate cases where the notion of "deprecated" applies. Did they offer anything that might help clarify the difference? Ultimately it comes down to "you can get it, but you probably shouldn't" vs "you can't get it at all".

I suppose that "active" and "superseded by [other credential]" together might be comparable? Though that also assumes there is another credential to point to, and that the publisher is willing to publish such information.

@stuartasutton

This comment has been minimized.

Copy link
Contributor

@stuartasutton stuartasutton commented Feb 11, 2019

Well, we should go with the advice of the HEAG and just deprecate "deprecate". If it is too subtle a difference for this HEAG to grasp, it's likely too subtle to be used meaningfully.

Do we have a way of checking whether it has been used at all (doubt it) in the current Registry data? That, of course, does not mean it has not been used in the wild...but deprecating "deprecate" does not break anything.

@siuc-nate

This comment has been minimized.

Copy link
Contributor

@siuc-nate siuc-nate commented Feb 11, 2019

There are six:
Use https://credreg.net/quickstart/queryhelper and this query to find them:

{
	"ceterms:credentialStatusType":	{
		"ceterms:targetNodeName": "Deprecated"
	}
}

(Note that we're still working on resolving an issue with the registry's search index that will enable using "ceterms:targetNode": "credentialStat:Deprecated" instead of the above query within the Credential Alignment Object, but for now just use this)

It's possible that "eliminated" applies to them; I haven't looked much more deeply than that.

@cwd-mparsons

This comment has been minimized.

Copy link
Member

@cwd-mparsons cwd-mparsons commented Feb 11, 2019

You can also see these in the credential finder:
https://credentialfinder.org/search?searchType=credential&filters=39-2250

@siuc-nate

This comment has been minimized.

Copy link
Contributor

@siuc-nate siuc-nate commented Sep 17, 2019

Per our 9/17/2019 meeting:
We will move forward with the changes outlined in this post:
#568 (comment)

@cwd-mparsons

This comment has been minimized.

Copy link
Member

@cwd-mparsons cwd-mparsons commented Sep 18, 2019

There are nine credentials with a status of superseded.
{
"ceterms:credentialStatusType": {
"ceterms:targetNodeName": "Superseded"
}
}
Vincennes has 7, and 1 each for Participate and PECB.
What should guidance be given to the partners regarding changing the status?

@siuc-nate

This comment has been minimized.

Copy link
Contributor

@siuc-nate siuc-nate commented Oct 8, 2019

Per our 10-9-2019 meeting:

Create ceterms:supersededBy

URI: ceterms:supersededBy
Label: Superseded By
Definition: Resource that replaces this resource.
Comment: For example, a credential that outright replaces the credential being described, and is not simply a newer version of the same credential (the two credentials have different CTIDs).
Domain: ceterms:Credential (and subclasses)
Range: ceterms:Credential (and subclasses)

Create ceterms:supersedes

URI: ceterms:supersedes
Label: Supersedes
Definition: Resource that this resource replaces.
Comment: For example, the credential that is outright replaced by the credential being described, and is not simply an older version of the same credential (the two credentials have different CTIDs).
Domain: ceterms:Credential (and subclasses)
Range: ceterms:Credential (and subclasses)

Create ceterms:nextVersion

URI: ceterms:nextVersion
Label: Next Version
Definition: Version of the resource that immediately follows this version.
Domain: ceterms:Credential (and subclasses)
Range: ceterms:Credential (and subclasses)

Update the Definition of ceterms:previousVersion

From: Version of the credential that immediately precedes this credential.
To: Version of the resource that immediately precedes this version.

Create credentialStat:Suspended

URI: credentialStat:Suspended
Label: Suspended
Definition: Awards of the credential are not available, but may resume.
In Scheme: ceterms:CredentialStatus

Update the definition of credentialStat:Deprecated

From: Credential is no longer awarded.
To: Awards of the credential have ceased.

Deprecate credentialStat:Superseded

From: vs:term_status vs:stable
To: vs:term_status vs:deprecated

The end result of which will be:
4 properties related to connections between nodes:

  • previousVersion (updated)
  • nextVersion (new)
  • supersededBy (new)
  • supersedes (new)

A revised credential status concept scheme:

  • Active (unchanged)
  • Probationary (unchanged)
  • Deprecated (updated)
  • Suspended (new)
  • Superseded (removed)
@siuc-nate

This comment has been minimized.

Copy link
Contributor

@siuc-nate siuc-nate commented Oct 11, 2019

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

@siuc-nate siuc-nate closed this Oct 11, 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.