Need to Support Use Cases that require a distinct and definable module or unit within a course or learning opportunity

[jeannekitchens]

From Jan 22 CTDL internal team running notes https://docs.google.com/document/d/1WquXThOId76NfYqFGS2-_jYIJJPfi_HIR7MpZKu5Hoo/edit#heading=h.z16du64ys9bx

Major Use Case: As a state agency, I need to publish the components of courses (considered by Arkansas to be modules) and align the components of the courses to competencies. This is a real use case with Arkansas. They have big, holistic publishing plans.

Currently, we have no way of doing this properly, meaning using a class that is for unbundling the components of a course.

E.g, ceterms:Module or ceterms:Unit

E.g., Definition: A distinct and definable module or unit within a course or learning opportunity.

Note: may or may not be part of a course or other learning opportunity- stand-alone modules are a very common use case.

Phil’s work with LT covers this https://k12ocx.github.io/k12ocx-specs/contentmodel.html

For now, the solution shows below. However, we will need to develop a solution that in the diagram below would show course’s hasPart pointing to CourseComponent or LOComponent. And, the Component pointing to the competencies.

[Curriculum Guide 2023-2024--NEW.docx]

(https://docs.google.com/document/d/1EJeYTHYiInmymUTL5fj7cVDUgSkte8Kg/edit)

[philbarker]

We need to be careful because the proposed definition would mean both ceterms:Course and ceterms:Module are parts of a LearningOpportunity that may or may not be offered as stand-alone units. At the very least we would need some strongly worded usage notes. I think we should insist 1 courses are larger than modules 2 programs are not divided directly into modules 3 courses are more stand-alone than modules: while modules may be independent they are designed to be part of something; courses are often part of something (in HE) but are designed to be self-contained and therefor can be part of several things (e.g. >1 program) and are often independent (outside HE).

We could go a long way to enforcing this with properties that have suitable domain and range, e.g. hasCourse domainIncludes Program ; rangeIncludes Course . hasModule domainIncludes Course ; rangeIncludes Module .

[siuc-nate]

Here's my thinking on it so far:

"Learning Chunk" is obviously just a placeholder (maybe), but I did throw in some other names that came to mind and sketched out definitions for them as well. Whatever we end up calling it, my thinking is that it can go down as many layers deep as it needs to, with each layer being associated with whatever chunk type concept the publisher wants to use.

Including things like "Objective" and "Outcome" in the list of chunk types probably risks confusion with cases where competencies are referred to as those things, but I could also see cases where chunks are small/granular enough to be nearly 1:1 with a given competency and that situation could be thought of as an outcome or an objective (maybe) - not sure how that would all shake out. Maybe we could leave those terms out of the concept scheme (to avoid general confusion) and let the publisher create/use them on their own if such a need arises.