OER Cycle
I think of it this way:
KT's view of a Life Cycle for Libre Learning
- Get --> Find
- Create --> Build and Adapt incorporating Remix
- Localise --> incorporated into Adapt to accommodate recontextualise, and other forms of adaptation similar to "localise".
- Remix --> incorporated into Create and Adapt above.
- License --> incorporate into Share but mention elsewhere too (e.g. in Adapt and wherever Remix is relevant e.g. Build and Adapt).
- Use: covers a lot of activities.
- Redistribute --> Share.
Visually-- it would be possible with colors or references to correlate Kim's diagram with the Get, Create, Localise ordering principle. What I like about Kim's diagramme is that it shows the process sequences in the context of multiple alternatives for usage.
- It could also be used as a template for describing scenarios (OER stories). Parts of it could be elaborated:
Expanding "Find"
- The Learning Design chapter would be interesting, but hard to scope.
I don't know if you saw Wiley had made changes to this page (http://www.wikieducator.org/Rationale_for_ToC_Changes_-_OER_Handbook), or is the straw dog version with that in mind?
I think listing out the places to "Find." More comments on the straw dog page.
Hi Seth, this is a partial response to your question about the difference between Composing and Adapting. In short, I think the Compose chapter could be more about the tools (they are mostly common to both) while the Adapt section could be more about the reasons for adapting (most notably localisation).
I know there is a time issue, but your question prompted the following diagram which suggests some possible changes.
OER development cycle
Including "Create"
"Quality" replaces "Evaluate"
Navigation with "license" as a filter
Libre Knowledge Resources Development Cycle
The educator (or learner), with a purpose in mind, starts by looking for resources (Find), then Shares and/or Uses the resource immediately, or perhaps Evaluates before Using or Modifying it or deciding to Build something else from scratch.
Composition tools are shared by both Modify and Build.
During Composition one may Build components from scratch, Modify existing components, Find new components and modify them while Composing.
I used Modify rather than Adapt since Adapt does not include simple corrections or changes which are not "adapting" to the context (e.g. enhancing the wording or sequencing of activities, etc.).
Composing includes Building from scratch (possibly including additional Find and Adapt cycles). I would be happy to add Create to form a Create-Build-Modify cycle within Compose.
There is a link between Find and Share - some common tools (e.g. RSS, tagging on a blog, etc.).
I think there is merit to the new diagram. However, I think for educators (or learners) just beginning to compose OER, a more linear model is best. There is also the time issue, and I get the sense that most who are participating on this project want the lifecycle locked down at this point.
>>In short, I think the Compose chapter could be more about the tools (they are mostly common to both) while the Adapt section could be more about the >>reasons for adapting (most notably localisation).
Given that, should "Mobile Access" be moved from Compose to Adapt? Also, would that mean "Composing Learning Resources from Multiple Sources" should stay where it is?
The printed book will be linear with the option to skip to required sections. The online version has the navigation templates. It might be useful to have a navigation template with links to relevant sections in the separate cross-cutting chapters) - perhaps a table at the foot of the page with relevant section links and comments.
Mobile Access is a cross-cutting concern. Move it into its own section/chapter.
"Composing Learning Resources from Multiple Sources" should go directly under "Compose" which could have sub-sections - see thoughts on structure.
>>The printed book will be linear with the option to skip to required sections.
It's not just a matter of subject material being presented in a linear fashion, but conceptually linear. In the introduction we do say that readers can jump to any point. However, to accommodate educators or learners who don't have much experience in learning object creation, I think the OER lifecycle needs to be fairly simple (but as you say, only simple enough) for them to understand.
I have also posted more on "thoughts on structure" Talk page.
