Link from competency to occupation, industry and CIP

[philbarker]

As discussed in CTDL meetings over the last few weeks, Rich Skill Descriptions link each competency / skill to an occupation using a an ONET code, to an industry using SIP and to a program classification using CIP.

Should we follow suit?

This would involve adding Skill to the range of ceterms:occupationType etc.

[siuc-nate]

I think that, semantically, it should be the occupations that reference the skills. An occupation (be that a ceterms:Occupation, or an ONET occupation, or any other sense of the term "occupation") "knows" what skills it requires; a skill can't possibly know all of the occupations it might be relevant to.

[philbarker]

I wonder if this might be the redemption of the alignment object. The usecase here isn't about building a skills framework for an occupation, but about aligning learning objectives with occupations (ultimately I guess with the aim of aligning courses/learning opportunities with occupations). So the point isn't really about what the skill "knows" but that someone has made an assertion that Skill A is useful for Occupation X. If the alignment object were seen as the central node for this assertion, we would say something like "this alignment object says that someone has asserted Skill A is useful for Occupation X". Since Alignment Objects aren't symmetric, i.e. arcs come in to them from the aligned resource, and go out of them to the node in a framework being aligned to, that would look like:

(Skill A)--[occupationType]-->(AlignmentObject)--[targetNode]-->(Occupation X)

instead of

(Skill A)<--["occupationAlignmentFor"]--(AlignmentObject)--[targetNode]-->(Occupation X)

(using a made up "occupationAlignmentFor" property)

When you're drawing a graph or querying one it doesn't matter much which way the arrows point (it's `?s ), but it does when thinking about workflow and who has authority to make assertions about which resources.

"Redemption of the alignment object" because this line of thinking justifies (for me at least) not simply saying

(Skill A)--[occupationType]-->(Occupation X)

It also leads to questions about whether you would want other information in the Alignment Object, such as "says who?"

[siuc-nate]

I would suggest looking at the existing CTDL AlignmentMap class, which may be of use here, since it allows an organization to, as a third party, make assertions about things it doesn't own. this would enable an organization to assert something along the lines of:

(Occupation X)--[ceasn:skillEmbodied]-->(Skill A)

Regardless of whether (Skill A) is a ceasn:Competency or an RSD or whatever since it just needs to have a URI to point to.

That also solves the "says who?" problem, since AlignmentMap is attached to its parent organization.

[stuartasutton]

We've not looked at AlignmentMap in a long time (and never in depth). The original driving context was the An instance of AlignmentMap references an array of rdf:Statement instances (:s :p :o)...i.e. a reified triple; thus, those rdf:Statement entities can be further annotated (including who asserted the triple). There is no certainty that the entity who created a particular AlignmentMap is actually the same entity who made the assertions. Thus, Bill can create a an AlignmentMap filled with assertions made by Jane.

[jeannekitchens]

All, just to be sure of what the end result we'll need to be. When I populate a spreadsheet for upload of a competency framework, there would be a column with a ceasn:occupationtype heading , and for each competency row under that heading will be cells with a pipe seperated list of occupation codes.

This is the spreadsheet used to upload the RSD Collection which currently doesn't have this column. https://docs.google.com/spreadsheets/d/1V_KQqdL4K8QUSOsboDj4Z2HASuTKW-JdM28HvU-NXfg/edit#gid=501611954

I just want to be sure we're keeping this simple. For me, it's no different than a list of key word. It's just more information about a competency statement.

[siuc-nate]

If all we want to do is include the list of codes and nothing else, then we can probably do it that way - but it sounds like we want to involve richer information. Regardless, I still think that the occupation should reference the competency, not the other way around.

[siuc-nate]

Per our 3/3/2021 meeting (and despite my objections):

Proposal:

Add:

Subject: ceterms:industryType
Predicate: schema:domainIncludes
Object: ceasn:Competency

Subject: ceterms:occupationType
Predicate: schema:domainIncludes
Object: ceasn:Competency

Subject: ceterms:instructionalProgramType
Predicate: schema:domainIncludes
Object: ceasn:CompetencyFramework, ceasn:Competency

We will also need to update the competency framework detail page, accordingly.

[woodkri]

In the import/export from CaSS, do you want to use socList and naicsList as was proposed for competency frameworks? Anything special for instructionalProgramType?

[jeannekitchens]

@woodkri the instructionalProgramType is the Classification of Instructional Programs (CIP) so cipList.

[siuc-nate]

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