Alternatives to the whether conditions/constraints on courses are off LearningProgram or Course

[stuartasutton]

@@@

[philbarker]

I was thinking more:

This misses off a few properties to simplify in drawing it, but the key differences are the program is preparation for a credential, not required for it, the courses are part of the program not required by it; the requirements for a credential are either courses or competencies (also, not shown, assessments); I'm not convinced by programs that are parts of programs.

[siuc-nate]

I think I'm with Phil on this one.

[stuartasutton]

I have no problem with it either. As for programs that are parts of programs, I respectfully disagree. How do you deal with the notion of "concentrations" with a program if they are not programs within a program?

[siuc-nate]

What exactly do the connections look like when describing a concentration? Is it just a particular subset of courses within a program that are exclusive to that concentration (with prerequisites and other courses being shared among the concentrations)? If that's the case, a program starts to look an awful lot like a pathway. Perhaps a collection could be used here?

Actually, do different concentrations lead to different credentials, or to the same credential with some additional object that conveys "this person had this concentration"? If the latter is the case, then is there any actual value in capturing which courses go with which concentration?

[stuartasutton]

"Is it just a particular subset of courses within a program that are exclusive to that concentration (with prerequisites and other courses being shared among the concentrations)?"

No, the overall program leading to a degree has an array of courses that are sliced and diced across a set of concentrations although nothing precludes some courses being unique to a particular concentration.

"If that's the case, a program starts to look an awful lot like a pathway."

Absolutely not a Pathway. The key distinguishing characteristic of a Pathway is sequencing over time. With the exception of course prerequisites (that we've solidly determined aren't pathways) there is absolutely no sequencing necessary to express a program or a program within a program (a concentration).

"Actually, do different concentrations lead to different credentials, or to the same credential with some additional object that conveys "this person had this concentration"?"

It is the SAME credential. Sometimes, the credential certificate may state a concentration, but most do not.

"Actually, do different concentrations lead to different credentials, or to the same credential with some additional object that conveys "this person had this concentration"? If the latter is the case, then is there any actual value in capturing which courses go with which concentration?"

There absolutely is a reason to capture this per-concentration course information--it's how students in a concentration plan their program and the basis of my assertion that concentrations can be effectively represented as programs within a program.

[siuc-nate]

No, the overall program leading to a degree has an array of courses that are sliced and diced across a set of concentrations although nothing precludes some courses being unique to a particular concentration.

This sounds like what I was trying to say/ask with that, though perhaps my perception had more overlap between courses (e.g. general education stuff).

It is the SAME credential. Sometimes, the credential certificate may state a concentration, but most do not.

One credential, with multiple tracks to earn it, then. It's hard to fend off the pathway analogies, but I'll try.

There absolutely is a reason to capture this per-concentration course information--it's how students in a concentration plan their program and the basis of my assertion that concentrations can be effectively represented as programs within a program.

I am inclined to agree. It's more specific than using a Collection, and has the convenience of already having been implemented in the schema. It also works for cases where there are offramp and other related credentials that are part of a program, but not the main goal of that program. We should probably throw that against all of the use cases/examples we've identified just to make sure it covers all of the bases.

[siuc-nate]

This came up in our Kansas meeting:

• Would it be a valid use case of a LearningProgram (as part of another LearningProgram) to be a listing of general education courses that get referenced from a variety of other Learning Programs? (I would think so)
• Would it be a valid use case of a LearningProgram (as part of another LearningProgram) to be a listing of a handful (say two or three) courses where the student must decide between those courses (e.g. pick one of two welding courses to fulfill x requirement), or is that level of detail strictly the responsibility of the pathway?

[jeannekitchens]

It is definitely a valid use case for multiple courses to be required or optional for many programs. This is well established.

The requirements for progressing through a Pathway are not the same as the requirements to enroll into a program. Didn't we discuss this at length in multiple meetings and that is why Condition Profile will be updated to support constraints?

[stuartasutton]

Would it be a valid use case of a LearningProgram (as part of another LearningProgram) to be a listing of general education courses that get referenced from a variety of other Learning Programs? (I would think so)

While it probably wouldn't be a problem considering general education as a sub-program, it's not necessary to do so. I have augmented the Stanford example to include ConditionProfiles to handle both general education and offered service course (i.e., courses developed to serve needs of the general student or needs of specific departments or colleges within a university that do not apply to the offering departments offered credential). See Stanford MS in Computer Science that we've reviewed (and will again today 2002-12-06): https://drive.google.com/file/d/1Y1x3NFM_1MVQ8Nhzd7dOrGWfjptUXwJf/view?usp=sharing

Would it be a valid use case of a LearningProgram (as part of another LearningProgram) to be a listing of a handful (say two or three) courses where the student must decide between those courses (e.g. pick one of two welding courses to fulfill x requirement), or is that level of detail strictly the responsibility of the pathway?

Yes this is a valid use case that is handled by the current proposal. While you frame this use case as a "LearningProgram (as part of another LearningProgram)", the nesting isn't relevant to the solution since everything that can be done with a LearningProgram can be done with a LearningProgram that is part of another LearningProgram. See this use case illustrated in the Stanford MS in Computer Science that we've reviewed (and will again today 2002-12-06): https://drive.google.com/file/d/1Y1x3NFM_1MVQ8Nhzd7dOrGWfjptUXwJf/view?usp=sharing

[siuc-nate]

Per our meeting on 2023-01-17: The Learning Program should be a simple inventory of what all is involved in the program; the conditions for earning a Credential should hang off of the Credential itself.

[siuc-nate]

Is there anything else to discuss with this one?

[philbarker]

I think we are done discussing it here, we seemed to reach consensus on the main point. We can close it as an issue, but still reference the conversation in ongoing work on Programs.