search

CredentialEngine / Schema-Development

Development of the vocabularies for the CTI models
14 stars 8 forks source link

Pathway Constraints and Other Related Updates Proposal #807

Closed stuartasutton closed 2 years ago

stuartasutton commented 2 years ago

Experience and further thinking on pathways require the removal of the domain and range of the PathwayComponent subclasses from the terms ceterms:precedes and ceterms:prerequisite. Appropriate domains/ranges for these properties are, at a minimum, ceterms:Course and ceterms:LearningProgram.

The rationale for removing the domain and range from PathwayComponent subclasses is that both properties define conditions directly on an instance of a PathwayComponent subclass when all such conditioning must be handled through that PathwayComponent's ceterms:ComponentCondition as the following diagram illustrates:

Pathway_Columns-2c drawio

The notion of "precedes" is inherent in the structure of the pathway through the hasChild and, additionally, through any progression model used that identifies points in the progression and adds gloss. The notion of "prerequisite" in the pathway is illustrated in the diagram above by the ConditionComponent for the "HTML5 CSS 3" badge component.

Related to #804

siuc-nate commented 2 years ago

How does this gel with the current use of precedes, where it basically means "There is no requirement to do "Thing A" before "Thing B", but you typically would"? For example, a course that prepares for an assessment, but which is not required to take the assessment (as seen in this pathway)?

stuartasutton commented 2 years ago

Nate, it doesn't affect the actual definition of ceterms:precedes which says "this" is before "that". It simply denotes a sequencing and nothing else. If you want something that precisely states that "[t]here is no requirement to do 'Thing A' before 'Thing B', but you typically would", you need to define a subproperty of ceterms:precedes to do that (e.g., optionallyPrecedes).

siuc-nate commented 2 years ago

The comment on ceterms:precedes was added specifically to indicate the lack of requirement. However, that is a little bit beside the point - the more important part of my question was to find out how this proposal gels with the NRF pathway I linked to, where precedes is an important part of the glue holding three sets of pathway components together.

stuartasutton commented 2 years ago

Summary of updates to the CTDL Pathway terms.

See also: CTDL Pathways, Conditions and Rules: Overview

Edit: The proposal has been moved here: https://github.com/CredentialEngine/Schema-Development/blob/master/PathwaysConditionsAndConstraints/proposal.txt

stuartasutton commented 2 years ago

The notion behind the current use of the ceterms:precedes property in this context is not a relationship between two ceasn:PathwayComponent entities, but a relationship between the schema:Person (learner) and a ceasn:PathwayComponent--i.e., the learner record of the person states that the ceasn:dateAcheived for a the particular component must be less than or equal to (≦)the ceasn:startDate of that subsequent component.

Note: Strained interpretation of ceasn:startDate, but the correct notion.

siuc-nate commented 2 years ago

I think you are technically correct, but also overthinking it a bit. Someone who is building a pathway from resources they may or may not own may want to simply say "you should do X before Y, but don't have to". (i.e. X precedes Y)

stuartasutton commented 2 years ago

Nate, that is already handled through the hasChild relationship that were totally left out of the NRF pathway.

siuc-nate commented 2 years ago

I'm not so sure that hasChild is the correct property. If Course A precedes Course B, that doesn't mean Course A is a child of Course B (since there is no structural relationship between them, just an optional temporal one).

stuartasutton commented 2 years ago

I agree, hasChild is not the right property. It was inherited from the earlier work group phase with its relationship to the Concentric Sky work. I could accept ceasn:precedes instead. Consequences of that change??

siuc-nate commented 2 years ago

Not to nitpick, but the other key thing is the directionality of the property. Precedes is the only one that goes "backwards" relative to the other properties. I would strongly suggest a different property that points from the later component to the earlier one. Perhaps "precededBy" or some variation of ceterms:recommends (which carries a similar "you should do it, but you don't have to" notion). Consistent directionality makes figuring out the pathway a lot easier (for example, when rendering pathways for the finder, one of the steps is to calculate a fake "precededBy" property based on reversing the "precedes" connections so the rest of the code can handle it properly).

stuartasutton commented 2 years ago

Nate, if you look at the document I prepared for pathways, you'll see a clear recognition of the two directions--one for application of constraints and the other for the learner/worker journey. That means that we could have reciprocal properties, but even that would be wrong in one direction or the other...application of constraints or journey traveled.

On Mon, Mar 7, 2022 at 12:21 PM siuc-nate @.***> wrote:

Not to nitpick, but the other key thing is the directionality of the property. Precedes is the only one that goes "backwards" relative to the other properties. I would strongly suggest a different property that points from the later component to the earlier one. Perhaps "precededBy" or some variation of ceterms:recommends (which carries a similar "you should do it, but you don't have to" notion). Consistent directionality makes figuring out the pathway a lot easier (for example, when rendering pathways for the finder, one of the steps is to calculate a fake "precededBy" property based on reversing the "precedes" connections so the rest of the code can handle it properly).

— Reply to this email directly, view it on GitHub https://github.com/CredentialEngine/Schema-Development/issues/807#issuecomment-1061096693, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAWNRJQ7EDSCYCVR5TV7ARLU6ZQMRANCNFSM5KMAWRYA . You are receiving this because you authored the thread.Message ID: @.***>

philbarker commented 2 years ago

Here's the N Dakota Cyber pathway (just the pathway part, not all the courses) using pathway basic components for the semesters and preceded by to provide the path. I haven't tried and of the proposed ways for representing conditions.

I think it looks good, but one thing that strikes me is that aside from the component condition there is no link between the Semester basic components and the course components, and this is exactly where hasChild would be the right link.

Sure you can infer that links exist via the component conditions, but if I think it would be useful for tools displaying these pathways to have something that represented nature of the link, in this case the precedBy link from semester to semester is different from the hasChild link from semester to course.

NorthDakotaCyber-Latest-PW drawio

[full version here]

siuc-nate commented 2 years ago

I think it would be useful for tools displaying these pathways to have something that represented nature of the link

The conditions provide the useful connective tissue, only needing to fall back on precededBy when no such condition exists. Otherwise you would be rendering twice as many arrows (with half of them being redundant, or worse, confusing since it would imply there are ways "around" those conditions), which is just visual spaghetti as far as the end user is concerned.

I don't understand the opposition to seeing the conditions as the glue that holds pathways together. There's no way to get through a pathway without meeting the conditions. If anything, they're more important than the notion of "preceded by".

Additionally, you can use requiredNumber = 0 in a condition to embody the same "it's optional but do it first" notion as "preceded by"

stuartasutton commented 2 years ago

Phil, I have a few suggestions that I'll document later this AM after the RWSC meeting etc.

stuartasutton commented 2 years ago

@siuc-nate, @jeannekitchens & @philbarker:

