Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Changes to integrate Pathway constraints model into ConditionProfile and related resources #848

Open
stuartasutton opened this issue Oct 4, 2022 · 2 comments

Comments

@stuartasutton
Copy link
Contributor

In order not to have to return to ceterms:prerequisite immediately after these discussions are concluded, we need to also consider the addition of ceterms:ConditionProfile to its range. This proposal stems from earlier discussions (at Phil's suggestion) that aspects of the model for ceterms:PathwayComponents conditions and constraints are also applicable to ceterms:Course and ceterms:LearningOpportunity through ceterms:ConditionProfile:

  1. ceterms:hasConstraint
  2. ceterms:logicalOperator
  3. ceterms:Constraint

Also add ceterms:targetCourse to ceterms:ConditionProfile as a subproperty of ceterms:targetLearningOpportunity.

The Hutchison Welding Technology prerequisites for course EN101: English Composition II illustrate the need:

Prerequisites: EN101 English Composition IA with a grade of C or higher, or EN101H English Comp IA with a grade of C or higher, or EN100 English Comp IB with a grade of C or higher.

Slight tweaks to the definitions of affected properties are likely necessary.

@siuc-nate
Copy link
Contributor

I would suggest treating prerequisite the same way we treat requires and entryCondition in terms of domain and range, as that would avoid future issues there (though it does feel even more redundant with entryCondition that way, it will at least then behave consistently with the other properties).

Adding those two pathway-related properties to Condition Profile makes sense, at least on the surface, but:

  • It may require adjustment to the definition of ceterms:Constraint, which explicitly calls out "pathway components" as being the things that it is applicable to.
  • The current usage of hasConstraint/Constraint implicitly applies those Constraints to the Pathway Components that are referenced via the parent Component Condition's targetComponent property. The structure here is different, so we'll need to give some thought to which properties of Condition Profile (or rather, which things pointed to by said properties) that Constraints would apply to in that context. Presumably this would be the various target_____ properties that are already part of Condition Profile, but something in the handbook to call that out would be good.
  • The comment on logicalOperator describing that it applies to Constraint entities should keep it from being misapplied to other properties of Condition Profile, but we'll need to keep an eye on how that gets used.
    • It should probably also be a usage note rather than a comment.

Also add ceterms:targetCourse to ceterms:ConditionProfile as a subproperty of ceterms:targetLearningOpportunity.

There is no targetCourse property, and targetLearningOpportunity already explicitly covers Course, so I don't see a need for this.

@siuc-nate
Copy link
Contributor

Discussion of this has picked up (somewhat) in #947

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants