Schedule

This page describes functionality and features currently beyond the scope of the Sakai/OSP 2.5 release.

Amsterdam OSP Strawman Proposal

"Blue Sky" discussions begun at the Sakai 2007 conference in Amsterdam are documented here.

Requirements

Specific requirements are written up in JIRA and summarized in the Proposed OSP Requirements (future) page (currently under review).

Background

The current crop of courseware tools in Sakai (namely assignment and discussion) makes it difficult to "remix" content from each of those tools into new content. It is difficult to publish a portfolio that reuses classroom content.

The centralization of content in Sakai course sites means that an institutional decision to delete that site or means that potential portfolio content is lost to the student.

"Folders" are not an optimal metaphor for organizing student content. It has been recognized that a tagging metaphor for organizing content will allow portfolio owners to organize their data better, adding additional tags over time to reflect their new ideas.

"Blue Sky" Data Flow Diagrams
A workflow through a class journal with optional, goal-based assessment	General Data Flow Diagram describing a combined portfolio/courseware system	A typical workflow scenario through assignments...note that the workflow involves messaging between two systems....
A workflow through a discussion...does it look like email? It does to me!

General Data Flow?

Sakai Courseware tools and the OSP portfolio system have been designed as relational databases to allow a minimum of data duplication while giving users different roles and permissions to interact with their content and data. Students and faculty have expectations about how different tools should be used to organize data into familiar structures with implicit rules for interacting with the data in those tools. The design of these tools have not not allowed a lot of interplay between the tools. It is difficult to publish a portfolio that reuses classroom content (ie: assignments and discussion threads) that the student otherwise has access to view and manipulate in the limited manner the tool allows.

Furthermore, if a student enrolls in another institution or another class that doesn't use the same instance of the courseware, the data from the different classes can not be combined to create new content.

What is needed is a student centered content management system that serves as the student's virtual backpack and their main platform for lifelong learning. The interface between their content management system and the classroom management tools deployed in a LMS has not yet been designed.

This data flow diagram is intended to describe the flow of information into, out of and within a distributed, networked LMS that has two main components: course content and student content management tools.

Channels - Subscriptions to a class (or learning group).

There is a lot of data flowing back and forth between the Courseware server and the personal space...If this was all done in Sakai then I suppose it would all happen through various API's. If, on the other hand, the personal LMS was not built on Sakai, then there would need to be a way for a student to "subscribe" to a course and send/receive their goals, activity descriptions, content and assessment data. I am calling that subscription to a set of coursewarish services a channel in these diagrams. I am thinking that the personal content system would periodically "sync" with the course server, getting new content of various kinds:

• Goals - Sets of Learning Outcomes...it should be the beginning of all instructional design, so a teacher should be planning ahead. Students will also be able to share their learning goals with the teacher.
• Activity Descriptions - The list of assignmenmts, discussions, portfolio reviews, etc that will be occurring in the class...as well as the associated due dates, start dates, etc that follows with them.
• Content - Rather that storing assignments, discussions, portfolios, blog entries, etc in different formats that can't play nice together, we will need to have a common place where all of the content lives in a standardized form so we can re-use it.
• Assessments - More standardized content related to who assessed what activity, how (rubric) and when of asessment data. Peer reviews, formative and summative assessments all can go here.
• Reports -

Assignment Data Flow

This data flow diagram illustrates the how students and teachers would interact in a distributed LMS to carry out the traditional graded assignment workflow.

A frequent use of courseware is to assign work to students, collect that work from students, assess the work and release the grades to students. In most courseware systems, this is all done in one tool. The Assignment tool (or the assignment and gradebook tools) "live" in a course. The design of courseware is mainly to facilitate the instructor's ability to manage the course.

An alternative approach would be to distribute the various transactions between two systems, the courseware system and a learner centered platform. Each set of tools would be designed and configured with the primary user's interest in mind.

