Closed siuc-nate closed 1 year ago
The ceasn:k/s/a__Embodied properties make most sense in terms of description of competencies, which is where is came from. They are designed to provide information more specific than a relationship to a competency. I agree they are overly specific for linking occupation/job/workrole/task to a competency.
So, yes, let's go back to using the ceasn:k/s/a__Embodied properties in their intended role of providing further details about competencies, if necessary.
And, yes the definition of targetCompetency
makes it a good substitute.
My only qualm is that while we've defined targetCompetency to mean relevant competency, the name is awkward because "target" implies leading towards or oriented towards, and what we have here is something more like requiredCompetency
or just relevantCompetency
—but I guess it is too late to address that.
Let's see if we can broaden the definition of targetCompetency and move this forward. It's definitely clear after spending alot of time on publishing jobs, work roles and tasks that there's only certain use cases that will at all related to using the embody properties. The targetCompetency is most appropriate for each of the Work classes. E.g., there's some jobs that may require every competency but the reality is most jobs do not, they have target competencies. These competencies may be learned on the job and depending on a level can be evaluated differently.
Let's see if we can broaden the definition of targetCompetency and move this forward.
Agreed.
Leave the definition as is and implement this as a final proposal.
Proposal: Add:
Subject: ceterms:targetCompetency Predicate: schema:domainIncludes Object: ceterms:Occupation, ceterms:Job, ceterms:WorkRole, ceterms:Task
The above change has been made in pending CTDL and noted in the history tracking.
Per our 2023-10-25 meeting: