Clarify limitations of current Modulestore and Content Libraries
- Scaling issues
- Coupling xblock runtime with store
- Black-box ?
Planning to reuse
- XBlocks
- OLX
Agenda
- Process
- Flesh out Collections vs Unit vs Sequence
- Clarify ownership use cases
- Semantics versus structure - flexibility
Process
- Use OEP? Yes, but timing considerations:
  - Braden: Wants to hash out some of the high level details first.
  - Ned: The more public, the better.
  - OpenCraft doesn't have a contract for LabX yet. Braden doesn't want this public with OpenCraft's name on it before the contract is in place.
  - Gaurav doesn't want it public at this point because they're trying to set up the organization in house first.
    - Ned: Can we take "LabX" out of it and talk about it as an Open edX design discussion?
  - How does adaptive play into this?
    - Nimisha: We need to have requirements, but they don't need to know the details on this yet.
  - We'll check in on Monday about communicating this.
Collections vs. Units vs. Sequence
- Proposed Vision
  - Units
    - "Normal" chunk of content, smallest useful piece.
    - Maps best to a vertical in current edx-platform (could even use the vertical block as implementation)
    - Single XBlock, or a few together (e.g. preamble, video, question).
    - Could have children (implementation detail)
      - For our purposes, smallest chunk.
    - Q: Are Units shareable?
      - A: Yes. Also can see OLX of the Unit via a "view source" type of thing. Not necessarily built into the app.
    - Q: Is UI included in proposal?
      - A: Some UI to import/export, but the focus of this is API.
    - Unit is an addressable piece of content that can be referenced and used in many different places.
  - Collection
    - Simple folder concept, not dynamic/tagged. Item is only in one Collection at a time.
    - Ownership, licensing, permissions can be determined at Collection level.
    - Simple organization scheme to make things easier for content authors.
    - Not planning to build the UI for this.
    - Examples:
      - HarvardX Physics Problem Bank
      - Joe's Course on PCR
      - A bunch of Videos
    - Maps to a Library in the current Studio, but with the ability to hold more different types of content.
    - Historical note: "Collections" term was originally part of the v1 for Content Libraries proposal, that indicated a subset of a Library.
  - Sequences
    - Short, linear pathways of content.
    - LabX doesn't have courses, but small, linear, curated paths.
    - Marco: Today: The fact that subsections in edx-platform are linear (and that's all that's available) is a limitation Product has run into. If you were to introduce the notion of a type of sequence (linear, adaptive, choose-your-own, explore, etc.)...
      - Sequences in the proposal are the "dumb" version. Adaptive would be implemented by hitting units, and not deal with Sequences.
      - Alternative can be to make it a more general interface and have multiple sequence types.
      - "Pathway" as a term? (many layers, Marco: everything is a pathway)
      - Pathway as the general thing, Linear Sequence as the more specific.
      - Dave: make sure the API and its promises are clear and forward thinking depending on which way we go with Pathways vs Sequences.
      - Determining where things are stored (based on DDD exercises): Content authoring vs Content repository vs Content management
        Q: Should Sequences be stored alongside BlockStore?
      - Braden: Abstract Sequence - what does the blockstore need to be concerned about?
        Type (linear, etc.)
        Storage/settings (order of units, for linear sequence)
        Units that may be referenced
      - Marco: What vs. How things are consumed (units vs. pathways/seq)
Ownership
- Sequences can have Units from different Collections
- Publisher associated with a Collection
- Nimisha: Can ownership be a tag built on RDF primitives? Or more generic in general.
  - Braden: Permissions vs. Ownership in the legal/branding sense. For BlockStore, want to have permissions system be simple.
  - Nimisha: RDF relationships so that we don't have to hardcode one or two layer organizational layout. Can build onto that relationship when sharing.
  - Marco: If it could be Organizations v2, who can author, who can see? (Most of what we have today rolls up to Orgs. It does currently hurt us that we don't support sub-orgs.)
- Ned: Proposal doesn't include what operations are supported on these data types.
- Relationship within the Org
- What happens when you create a Sequence of Units from different Collections?
  - Content could either be public or private.
  - Public content would have license, and be discoverable. Usable in a read-only way.
  - Q: No overrides?
    - A: To keep things simple, read-only or make a local copy if license allows to modify.
    - Marco: We ran into this on libraries. There is a lot of power that would be useful here.
    - Braden: XBlocks tries to do this with settings scope.
      - In the longer term, want to be able to do overrides at the sequence scope or higher level.
- Braden: look at Git (fixed hierarchy) versus Gitlab (flexible hierarchy)
Publishing
- At what granularity? Sequence-level or Unit-level?
- LabX requires both use cases.
Ned:
- Why only units and sequences? Do we need more?
- Same issue with organizations.
- Should we consider having a more flexible and abstraction structure? Or would that be over-engineering?
- Braden: OEP input on the use cases.
Next Steps:
- Braden will create a new Google doc, consolidating the latest thoughts, sharing with this group.
- We'll expect an email from Gaurav and/or Braden early next week regarding opening up the discussions over an OEP proposal. The OEP may remain in a Draft state while things are being fleshed out.

Browser not supported