Improve handling of targetCompetency

[siuc-nate]

http://credreg.net/ctdl/terms/targetCompetency

Currently:

• Credential does not have targetCompetency
  • Credential references competency via properties that point to ConditionProfile, e.g. Credential -> requires -> targetCompetency or Credential -> recommends -> targetCompetency
  • The exact meaning of Credential -> targetCompetency is not as clear as using one of the properties that point to ConditionProfile
• AssessmentProfile and LearningOpportunityProfile do have targetCompetency
  • Presumably Assessment -> targetCompetency means the assessment assesses that competency - however, we also have ceterms:assesses, which expresses the same data more directly
  • Presumably Learning Opportunity -> targetCompetency means the learning opportunity teaches that competency - however, we also have ceterms:teaches, which expresses the same data more directly

Should we add targetCompetency to Credential or remove it from AssessmentProfile and LearningOpportunityProfile?

[stuartasutton]

Nate, before we go any further with this, note that your first bullet is only partially correct.

"Credential references competency via properties that point to ConditionProfile, e.g. Credential -> requires -> targetCompetency or Credential -> recommends -> targetCompetency"

The following don't exist:

Credential -> requires -> targetCompetency
Credential -> recommends -> targetCompetency

We have:

Credential==requires/recommends==>AssessmentProfile
Credential==requires/recommends==>ConditionProfile
Credential==requires/recommends==>CredentialAlignmentObject
Credential==requires/recommends==>LearningOpportunityProfile

What I think your are saying is missing is the ability of the ceterms:Credential subclasses to point to instances of Competency in the same way as the recent addition of teaches and assesses. So, let's back up and look at why those two properties were added (see #403). I discovered in WorkIt data that literals for teaches and assesses were being used as values for the alignmentType property in instances of CredentialAlignmentObject being referenced from instances of LearningOpportunityProfile and AssessmentProfile. So #403 suggested that we create teaches and assesses as subproperties of targetCredential and that they be used instead as the verbs in

LearningOpportunityProfile==teaches==>CredentialAlignmentObject
and
AssessmentProfile==assesses==>CredentialAlignmentObject

If anything, the addition of something like requiresCompetency (existing requires has too broad a domain) with constrained domain of the Credential subclasses and range of CredentialAlignmentObject and Competency completes the picture so that we go from this situation:

