Pathway Components

[jeannekitchens]

@stuartasutton @philbarker today I, @siuc-nate and @mparsons-ce met to review a pathway set that we're working with a state to publish to the sandbox. You can see the spreadsheet with the pathway information from the state that we saved in a Google Sheet. The pathway is incomplete but we're publishing the components we have so far (i.e., job components) to the sandbox to (1) understand the components and why they're not a pathway without components that get you to the occupation (e.g., credential), and (2) to continue the anlysis process to ensure we're on the same page about how to do and analysis, breakdown the components and publishing them. This led to Nate posting #745 . This is to try out a discussion to see if it makes sense to field questions for this issue or not so we can act on the issue as soon as possible if it is the correct solution. See the Google Sheet here https://docs.google.com/spreadsheets/d/1WKbPJrTIX3uZ_eED9QLoHacJTZXWk1Es/edit#gid=1657262239.

Sheet 1 = information pre-populated with yellow highlighed informaiton added by us.
Sheet 2 = the bulk upload sheet filled out.
Sheet 3 = the pathway set name and description
Sheet 4 = verbatim from state

[jeannekitchens]

..related to this, you can create a discussion and then click the ... at top, right corner and reference an issue.

[philbarker]

The solution @siuc-nate proposes in #745 seems fine.

I guess my biggest question is how does JobComponent relate to Job? Or perhaps JobComponent more like Occupation (e.g. an occupation that is a specialty of another) -- I don't see much that is employer specific in JobComponent or the use case shown. Is JobComponent a subclass of Occupation? I think such a relationship would strengthen the "education to employment" narrative for the Occupation/Job/WorkRole/Task family.

Aside: at an instance data level this is another case where multiple typed entities might help: then Occupation and JobComponent could be separate classes and some instances could be members of both, others not.

[jeannekitchens]

We're working with a partner on supporting their pathway use case which involves real employers putting their https://credreg.net/ctdl/terms#Job in the Registry and using the URIs to those jobs as a Job Component. For these pathways, they are using the ONET occupations, not a https://credreg.net/ctdl/terms#Job. If we do add an Occupation Component, it would still need to enable using Occupation Classification. Also, a Job Component can be aligned to an occupation in an Occupation Classification so we may need to have an Occupation Component as well but that component and Job Component would still both need to support identification of, for example, a Standard Occupation Code (SOC) which is in an occupation classification.

[philbarker]

What prompted the question is that the definitions for JobComponent and Occupation / Job look very similar. I know there is a functional difference, but surely there is a relationship too. Encode that relationship so that data that comes from JobComponents can be referenced from Jobs and Occupations.

For further motivation, let me rephrase the question back-to-front. If I see a Job advert for a Billing and Posting Clerk, how can credential engine data show me what career pathways this is on? The data from the spreadsheet shows me I can to get from Clerk to Financial Manager, but how could we get from the job advert (using ceterms:Job) to the pathway? Going through the SOC code is fine when there is a one-to-one match with a SOC code, but sometimes there isn't.

[jeannekitchens]

Yes...in this case the state doesn't have real-world jobs. They're using ONET occupations only. We realize there are cases where there is not a one-to-one match between a job and on occupation in classification and via the CTDL, we cover both but yes with pathway components we need to nail this down as we have two real-world use cases we're analyzing now (1) state using SOC codes (and again) the occupations as an ordered list are not a pathway they will be providing credential and other components to get ot those occupations and (2) micro pathways that lead to jobs. The jobs could have an alignment to a SOC.

[siuc-nate]

I think we came up with JobComponent before we came up with Job/Occupation/etc. classes, so it's probably just a holdover of old terminology. Since we aren't referencing any specific ceterms:Job, it probably is more correct to have some kind of OccupationComponent to represent the more ambiguous "some job in this field" notion (where "field" can either be some list of occupations or industries) that this pathway is trying to convey.

Alternatively, some third term ("CareerComponent" perhaps) that is purposefully ambiguous (to avoid confusion with the "Job" and "Occupation" classes) and can reflect a reference to any array(s) of occupation, industry, or job.

[stuartasutton]

I agree, Nate, the pathway's notion of "job" predates our new class additions. We need to keep in mind that the JobComponent in a pathway is a mere surrogate for the job and need not include everything we might deem necessary/useful in the full description of the job unless there is nothing to reference.

It seems to me that our solution needs to meet both the current Credential Engine pathway use cases and use cases beyond the Credential Engine context and policy constraints. JobComponent needs to recognize that a the CTDL pathway specification can be used by others to describe a particular persons personal journey (i.e., a surrogate for a specific position that may not have anything to reference). So, the JobComponent may reference what JDX calls a job description (e.g., not tied to a specific position) or a specific position.

To wrap our heads around the scope of what a JobComponent might represent, I suggest we go back to a pivotal document generated by Bob Sheets for the JDX work back in September of 2018 titled "Proposed Definitions and Data Element Comparison". My take is that a JobComponent can reference any of the entities described by Bob that exist in the world.