Education to Work is Not Linked

[jeannekitchens]

This is an Equity Council use case.

This issue replaces #873

Need to support functionality to indicate a Credential, Learning Opportunity, Learning Program, Course or Assessment Profile isPrepartionFor, isRequiredFor, isRecommenedFor a Job, Occupation or Work Role and very likley also a Task.

Add: ceterms:targetJob - Job that is a focus of the resource. Add: ceterms:targetOccupation - Occupation that is a focus of the resource. Add: ceterms:targetTask - Task that is a focus of the resource.

URI: ceterms:targetJob Label: Target Job Definition: Job that is the focus of a resource. Domain: cetermsceterms:ConditionProfile Range: ceterms:Job

That would enable a path like Credential > isRequiredFor > ConditionProfile > targetJob > Job

URI: ceterms:targetOccupation Label: Target Occupation Definition: Occupation that is the focus of a resource. Domain: ceterms:ConditionProfile Range: ceterms:Occupation

URI: ceterms:targetTask Label: Target Task Definition:Task that is the focus of a resource. Domain: ceterms:ConditionProfile Range: ceterms:Job

Domain Includes: ceterms:ConditionProfile, ceterms:Credential, ceterms:LearningOpportunity, ceterms: Course, ceterms:AsssesmentProfile

[siuc-nate]

Is this a duplicate of #873 ?

[philbarker]

1. The proposed domain leads to paths that are convoluted: Credential > isRequiredFor > ConditionProfile > targetJob > Job. What's wrong with Credential > isRequiredFor > Occupation ?

2. The definitions are kind-of opaque: what does "is focus of" mean? We can be clearer by being more specific, e.g. targetJob: Indicates a job to which the resource was designed to lead, or for which it has been found to be highly relevant.

[siuc-nate]

Routing it through Condition Profile is intentional, as it allows us all of the contextualization there that we gain by going through it in other use cases.

The definitions were (loosely) based on the existing definitions for the various "target____" properties. They could probably all do with some cleanup/examination.

[siuc-nate]

Per our 2023-05-08 meeting: There is preference for the idea of a "target occupation" rather than a "target job", as the former is more practical than the latter in terms of "I am publishing a credential, it is for ____".

[siuc-nate]

@philbarker @mparsons-ce @jeannekitchens per our 2023-05-09 meeting this is a final proposal to enter into pending on Friday, May 12th. Need any specific changes ahead of May 12th.

Proposal:

Create rdf:Property - ceterms:targetOccupation

Status: vs:unstable Label: "Target Occupation" Definition: "Occupation that is the focus or target of this resource" Domain: ceterms:ConditionProfile Range: ceterms:Occupation

Create rdf:Property - ceterms:targetJob

Status: vs:unstable Label: "Target Job" Definition: "Job that is the focus or target of this resource" Domain: ceterms:ConditionProfile Range: ceterms:Job

Create rdf:Property - ceterms:targetTask

Status: vs:unstable Label: "Target Task" Definition: "Task that is the focus or target of this resource" Domain: ceterms:ConditionProfile Range: ceterms:Task

[philbarker]

The proposal leaves my concerns above unaddressed, but we can leave those on the table for another time. There is also some complexity around using ConditionProfile with requires as it makes the symmetry between requires and requiredBy awkward, but that is not new to this proposal, again we can think about that "another time".

With those caveats, I'm happy with this proposal.

[siuc-nate]

There is also some complexity around using ConditionProfile with requires as it makes the symmetry between requires and requiredBy awkward

Can you describe what you mean (I assume you are referring to ceterms:isRequiredFor) about the symmetry being awkward? Both properties flow through ConditionProfile.

[philbarker]

@siuc-nate I don't really want to go down that rabbit hole, but yes I did mean ceterms:isRequiredFor. The problem comes from the lack of symmetry in ConditionProfile:

res:Cr 
   a :Credential ;
   :isRequiredFor res:CP .

res:CP 
  a :ConditionProfile ;
  :targetOccupation res:O .

we don't say :requires owl:inverseOf :isRequiredFor but someone might think it is a reasonable assumption that if A requires B then B is required for A, however it would imply:

res:CP :requires res:Cr . 

# but this doesn't mean the same as, or entail  

res:O :requires res:CP.  # which is probably what was meant

# saying that explicitly makes things odder b/c you then effectively  have:

res:O :requires [ :targetOccupation res:O ]   #?! I mean, it's not wrong but it's odd.

None of which is a problem right now because we don't say :requires owl:inverseOf :isRequiredFor but it just illustrates a whole load of non-obvious awkwardness that we build in to CTDL when we reuse properties on the basis of them being functionally similar for our use case.

However, as I said: With those caveats, I'm happy with this proposal.

[siuc-nate]

res:O :requires [ :targetOccupation res:O ]   #?! I mean, it's not wrong but it's odd.

The Occupation wouldn't require itself. Wouldn't this be:

res:O :requires [ :targetCredential res:Cr ] 

Though I doubt such a thing could be inferenced without some more complex processing.

Is there some equivalent to owl:inverseOf that allows for the kind of reification/indirection involved in having something between two objects that describes the relationship between them in greater detail? It seems like a limitation of RDF. We'd have the same issue with, for example, the Action classes:

(x)-[accredits]->(y)

vs

(x)-[credentialingAction]->(AccreditActionThatDescribesThingsAndAlsoPointsToOtherStuff)-[object]->(y)

[philbarker]

res:O :requires [ :targetOccupation res:O ] #?! I mean, it's not wrong but it's odd.

The Occupation wouldn't require itself.

You would have

res:O :requires  res:CP .

res:CP  :targetOccupation res:O . # was given earlier

# hence

res:O :requires [   :targetOccupation res:O  ]  .

Wouldn't this be:

res:O :requires [ :targetCredential res:Cr ]

Nothing implies being able to turn res:Cr :isRequiredFor res:CP . into res:O :requires [ :targetCredential res:Cr ]

Is there some equivalent to owl:inverseOf that allows for the kind of reification/indirection involved in having something between two objects that describes the relationship between them in greater detail? It seems like a limitation of RDF. We'd have the same issue with, for example, the Action classes

It's a limitation of the model built on RDF, not of RDF. Don't use the same property to point to things that behave differently, then it works.

Given different properties for a strict requirement and a contextualized requirement and given a definition of "targetX" that allows an inverse this can be modelled in RDF.

[siuc-nate]

A lot of that is what I was getting at with:

Though I doubt such a thing could be inferenced without some more complex processing.

Anyway:

Given different properties for a strict requirement and a contextualized requirement and given a definition of "targetX" that allows an inverse this can be modelled in RDF.

What would an example of this be? Would you need separate properties for every possible combination of "thing that points to condition profile" + "thing that a condition profile references"? We should keep in mind that a condition profile could constrain an isRequiredFor relationship to just certain jurisdictions, audiences, or different combinations of 2-n target____s and so on.

[siuc-nate]

Also, current discussion aside, we are ready to implement the changes from this post, correct?

[philbarker]

@siuc-nate Sorry I don't have time to go much deeper into this rabbit hole unless there is a real prospect of changing how requirements are handled (that would be a breaking change).

The current proposal just continues with something that is already problematic (having requires point to something directly and point to a more complex set of conditions). As I have said twice above: with caveats, I'm happy with this proposal.

[siuc-nate]

The changes from this post have been made in pending CTDL and noted in the history tracking.

I recommend we close this issue and, if needed, continue the discussion in a separate one.