Are LearningPackages 1:1 with Course or Library?

[ormsbee]

I've been thinking of LearningPackages as a more generic version of a Course or Library or future modular learning collection of content. I've had this vague notion that they weren't really 1:1, but I couldn't really pin it down very well.

At the same time, I think we've all been struggling a bit with the modeling of import/export of content dependencies, like libraries and (soon) taxonomies.

So maybe LearningPackages are a layer above that–i.e. LearningPackages contain courses, libraries, taxonomies, etc. There are still shallow/partial copies for those things that come from libraries outside of the LearningPackage. But I think one of the nicer aspects of this is that we can get to a place where you're importing your library at the same time as your course–i.e. it's linked together in a more natural way. We can still have a separate concept of a Library for UX purposes if we want, but LearningPackages become a place where a big bag of content lives, including different groupings of that content.

(This was the five minute version because I wanted to write it down before I forgot. More to follow later...)

[ormsbee]

Key questions:

1. Is there a fundamental difference between re-using a problem from a library vs. from another course?
2. Are most libraries created to be shared across courses, or reused by multiple runs of the same course?

[ormsbee]

Or maybe LearningPackages are 1:1 with new libraries, and it's the libraries that can contain courses and all manner of other things. We've talked about that direction in the past, where libraries eventually eat the world, though I'm not sure what that looks like from a UX perspective.

[ormsbee]

Or maybe LearningPackages are 1:1 with new libraries, and it's the libraries that can contain courses and all manner of other things. We've talked about that direction in the past, where libraries eventually eat the world, though I'm not sure what that looks like from a UX perspective.

After talking with @jmakowski1123, I think this is where we want to go with this for now. The main short-term takeaway is that we should not associate LearningPackage directly with a LearningContext key (like a CourseKey), since it should be capable of holding multiple Learning Presentations within it.

[ormsbee]

Other thoughts:

A LearningPackage could represent a namespace that's shared by library-like content and multiple runs of the same course (as opposed to multiple courses), and the LearningPackage itself could be namespaced into an org.

So say the LearningPackage key is Core-Contributor-Intro. It's in the Axim org. It has multiple CourseRun objects in it, and those have keys like 2023, 2024.

Then we could look up the course course-v1:Axim+Core-Contributor-Intro+2024 by mapping it through those layers.

Maybe PublishableEntity should have a namespace in addition to a key, instead of bolting them together into the key directly?

[ormsbee]

Another thought–having LearningPackages be cross-run would save us space because we wouldn't have to clone the RawContent (files and uploads + raw OLX). It would also make the process of creating a re-run much faster.

[ormsbee]

Another thought:

We could have one LearningPackage contain all runs of the same course. Another LearningPackage to contain a library (or multiple libraries). The Course LearningPackage could also contain things that are not directly attached to the course tree.

A LearningPackage could also contain multiple things that we call "libraries" today.

[ormsbee]

Current thinking: LearningPackages are 1:1 with the new-style Libraries we're making (that can contain many older v1-style libraries). But LearningPackages are not 1:1 with LearningContexts in general (e.g. course runs). The current thinking is that we will eventually be able to hold the content for multiple course runs in the same LearningPackage.