Target Occupation and Target Job Domain Needs to be Expanded

[jeannekitchens]

Major use case: As an education and training provider, I offer credentials and related opportunities to prepare for specific career fields or jobs. As a learner, I need to enroll in a program and earn a credential that makes me hireable for a specific occupation or job.

https://credreg.net/ctdl/terms#targetJob and https://credreg.net/ctdl/terms/targetOccupation need to be expanded to include:

1. All credential types https://credreg.net/page/typeslist#ceterms_Credential
2. https://credreg.net/ctdl/terms/LearningOpportunityProfile
3. https://credreg.net/ctdl/terms/LearningProgram
4. https://credreg.net/ctdl/terms/Course
5. https://credreg.net/ctdl/terms/AssessmentProfile

Many credentials, LOs, LPs, Courses, and APs are for the purpose of preparing for specific occupations or jobs. It is not sufficient to only identify Occupation Types. Occuption Types are used for many other purposes including CIP/SOC crosswalks.

From Rutgers University EERC State Noncredit Data Taxonomy https://docs.google.com/spreadsheets/d/1svFLdfsOEusIy9c3oZUgROJvHMsHqDau/edit#gid=257574632 (do not type in this Google Sheet) “Noncredit occupational training is geared toward individuals seeking to gain or improve job skills leading to initial or better employment. These courses are most often available through an open registration process, do not follow a typical semester schedule, and are paid for by individuals through either their own resources or through third-party funding for which they are eligible.”

[philbarker]

I think this is a step in the right direction. Classifying Learning Opps, Programs, Courses and Assessments as Occupations using occupationType was one of those short cuts that confuses two related entities; saying that the LO, program, course or assessment, targets an Occupation (which may have an Occupation Type) is more correct.

So while I know the proposal isn't to stop using occupationType on occupation-related entity types, and I know we can't deprecate its use, anything that provides a better way of specifying the occupation-relevance of these types of resource seems like the right direction. My only question is, whether the effect on search & query of having an additional path to check is too burdensome?

[siuc-nate]

I think, rather than a generic "target" property, it would make more sense to use:

Credential -[isRequiredFor]-> Condition Profile -[targetJob]-> Job
Credential -[isRecommendedFor]-> Condition Profile -[targetJob]-> Job
Learning Program -[isRequiredFor]-> Condition Profile -[targetJob]-> Job
Course -[isRequiredFor]-> Condition Profile -[targetJob]-> Job
Assessment Profile -[isRequiredFor]-> Condition Profile -[targetJob]-> Job
etc.

All of which are also already supported (as are other properties that go through condition profile, ie advanced standing, preparation, etc)

Edit: Fixed examples

[philbarker]

@siuc-nate, any suggestions for Occupation?
For Job that might make good sense, but I suspect Occupation is the more important use case. Job's are quite specific so I think there will be far fewer credentials that target jobs than target occupations. Compare "Do this certificate if you want to be a welder" to "Do this Certificate if you want to work as a fabricator-level-1 at Bob's Welding".

[siuc-nate]

We also have the same connections available for Occupation via ceterms:targetOccupation for stuff that goes through condition profile, as with most other things.

Credential -[isRequiredFor]-> Condition Profile -[targetOccupation]-> Occupation
Credential -[isRecommendedFor]-> Condition Profile -[targetOccupation]-> Occupation
Learning Program -[isRequiredFor]-> Condition Profile -[targetOccupation]-> Occupation
Course -[isRequiredFor]-> Condition Profile -[targetOccupation]-> Occupation
Assessment Profile -[isRequiredFor]-> Condition Profile -[targetOccupation]-> Occupation
etc.

Edit: Fixed examples (again)

[philbarker]

Looks like we already have this covered