...to the following situation with Credential being treated in the same was a LearningOpportunity and `AssessmentProfile:

Which, with the appropriate ranges would enable the following in a thin CTDL and schema.org contexts:

[siuc-nate]

Fair enough on your points, but, ceterms:requires already has a range of CredentialAlignmentObject, which was added (per #188) specifically to enable saying Credential -> requires -> targetCompetency. So in my opinion we don't need a requiresCompetency property. This also (conveniently) lets us keep with the "teaches/assesses/requires" nomenclature used in the world of learning resources.

Anyway, I think what got lost in my first post was the point I was really trying to make: we seem to have a lot of confusing/redundant/questionable semantic meaning now that we have so many ways of getting from something to a competency.

Consider (given that all of the "Competency" instances below are actually done through CredentialAlignmentObject - I am just going to use "Competency" here for brevity):
Credential
Credential -> requires -> Competency
Means: "The credential requires the competency." Clear enough.

Assessment
Assessment -> requires -> Competency
Means: "The assessment requires the competency." Presumably this means you must have the competency in order to pass the assessment.

Assessment -> assesses -> Competency
Means: "The assessment assesses the competency." My first instinct (and original version of this paragraph) is to say that this means the same thing as "requires", but, in thinking about it further, an assessment could assess several competencies without necessarily requiring any of them - i.e., you must demonstrate knowledge of 7 out of 10 things, but which 7 do not matter. If two of those 10 things are required regardless, then it makes sense to have both an assesses and a requires property, here. It just may not be immediately intuitive.

Assessment -> targetCompetency -> Competency
Means: "The assessment aligns to the competency." I'm not sure if this is a problem with the definition of "targetCompetency" or not, but the meaning here isn't obvious. It probably made more sense before the two previous properties were available, as it could then easily imply that the assessment "targets" some competency (though this doesn't really match the definition, it is how we have been using the property), which in turn implies that the assessment both assesses and therefore requires the competency. But:

1. That is a lot of reliance on implications/interpretations, and
2. Now that we do have the other two properties, I'm not sure what you would express with this property that couldn't be expressed better with one of the above properties (or the properties that point to ConditionProfile, e.g., Assessment -> advancedStandingFrom -> ConditionProfile -> targetCompetency -> Competency).

Assessment -> entryCondition -> ConditionProfile -> targetCompetency -> Competency
Means: "You must have this competency before taking this assessment." Perhaps an uncommon usage (at least to me), but, I guess it isn't really redundant or nonsensical.

Learning Opportunity
Learning Opportunity -> requires -> Competency
Means: "The learning opportunity requires the competency." Again, clear enough, provided it's understood that this is a requirement to pass the learning opportunity, and not in some other way.

Learning Opportunity -> teaches -> Competency
Means: "The learning opportunity teaches the competency." Unlike "assesses" above, this one doesn't feel redundant with requires.

Learning Opportunity -> targetCompetency -> Competency
Means: "The learning opportunity aligns with the competency". Again, since we have the other properties, this particular usage seems to have outlived its usefulness.

Learning Opportunity -> entryCondition -> ConditionProfile -> targetCompetency -> Competency
Means: "You must have this competency before entering this learning opportunity". Fair enough.

In typing all that out, I think the problem became clearer to me - I had conflated two separate things (and discovered a third):

1. Now that other, more detailed properties are available, it is not clear what the meaning of "targetCompetency" is when used directly by either Assessment or Learning Opportunity. I would suggest we consider dropping AssessmentProfile and LearningOpportunityProfile from the domain of targetCompetency, but it's possible I'm missing something that mean this is a bad idea.
2. Because of how closely related "requiring something" and "assessing (i.e., ensuring that you have or are capable of) something" are, the distinction between the intended meaning of Assessment -> requires -> Competency and Assessment -> assesses -> Competency wasn't immediately clear. We will need to make sure we have good documentation/guidance for this part.
3. The definition of ceterms:targetCompetency does not align well with how we actually use the property. I suggest changing it to something like "A competency relevant to the resource being described." Even if we do nothing else, I think this change makes sense.

To summarize:

Proposed changes:
Remove:

Subject: ceterms:targetCompetency
Predicate: rdfs:comment
Object: "An alignment to a competency assertion in an established framework."

Add:

Subject: ceterms:targetCompetency
Predicate: rdfs:comment
Object: "A competency relevant to the resource being described."

Changes to consider/discuss:
Remove:

Subject: ceterms:targetCompetency
Predicate: rdfs:domain
Object: ceterms:LearningOpportunityProfile

Remove:

Subject: ceterms:targetCompetency
Predicate: rdfs:domain
Object: ceterms:AssessmentProfile

On that note, is it considered a system breaking problem to remove a domain like that? I can see how it might be. If so, it isn't something we should sweat too much - we can probably lean on documentation and guidance to achieve the desired effect without making these changes to the schema. And there may yet be some unforeseen usefulness to saying that a competency relates in some general sense to an assessment or learning opportunity, so I do not feel very strongly about making this change.

[stuartasutton]

Nate, part of my goal was to reduce the direct use of targetCompetency as much as possible. Both teaches and assesses are subproperties of targetCompetency. The goal of creating a requiresCompetency was so it, too, could be declared as a subproperty of targetCompetency...something we would not want to do with requires.

[siuc-nate]

But then we would have:
Assessment/Learning Opportunity/Credential -> requires -> Competency
and
Assessment/Learning Opportunity/Credential -> requiresCompetency -> Competency

I don't think it's necessary to introduce such a property since the domain and range of requires already accommodate the use case.

Additionally, we already have
Assessment/Learning Opportunity/Credential -> recommends -> Competency
We wouldn't want to have to also introduce a "recommendsCompetency" property.

I think the schema as-is handles this well enough.

[stuartasutton]

Bottom line, we've started moving away from use of ceterms:targetCompetency with ceterms:LearningOpportunityProfile and ceterms:AssessmentProfiles through the use of the new and more precise ceterms:teaches and ceterms:assesses. If you think ceterms:requires is good as-is to support the same movement for ceterms:Credential, then OK. But let's not add ceterms:Credential to the domain list of ceterms:targetCompetency when we actually mean the more precise, and already existing ceterms:requires.

In this regard, you ask:

"Should we add targetCompetency to Credential or remove it from AssessmentProfile and LearningOpportunityProfile?"

It's clearly the latter for me--i.e., remove it from the domain list for ceterms:LearningOpportunityProfile and ceterms:AssessmentProfiles.

SECOND, we should add at least ceterms:Competency to the ranges of ceterms:teaches, ceterms:assesses, and ceterms:requires so we can enable the following direct assertions in a thin CTDL as noted above:

Credential==requires==>Competency
LearningOpportunityProfile==teaches==>Competency
AssessmentProfile==assesses==>Competency

So terse assertions can be made without always going through `ceterms:CredentialAlignmentObject.

[stuartasutton]

We should also enable

Credential==recommends==>Competency

Through addition of ceterms:Credential to the range list of ceterms:recommends.

[siuc-nate]

So what this comes down to (correct me if I'm wrong) is:

Remove:

Subject: ceterms:targetCompetency
Predicate: rdfs:domain
Object: ceterms:LearningOpportunityProfile

Remove:

Subject: ceterms:targetCompetency
Predicate: rdfs:domain
Object: ceterms:AssessmentProfile

Add:

Subject: ceterms:requires
Predicate: rdfs:range
Object: ceterms:Competency

Add:

Subject: ceterms:assesses
Predicate: rdfs:range
Object: ceterms:Competency

Add:

Subject: ceterms:teaches
Predicate: rdfs:range
Object: ceterms:Competency

Add:

Subject: ceterms:recommends
Predicate: rdfs:range
Object: ceterms:Competency

[stuartasutton]

@siuc-nate, I'd also include your earlier suggestion to clean up the definition of ceterms:targetCompetency:

Remove:

Subject: ceterms:targetCompetency
Predicate: rdfs:comment
Object: "An alignment to a competency assertion in an established framework."

Add:

Subject: ceterms:targetCompetency
Predicate: rdfs:comment
Object: "A competency relevant to the resource being described."

Then, more precision is achievable through the ceterms:targetCompetency subproperties 'ceterms:teaches, ceterms:assessesandceterms:requires(even though the latter is not (and cannot) declared as a subproperty ofceterms:targetCompetency`).

Regarding semantic conflation of ceterms:requires and ceterm:assesses, there is a significant difference with a domain of `ceterms:Assessment. An assessment may require a competency with no intention of assessing it. It may simply want to guarantee (require) evidence of success with a competency even thought it does not directly assess it through the subject assessment.

[siuc-nate]

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