ceterms:entryCondition Domain needs to be updated to include Credential and its subclasses

[jeannekitchens]

Major Use Case: As a state agency, I require all WIOA credentials to include prerequisites to entry along with requirements. Thereby, my system identifies these as two separate data elements. Major Use Case: As a software solution provider I am required to display CTDL data for WIOA credentials and differentiate between prequisites and other conditions for enrollment with my tool for learners and local workforce providers. Major Use Case: As a major competency-based online postsecondary institution, I do not consider my insitutions credentials to be programs. They are credentials and I need to be able to explictly describe conditions and entry requirements.

ceterms:entryCondition Definition: Requirements for entry into a credentialing program, a learning opportunity, or an assessment, including credentials, transcripts, records of previous experience, or other forms of entry documentation. Usage Note: For Courses required to be taken before entry into another Course, use prerequisite.

Updates

Update Defintion ceterms:entryCondition definition to "Requirements for entry for a Credential, Learning Program, a Learning Opportunity, or Assessment, including credentials, transcripts, records of previous experience, or other forms of entry documentation."

Add Domain Includes: Credential and all Credential subclasses.

[philbarker]

I know why you are asking for this, but you won't get decent linked data if you conflate Program with Credential. Even when people are using "Credential" as a metonym for Program we need to separate the two.

We need to look at our definition of Program to better address competency-based education, perhaps:

Set of learning opportunities, assessments, and/or pathway that leads to an outcome, usually a credential like a degree or certificate.

The change is in bold. We could go further and say that the pathway can be a competency pathway, either in the definition or as a usage note.

[jeannekitchens]

@philbarker if a credential has conditions including the concept that credits have to go through condition profile. It makes sense that a specific type of condition is an entryCondition. When using condition profile, both recommended and required are in range. Also, many credentials are stand alone meaning they are not offered by a school. I.e., an occupational license may require an assessment or have prerequisites that include have met a set of occupational and other conditions. I really don't see how we can not support this with Credential classes.

[philbarker]

@jeannekitchens If you're talking about the requirement to be awarded a Credential that is fine, it belongs on the condition profile associated with the credential, e.g. if you need a law degree before you can get a license to practice law. Likewise, if you must have certain competencies before you are awarded a competence-based credential. That's already possible.

I understood you were after something different, the entry requirements or conditions that had to be met before you enrol with the "major competency-based online postsecondary institution" for it to do whatever it is that it does (e.g. enrol on a program of assessments). That's about something different to the credential, just as a law degree is different to the license to practice and the competencies are different to the competence based credential.

[jeannekitchens]

If we broadened https://credreg.net/ctdl/terms#prerequisite that would make alot of sense because, for example a certification or an occupational license that have prequisites could use the definition most pertainent. However, if we can minimally get https://credreg.net/ctdl/terms#entryCondition into play that satisfies multiple real-world use cases. Also, I don't see how could limit it to just license or certification. That leaves out WGU and likely other institutions and we'd have trouble with certificates etc.. A badge could be awarded for anything.

[philbarker]

I sense that adding Credential to the domain of https://credreg.net/ctdl/terms#entryCondition is the least bad option that you'll accept.

Conflating Credentials with the programs that lead to them is a bad idea, it degrades the ability to distinguish between the two, and this ability is important for people who describe just credentials (e.g. verifiable credentials) or just learning opportunities (e.g. course directories). It will also make mapping & crosswalking more difficult. But CTDL is already full of it, so it's just adding to an existing weakness.

A better solution would be to use entryCondition on whatever people have to enrol on before sitting the assessments or whatever it is that leads to award of the credential. That could be via a blanknode if there is nothing the data provider wants to admit to having.

Missing out details of condition profiles that would look like:

