Adjust the applicability of ceterms:requiredNumber

[siuc-nate]

The current definition for ceterms:requiredNumber is: "Number of targetComponent resources that must be fulfilled in order to satisfy the ComponentCondition."

However, that was written before we enabled ComponentConditions to be nested.

For comparsion, the ceterms:logicalOperator property applies to the aggregation of values from both ceterms:hasCondition and ceterms:targetComponent: Definition: "Type that denotes a logical operation such as "And", "Or", "OnlyOne"; select from an existing enumeration of such types." Comment: "Only a single instance of logicalOperator is allowed defining operations on two or more nested ComponentCondition entities, Constraint entities, or a mix of ComponentCondition and Constraint entities."

Given that ComponentConditions are now nestable, the ceterms:requiredNumber property needs to be tuned to also apply to the aggregation of values from ceterms:hasCondition and ceterms:targetComponent, so that a situation where a ComponentCondition has 3 values in its ceterms:hasCondition array but only requires 2 of them, we can capture that.

[mparsons-ce]

This update needs to consider a scenario like: Condition A

• requires 4 of 6 target components
• requires one of two entries in HasCondition

What would be the proper value to include in requiredNumber? The correct answer is 4 (of the targets) and 1 (of the hasCondition), which is not possible.

It would seem a separate property may be required like requiredConditions?

[siuc-nate]

Per our 3-14-2023 meeting:

Remove:

Subject: ceterms:requiredNumber Predicate: rdfs:comment Object: "Number of targetComponent resources that must be fulfilled in order to satisfy the ComponentCondition."

Add:

Subject: ceterms:requiredNumber Predicate: rdfs:comment Object: "Number of targetComponent or hasCondition objects that must be fulfilled in order to satisfy the ComponentCondition."

[siuc-nate]

Per our 3-14-2023 meeting: Consider:

• Logical Operator currently applies to both hasCondition and hasConstraint
• Required Number (per the above) applies to both hasCondition and targetComponent

This leads to a potential conflict in a situation like this:

Initially, we considered extending requiredNumber to also apply to hasConstraint, but that would create confusion in a scenario like this:

So instead, it seems that the number of required constraints is a different facet to the other information, which would imply the need for a property like "requiredConstraint" that is specific to the array of values of the hasConstraint property:

The above would also negate the need for the logicalOperator property entirely, except for its "onlyOne" value - but I don't think we've ever seen a scenario where "onlyOne" would make sense (and that could be handled via a Constraint anyway).

So the potential proposal (in addition to the requiredNumber changes above) would be:

• Remove logicalOperator from ComponentCondition
  • It may be worth holding onto the property and its concept scheme in case we find a use for them elsewhere
• Create a "requiredConstraint" property with a domain of ComponentCondition and a range of xsd:integer

We should also look at how these changes would impact ConditionProfile's proposed use of Constraints.

[jeannekitchens]

@philbarker @siuc-nate @mparsons-ce this is impacting our Pathway Builder Pilot. We need to be sure CTDL supports the use cases. Please review and let's get this at top of the agenda next CTDL meetin.

[philbarker]

This update needs to consider a scenario like: Condition A

requires 4 of 6 target components requires one of two entries in HasCondition What would be the proper value to include in requiredNumber? The correct answer is 4 (of the targets) and 1 (of the hasCondition), which is not possible.

As far as I can see problem, in this case, disappears if we consider logical operator to apply only to Constraints. Is it an artefact of trying to generalize the applicability of a property that was introduced for Constraints?

Expanding the scope of requiredNumber to reference Constraints and Components seems to be doing the same? Certainly if we ever expand the scope of requiredNumber beyond Conditions and Components we will need a requiredComponents property and a requiredWhatever we expand it to. The only alternative I can see is nesting of (sometimes many) alternate Conditions -- which how I handled this type of logic in the HW pathway.

We don't need logicalOperator to apply to Components because required number covers the same logic with more detail. Given n components, if

• requiredNumber is 1 of n => logical onlyOne / XOR
• requiredNumber is between 1 and n => logical OR (with more detail)
• requiredNumber is = n => logical AND.

Adding requiredConstraints adds this level of extra detail to the constraints, in which case we wouldn't need logical operator at all.

[siuc-nate]

As far as I can see problem, in this case, disappears if we consider logical operator to apply only to Constraints. Is it an artefact of trying to generalize the applicability of a property that was introduced for Constraints?

If there are 3 or more conditions, or 3 or more target components (or both), then simply saying "and" or "or" is not good enough if any 2 of the 3 present a valid choice. That's what led us to considering removing logicalOperator from the picture entirely, which seems to be where you ultimately landed as well.

Expanding the scope of requiredNumber to reference Constraints and Components seems to be doing the same?

That was where we started, but it creates the same problem of ambiguity, which is where the "requiredConstraint" property in the third picture in my previous post came from.

Certainly if we ever expand the scope of requiredNumber beyond Conditions and Components we will need a requiredComponents property and a requiredWhatever we expand it to. The only alternative I can see is nesting of (sometimes many) alternate Conditions -- which how I handled this type of logic in the HW pathway.

Correct, that nesting is how we (in our meeting) got around the problem of needing a "requiredComponents" property and a "requiredConditions" property, while also still allowing for cases where a mix/match of components and conditions was a valid choice (e.g. 3 targetComponents and 4 hasConditions, pick any combination of 5 items), a lighter version of which is shown in the bottom-most branch of the example below:

[philbarker]

That nesting approach is OK with small numbers (e.g. enumerating each combination of 3 out of 4) but it'll get tedious with bigger numbers. I think we are heading in the same direction.

[siuc-nate]

You would only need to enumerate each combination if you were using logicalOperator. By using requiredNumber/requiredConstraint, any array size should work just as well as any other. Or am I misinterpreting you?

[philbarker]

Maybe I'm wrong. Sorry, not feeling great.

[siuc-nate]

• Update definition for requiredNumber to apply to both Conditions and Components

Remove:

Subject: ceterms:requiredNumber Predicate: rdfs:comment Object: "Number of targetComponent resources that must be fulfilled in order to satisfy the ComponentCondition."

Add:

Subject: ceterms:requiredNumber Predicate: rdfs:comment Object: "Number of targetComponent or hasCondition objects that must be fulfilled in order to satisfy the ComponentCondition."

• Remove the domain for logicalOperator

Remove:

Subject: ceterms:logicalOperator Predicate: schema:domainIncludes Object: ceterms:ComponentCondition

• Create the requiredConstraint property

URI: ceterms:requiredConstraints Label: Required Constraints Definition: "Number of hasConstraint objects that must be fulfilled in order to satisfy the ComponentCondition." Domain: ceterms:ComponentCondition Range: xsd:integer

[siuc-nate]

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