Development of this proposal is being funded by Harvard LabXchange and the Amgen Foundation, with significant in-kind contributions from edX.
...
- ID - globally unique identifier (probably UUID)
- Name
- Description
- Owner - who (person or organization) legally owns any original content in this Collection
- Author - who is credited for authorship of original content this Collection contains, if different
- Permissions - ACL that defines what users/groups have permission to view and/or edit its content.
- License - what content license is applied to content in this Collection.
- For ease of content reuse internationally, for any content that’s not “All Rights Reserved” or “Public Domain”, the use of a Creative Commons license should be encouraged.
- Blockstore does not enforce licensing, but high-level software that uses the Blockstore may wish to - for example, prohibit “View OLX Source” for units that are not under an open license, and provide shortcuts for copy-on-write modification of units that are.
- Tags (tags are not stored within Blockstore, nor is Blockstore aware of them, but Collections must be taggable via some external tagging service)
...
- A physics teacher searches all publicly available Open edX content and finds several videos about the second law of thermodynamics, as well as an interactive animation that explains entropy. She creates a “Playlist” consisting of three video Units and an HTML Unit that contains the animation.
- The “playlist” application internally creates a Collection containing one ContentSet to represent this playlist. The ContentSet contains four Links (one to each Unit). Separately, the playlist application records the order of the links.
- If any of the Units used in the playlist get changed or deleted, the Playlist app will receive a notification and can choose to update the Playlist by updating the Links in the ContentSet or not.
- A typical Open edX course tree could be modelled using ContentSets plus metadata: A root ContentSet would contain Links to each “chapter” ContentSet, which would each contain Links to each “subsection” ContentSet, which would each contain Links to each Unit.
- This is not saying courses should be modelled that way, but is pointing out the flexibility. In particular, courses modelled as ContentSets could be cyclic graphs as far as Blockstore cares, potentially even worse than today’s course DAGs in terms of edge cases.
- A fully adaptive course may not define a hierarchy of content, but rather consist of a ContentSet containing a vast pool of content, and a machine learning-based adaptive algorithm that constructs a unique “pathway” through the content for each learner. (Learner 1 sees Intro > What are Objects > Subclassing > Test, while Learner 2 sees Intro > Advanced Topics > Advanced Inheritance in Python > Test > Advanced Test).
TODO: Is this sort of model useful, or do we really just need a way to indicate that certain content is in use for some application, without any attempt to model structure?
TODO: Should ContentSets support (optional) ordering of the links they contain? It seems like an extremely common use case, and would make a lot of things (like modelling playlists and course trees with ContentSets) cleaner. If ordering etc. is always kept externally, then we may not need the ContentSet concept at all.
...