ex:MyCredential a ceterms:Credential ; ceterms:requires [ a ceterms:LearningProgram #NB, redefine this to include a set of assessments of competencies ceterms:entryCondition ex:Condition1, ex:Condition2 ; ], ex:Competency1, ex:competency2 .

This says that to enter on the program (defined broadly to include a set of assessments) that leads to the award of the credential you need to satisfy two entry conditions; and these are differentiated from the requirements for the Credential which are completion of the program (which could be passing the assessments) and two competencies (presumably assessed by those assessments passed). Using a ConditionProfile would make lots of variations possible, like the LearningProgram being optional if you already have certificates for the relevant competencies.

I think that satisfies the use case, without muddying what is required for what.

[siuc-nate]

I'm with Phil on this one.

One does not enter into a credential, one enters into a program and eventually receives a credential. A credential is the output, the result, the end product. The thing you do to earn the credential (be it a program or assessment or whatever) is the thing with the "entry" condition.

Conflating Credentials with the programs that lead to them is a bad idea, it degrades the ability to distinguish between the two,

This is the very short version of what I've been saying all along every time one of these changes comes up.

But CTDL is already full of it, so it's just adding to an existing weakness.

Unfortunately this is also true, despite my pushback in previous instances.

That could be via a blanknode if there is nothing the data provider wants to admit to having.

I have also suggested this in the past for similar kinds of issues.

[jeannekitchens]

@philbarker and @siuc-nate we have to resolve this preferably today. This is holding up an important use case with data requirements.

It is factual that there are credentials that are firewalled from the offerings and assessments to prepare for them. Those credentials have conditions including prerequisites.

If any given credential can have any of these already in the Credential domain that in range of Condition Profile. It makes sense that either entryCondition and/or prerequist

1. ceterms:advancedStandingFrom]
2. ceterms:coPrerequisite
3. ceterms:corequisite
4. ceterms:isAdvancedStandingFor
5. ceterms:isPreparationFor
6. ceterms:isRecommendedFor
7. ceterms:isRequiredFor
8. ceterms:preparationFrom
9. ceterms:recommends
10. ceterms:renewal
11. ceterms:requires

[philbarker]

@jeannekitchens I can't think of anything except to repeat what @siuc-nate has above "One does not enter into a credential, one enters into a program and eventually receives a credential." The list you provide are the conditions for being awarded the credential, not entering into the program. It's quite important not to conflate the two.

This works:

ex:MyCredential a ceterms:Credential ;
    ceterms:requires [
        a ceterms:LearningProgram            #NB, redefine LearningProgram to include a set of assessments of competencies
        ceterms:entryCondition ex:Condition1, ex:Condition2 ;
] .

@siuc-nate might be able to suggest other properties, build out an example with a ConditionProfile and/or put it into JSON-LD.

I cannot honestly advise you to do something that I think is worse than that.

[jeannekitchens]

@philbarker Since credential has other options, e.g., ceterms:coPrerequisite we'll have to utilize it but let's discuss this. I actually prefer not to use entryCondition. I started there due to pushback.

Prequisite is better and Credential already has coPrerequisite and coPrerequisite. Can we change this proposal to use prerequisite?

[philbarker]

We decided a while back to keep ceterms:prerequisite as a relationship between courses, because we already have the broader ceterms:requires. If you want to define a requirement of a Credential use that.

[jeannekitchens]

Just so everyone has the full list of existing Credential properties that are in range of Condition Profile, Credential already has the following so there isn't much benefit to excluding cterms: prerequisite from Credential:

1. [ceterms:advancedStandingFrom] (https://credreg.net/ctdl/terms/advancedStandingFrom)
2. ceterms:coPrerequisite
3. ceterms:corequisite
4. ceterms:isAdvancedStandingFor
5. ceterms:isPreparationFor
6. ceterms:isRecommendedFor
7. ceterms:isRequiredFor
8. ceterms:membershipCondition
9. ceterms:preparationFrom
10. ceterms:recommends
11. ceterms:renewal
12. ceterms:requires

Per prior posts, it was required to support the use case where there required or recommended conditions and prerequisites. Thereby, we utilized coPrequisite as it is defined as, "Resource that must be completed prior to, or pursued at the same time as, this resource."

[jeannekitchens]

No action taken. Used ceterms:coPrerequisite for the described use case.