The student would receive a message in their "inbox" with the assignment instructions, learning outcomes and rubric for the assignment.

The student would then do the work, saving their "drafts" in their own system and eventually sending back a response to the assignment with their work attached. Note that a copy is sent to the instructor, with the original content still on the student system.

The teacher would receive the student work in her "inbox" and (assuming that there is to be no formative feedback) evaluate the work against the rubric and release the grades back to all of the students.

There is a lot of duplicated data in a system like this which may end up causing issues for storage. However, this does allow each learner to retain a record of all of the assignments, work and assessment data that occurred in their classes...forever if they wish to. Similarly, this frees the institution from maintaining the course indefinitely "just in case" students need access to their data.

An important assumption is that a system that can engage in this sort of messaging becomes standardized, allowing students to remix and reuse their content in multiple classes at multiple institutions.

Discussion Workflow

This data flow diagram illustrates the how students and teachers could interact in a distributed LMS to engage in a group discussion.

A discussion tool is another typical tool found in courseware. The discussion tool is used to allow a teacher to set of "forums" or "threads" of conversation related to the course material. Like the assignment tool, it also lives and dies with the course worksite.

An alternative approach would be to distribute the messages between the courseware system and a learner centered platform, much like email systems do. The difference between the a distributed leaning management system discussion and traditional email systems would be that this content would be stored in a standardized format that allowed users to easily re-use the content in their other courses or portfolios.

Again, once the course ends or the student leaves the institution, they have the option to keep a copy of all of these discussions for there own use, much like they do with email.

Again, there is a lot of duplicated data in distributed system like this which may end up causing issues for storage. However, this does allow each learner to retain a record of all of the discussions that occurred in their classes...forever if they wish to. Similarly, this frees the institution from maintaining the course indefinitely "just in case" students need access to their data.

An important assumption is that a system that can engage in this sort of messaging becomes standardized, allowing students to remix and reuse their content in multiple classes at multiple institutions.

Class Journal Workflow

This data flow diagram illustrates the how teachers and students would interact to create, discuss and assess a private (student to teacher) class journal. Periodic review of student blogs (chronologic, personal, reflective portfolios) is likely to be a common interaction style that many teachers would find useful as an venue for formative feedback.

Blogs frequently allow readers (in this case the course instructor) to leave text comments (which this would also support). However, this interaction style would leverage the ability of students and instructors to identify learning outcomes for the journalling process and allow assessment of each blog entry on an ad hoc basis for formative assessment purposes.

Student blog posts would appear as messages in the instructor's inbox. Instructor's would periodically read the blog posts and send back either plain comments or comments with assessments (as related to tagged goals). An important feature of this interaction style is that it supports the idea that "knowledge is emergent" by allowing students to add new learning outcomes to their Goals and to tag their blog posts with those tags. Assessment of student learning, then, can be done in response to student Goals and Faculty Goals (related to the original activity description).

Again, once the course ends or the student leaves the institution, they have the option to keep a copy of all of these posts, assessments and comments for their own use, much like they do with email.

An important assumption is that a system that can engage in this sort of messaging becomes standardized, allowing students to remix and reuse their content from other activities in multiple classes at multiple institutions.

Long Term Issues

1. Integration of social software
2. Longitudinal persistence of different views of portfolio data not to be lost with the ending of the course. Policy and software to make data portable and persistent in order to represent learning over time.
3. Standardizing content so it can be easily moved and transformed. Need uniform data structures/schema to collect data from content. An assignment is a collection of instructions, goals, inline text, attachments, reflections, and ratings of goals. There may be tools in Sakai that already support this. Consider the LAMS heuristic. Stick with open standards (RSS, etc.) Possibly reduce this requirement to making OSP have RSS capability.
4. Advocacy work within the larger Sakai environment assignments, interoperability, social networking, web services, user interface.
5. Integrative thinking in developing strategies for long term OSP development. Pulling things back and forth between current and future versions to manage immediate versus future requirements.