LabXchange 2018-03-27
- 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.
- Use OEP? Yes, but timing considerations:
- 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)
- Units
- Proposed Vision
- 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.