Nate, you are absolutely mistaken when you say that "[t]he conditions provide the useful connective tissue, only needing to fall back on precededBy when no such condition exists." There is obviously something here that I apparently cannot make clear to you. The basic connective tissue of the pathway should be complete even if you had no ComponentConditions (and I'm not implying that you should have none).

Below is a snippet of my diagram of the National Retail Federation pathway with ConditionComponents. The skeleton of the pathway is the heavy black arrows (all precededBy (used to be hasChild)) and the grey, light dotted arrows and circles are the ComponentCondition information. Simple count rule is all that is needed in the NRF, so there are no Constraint entities. Notice that I could indeed delete all ComponentCondition entities (i.e., every dotted arc and circle) and have the basic skeleton of the Pathway fundamentally in place.

NRF-Management

Given Marc's UI/UX, this skeleton could be constructed completely through drag-and-drop before clicking to add any constraints after the skeleton was in place. However, whether the ComponentConditions and Constrain entities are displayed at all is a UI issue and not a data modeling issue. So, if it turns onto visual spaghetti, that has to be solved via the UI. The information could be derived from ComponentCondition and Constraint entities and displayed in a modal window or as text in the relevant PathwayComponent (i.e., as Concentric Sky handles it).

This will be on Tuesday's CTDL agenda; so I'd prefer not to go round and round here.

siuc-nate commented 2 years ago

I recognize your points, but my pushback would be that the pathway information is not very useful without the conditions, but that it still works fine if you use the conditions to connect the nodes and leave out most (if not all, depending on the pathway) of the precededBy arrows. If you were to swap the hard arrows with the dotted arrows in your diagram, you would still be able to determine the order of nodes and their requirements, as opposed to just the order of nodes alone.

In a more grounded context: It seems that this approach would require user entry of both the conditions and the precededBy arrows. If true, that will add an additional layer of complexity/chance for errors to the pathway upload and the editor. It may be possible instead to calculate most if not all of those precededBy connections (again, depending on the pathway) based on the conditions, but that still means the computer may guess incorrectly in some edge cases.

Ditto for display: Should precededBy arrows be left out where the conditions make them redundant, so as to keep a cleaner display for the user?

Regarding the UX for the builder: I'm pretty sure it came up that there would always be at least one condition between nodes, so this is probably something we'd need to verify.

Anyway, I don't think there's much point in arguing about it one way or the other - both precededBy and the various condition stuff need to be present in the schema, regardless of whether or not they're critical for the data for any given pathway.

stuartasutton commented 2 years ago

You are correct, there is not much point in arguing. We both know what the other is saying--we are not talking past each other. Generating the appropriate data using the pathway editor under development supports what I have been saying--(1) first you drag and drop a destination component, then (2) you drag and drop the next component, then (3) procedurally, you generate the link between the two components--that's the precededBy link (the skeleton), then (4) you click on the icon to generate a condition that establishes any constraints on the relationship(s).

If you want to create an authoring tool that leaves out the precededBy relationships, then go ahead and do it while understanding that the data generated will not interoperate smoothly with systems that more appropriately include the precededBy. However, if precededBy remains in the language, then I am satisfied and we can conclude these comments now.

philbarker commented 2 years ago

As it says in the commit summary, I have made a start on a text file for the proposal above

@stuartasutton I'm not sure what to make of the first item under properties in your comment.

ceterms:componentCondition
  Domain: ceterms:ComponentCondition
  Range: ceterms:ComponentCondition

@siuc-nate I'll break out the modified properties into subject / predicate / object lines later.

philbarker commented 2 years ago

Seeing :<= in the examples, as if < can be in a URI, got me to putting down ideas about concept schemes for comparators, I added what I could remember for actions too, though I recall Nate showing a list of array operations. My ideas are in a Google doc.

stuartasutton commented 2 years ago

See ORDL starting here: https://www.w3.org/TR/odrl-vocab/#logicalConstraints

philbarker commented 2 years ago

@stuartasutton thank you for the ODRL link. I have added mappings where I think we can.

siuc-nate commented 2 years ago

I have updated Stuart's comment above to reflect the current state of the proposal based on the powerpoint and on our discussions.

The vocabularies for constraints are still TBD.

I would also point out that the issue of whether or not to have precedes/precededBy be properties of pathway component (#813) is still open.

stuartasutton commented 2 years ago

@siuc-nate, a couple of issues with your changes: (1) the ceterms:Rule is actually a new class so I have moved it back up into the list of adds; and (2) the ceterms:hasCondition was misnamed but remains in the Modify Existing Properties section because it is the change that enables the nesting of conditions.

I see you have added ceterms:targetComponentConstraint. I don't think there was an actual decision to do so. I'm not opposed, but would like us to make sure we all understand and have looked at it in greater depth than we did last meeting.

siuc-nate commented 2 years ago

I don't recall seeing ceterms:Rule come up in our discussions or presentations - how would it be used?

siuc-nate commented 2 years ago

Per our 2022-06-14 meeting: We'll leave this one open for now so it can be tracked in the schema management system, history tracking, etc.

For the formal proposal itself, see here: https://github.com/CredentialEngine/Schema-Development/blob/master/PathwaysConditionsAndConstraints/proposal.txt

siuc-nate commented 2 years ago

Looking at the final proposal, I would advise 3 separate concept schemes, as the concepts have fairly specific uses and don't overlap:

There is zero support for skos collections in any of our code/infrastructure/documentation/etc., and it's likely that such support would not be meaningfully different from just having separate concept schemes, especially given the lack of overlap in the purposes of the concepts in such collections/schemes.

I don't think "and sequence" makes much sense as a logical operation; it seems like sequencing can and should be embodied elsewhere in the pathway structure. What would an example be of this? I'm also curious what a realistic example of an "only one" constraint would be.

I would also suggest looking at other logical operations, to make sure we don't establish a pattern that would make it difficult to add the others if they were to become relevant.

siuc-nate commented 2 years ago

Also: the definitions and ranges for left source and right source don't quite line up. I'll normalize them.

The document also uses "ceterms:Concept" in a few places - I am using skos:Concept instead.

It's also missing ceterms:leftAction. I will create it based on ceterms:rightAction.

The definition for rightAction says "action performed on the right constraint" - I assume this should be "right source" rather than "right constraint"

The domain and range of ceterms:precededBy are misaligned. Shouldn't they both be: skos:Concept, ceterms:PathwayComponent (subclasses) ?

The modification of ceterms:hasCondition only needs to add ceterms:ComponentCondition to the domain of the property (that class is already in its range).

ceterms:isPartOf is already a property of the pathway components - however, it does not point to ceterms:Pathway. However, such a change is not listed in the proposal. I will update the schema so that ceterms:isPart has a range of (among other things) ceterms:Pathway.

Curiously, ceterms:isPartOf already (in the current schema) has the pathway component subclasses in its range. What was the reasoning behind this?

One of the change items lists ceterms:componentCondition as the URL, the domain, and the range. This change doesn't make any sense (also componentCondition is not a property)

There seems to be a missing change that would remove the pathway component subclasses from the range of ceterms:prerequisite (there is only a change indicating to remove them from that property's domain). I will remove it from both.

The definitions for minimum/maximum value are reversed (and in the powerpoint, for that matter). I will un-reverse them in the schema.

I suggest giving skos:exactMatch designations in both directions between the following concepts (but have not currently done so):

stuartasutton commented 2 years ago

I gotta say, Nate. This reopening of discussion drives me crazy...since nothing is ever final, even final for the moment.

Looking at the final proposal, I would advise 3 separate concept schemes, as the concepts have fairly specific uses and don't overlap:

  • Comparators
  • Array Operations
  • Logical Operators

I've made my point here. Having 1 constraint concept scheme to look for concepts as opposed to 3 when many will likely already be struggling a bit with the semantics makes far more sense to me. SKOS concept schemes can handle node labels that can break a single concept scheme down into 3 collections.

There is zero support for skos collections in any of our code/infrastructure/documentation/etc.,

All that means is that we haven't used the skos:Collection functionality, not that we couldn't/shouldn't (but good to know that I count as "zero support"). The Collection functionality is used by many in fairly significant ways within and outside concept schemes. One frequent pattern is demonstrated in the schema encoding for the ODRL turtle odrl_schema.txt where skos:Collection is used to group properties to classes to drive interfaces to the schema.

and it's likely that such support would not be meaningfully different from just having separate concept schemes, especially given the lack of overlap in the purposes of the concepts in such collections/schemes.

I don't think "and sequence" makes much sense as a logical operation; it seems like sequencing can and should be embodied elsewhere in the pathway structure. What would an example be of this? I'm also curious what a realistic example of an "only one" constraint would be.

Drop them then. They can be added back later.

I would also suggest looking at other logical operations, to make sure we don't establish a pattern that would make it difficult to add the others if they were to become relevant.

We have looked at others and have kept ours terse.

siuc-nate commented 2 years ago

I agree, it's difficult when we have multiple very large proposals that overlap and seem to always be shifting. But I would rather us sort things out before putting them into the schema rather than afterwards.

I'm not (as my main point, at least) taking issue with the semantic argument regarding skos collections. I'm saying that our systems (schema management, publisher, APIs, search, finder, etc.) have absolutely no way to capture or use a skos:Collection (this is what I meant by "support"; i.e., the software does not support it). And even if they did, it would end up working the same way as multiple concept schemes work today from the user's perspective. I don't see the point in reinventing functionality for a more complicated solution (having to select from one concept scheme but then only use certain parts of it in certain situations) like that when a perfectly viable, simple solution is available. If we want to discuss the use of skos collections more broadly, that's fine, but we can't just insert brand new system functionality into a proposal like this.

Besides, separate concept schemes allow for separate namespace prefixes, so we could accommodate logic:oneOf and array:oneOf side by side without issue

siuc-nate commented 2 years ago

The definitions for and/or/onlyOne/andSequence are too restrictive (applying, explicitly and only, to constraints and conditions). The terms and their URIs should be re-scoped to match, or the definitions should be broadened. This is because the notions of logical and/logical or can apply to a wide variety of things (including our own future plans to use them with condition profiles).

Suggestion (use of lowercase "conditions and constraints" in the definitions is intentional, since that would allow for Condition Profiles or any other notion of "conditions"): Label: And Definition: Relation is satisfied when all of the conditions and constraints are satisfied. Usage Note: When used in a Component Condition, this applies to the combination of all immediately subordinate Component Conditions and Constraints.

Label: Or Definition: Relation is satisfied when at least one of the conditions or constraints is satisfied. Usage Note: When used in a Component Condition, this applies to the combination of all immediately subordinate Component Conditions and Constraints.

I'm less certain as to whether the following apply to the combination of immediately subordinate Component Conditions and Constraints (particularly AndSequence, given there is no notion of ordering between the values of two separate properties), but: Label: Only One Definition: Relation is satisfied when exactly one, and not more, of the conditions or constraints is satisfied. Usage Note: When used in a Component Condition, this applies to the combination of all immediately subordinate Component Conditions and Constraints.

Per our 6-21-2022 meeting: We will not keep andSequence at this time (If we keep AndSequence...) Label: And (Sequence) Definition: Relation is satisfied when each of the conditions and constraints are satisfied in the order specified. Usage Note: When used in a Component Condition, this applies to the combination of all immediately subordinate Constraints, and the order of Constraints must be preserved.

stuartasutton commented 2 years ago

@siuc-nate, @jeannekitchens & @philbarker, we'll need to put these changes on the agenda for next Tuesday.

siuc-nate commented 2 years ago

Per our 6-21-2022 meeting: We will embody the concepts above in three separate concept schemes

siuc-nate commented 2 years ago

Additional updates found by @stuartasutton and @jeannekitchens:

To be determined:

(My position on the above two is that it isn't necessary)

I will update this with formalized changes when I get back to working on this.

stuartasutton commented 2 years ago

One additional update:

The hasCondition property needs the phrase "...by which a rule set is satisfied."

siuc-nate commented 2 years ago

Will do.

I also noticed that we didn't deprecate SelectionComponent in this proposal. I assume we should do that as well?

stuartasutton commented 2 years ago

I thought that had already been done.

On Mon, Jun 27, 2022 at 10:01 AM siuc-nate @.***> wrote:

Will do.

I also noticed that we didn't deprecate SelectionComponent in this proposal. I assume we should do that as well?

— Reply to this email directly, view it on GitHub https://github.com/CredentialEngine/Schema-Development/issues/807#issuecomment-1167398451, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAWNRJXLCVE3WV3HXAOJ7RDVRHM5LANCNFSM5KMAWRYA . You are receiving this because you were mentioned.Message ID: @.***>

siuc-nate commented 2 years ago

It had not.

Further changes to make:

A quick question on "rule set" above: We removed the reference to RuleSet (the class) from the definition for targetComponent. Do we want to add that back (perhaps as "rule set" instead of "RuleSet")?

stuartasutton commented 2 years ago

No, the 3rd bullet should be "Referenced resource defines a single constraint by which a condition is satisfied."

On Mon, Jun 27, 2022 at 11:53 AM siuc-nate @.***> wrote:

It had not.

Further changes to make:

  • Add ceterms:name to ceterms:Constraint
  • Deprecate ceterms:SelectionComponent
  • Use "Referenced resource defines a single constraint by which a rule set is satisfied." for the definition of ceterms:hasConstraint

A quick question on "rule set" above: We removed the reference to RuleSet (the class) from the definition for targetComponent. Do we want to add that back (perhaps as "rule set" instead of "RuleSet")?

— Reply to this email directly, view it on GitHub https://github.com/CredentialEngine/Schema-Development/issues/807#issuecomment-1167754472, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAWNRJRH3Q6MAZK7O2HR56LVRH2EHANCNFSM5KMAWRYA . You are receiving this because you were mentioned.Message ID: @.***>

siuc-nate commented 2 years ago

Apologies, it looks like I misread and got hasConstraint and hasCondition mixed up. Currently, in pending, their definitions are:

Are these correct?

stuartasutton commented 2 years ago

@siuc-nate, looks OK but I don't know where the notion of "rule set" comes into play with hasCondition.

siuc-nate commented 2 years ago

From your message:

One additional update: The hasCondition property needs the phrase "...by which a rule set is satisfied."

stuartasutton commented 2 years ago

The hasCondition property has the domain of nothing but the PathwayComponent subclasses which have nothing to do with the notion "rule set". I think my earlier message was incomplete. It would be acceptable as: "Resource referenced defines a condition by which this resource is satisfied in full or in part."

siuc-nate commented 2 years ago

Also updated:

siuc-nate commented 2 years ago

The above changes have (finally) been entered into pending CTDL and noted in the history tracking.