Course Cartridges, Requirements, and Integration
Well, it's been a busy week in spite of not being out in Ann Arbor for Sakai Integration Week. I miss the geek-intensive meetings we used to have in previous years, but Chuck tells me that he'll be setting something up soon, perhaps connected to the Atlanta Conference.
Course Cartridge
Some may know that I've been working with Zach Thomas and others on moving data around for Sakai. This has several aspects to it including archiving, data migration from other CMS environments, portable portfolios, Open Courseware support, and IMS Common Cartidge. You can learn more about this at the Migration Confluence Site but what I want talk a bit about is Common Cartridge (CC).
For years, the major textbook publishers (Pearson, Thomson, McGraw-Hill, etc.) have made their content available electronically and often augment a textbook with on-line material. Professors who select one of these books can get a "course cartridge" which is a piece of data enabling content access from a course environment. Many of the leading course environments support such things (BlackBoard, WebCT, Angel, etc.)
Early last year, Sakai hosted a meeting out at Foothill College with publishers to discuss support for this kind of content in Sakai. Chuck Severance suggested that what was needed was an industry standard rather than writing custom access for each CMS and volunteered IMS to manage it. Well, this led to a course cartridge guideline last year, and the development of a specification this year. The spec isn't done and won't be until next year, but the key aspects of it are firming up nicely. IMS gave an industry briefing on it last week in Lynnfield, MA.
The course cartridge specification is a profile of IMS Content Package. That means that it perscribes EXACTLY how content package is used to create a common cartridge. It's very specific in what it allows and what it doesn't Data types are limited, but include most of the things that people would like to distribute as content: web materials, learning objects including SCORM, assessments based on QTI, etc. Content can be either in the package, or accessed remotely. Provisions are made to define authorization and the Tool Interoperability Guildlines (also jump started by Sakai) is used.
While the spec has a ways to go, Zach has already got prototype code up and running as part of the new archive module additions in 2.3. This was based on demoware shown at alt-i-lab last June in Indianapolis. With today's code freeze, archiving functionality is final, but we'll be testing it against sample cartridges and tweak it up for robustness. Meanwhile, I'll be attending the CC spec meetings and helping the Sakai development team to stay on track for conformance. I think this will be a very important feature in the future and it's very cool that Sakai is out in front of it.
Requirements WG
Mara Hancock stepped down as the chair of the Sakai Requirements group after doing an outstanding job of establishing this group. I led my first meeting of the group today. There was a lot of discussion on how the process has worked to date and how it can be improved.
Simply put, the requirements group has the job of getting people to make suggestions and working with those people to refine them into a form that will encourage designers and developers to step up and work on it. Refining them means collecting use cases, extracting requirements, and perhaps guiding early design efforts. Naturally, I'm open to any ideas any of you may have in making this process better. Sakai is a community of volunteers and generating work enthusiasm is a big part of getting things done.
Part of promoting this process will include several events at the up coming Sakai Conference in Atlanta. The REQ-WG will report out on the process to date, examine some success stories, and explain how the Sakai development process is very different than developing a commercial product. We are also exploring the idea of have a requirements writing workshop, perhaps in conjunction with the UI Book Camp. All TBD at this point, but interesting.
Integration Workshop
I'll be presenting a Sakai Developer Workshop focused on integrating Sakai into enterprise environment on Oct. 16 - 18, 2006 in Phoenix. There are still places left if you are interested in attending.
Meanwhile, I'm working on finishing up the material for it. I'm writing a small tool that displays a list of Sakai sites. If you click on one of these links, you see a page with all members of that AuthzGroup. You can then click on one of the group members to see their full name and email address. Besides illustrating how to use various Sakai services, this application will serve as a test harness for workshop participants to write Group and User providers. These providers will interface to a dummy student information system that I've put together in a MySQL database that will run locally on a LAN. I'm writing the sample providers now.
Part of the course will also include writing an application to populate course sites using SakaiSpeak (our web services system). While the app could be written in PHP, Perl, or Ruby, we'll probably do it in Java since it's already a requirement for the workshop. The test application (MemberTool) will show new course sites as they are added by the webservice application.
- Mark
Course Cartridge
Some may know that I've been working with Zach Thomas and others on moving data around for Sakai. This has several aspects to it including archiving, data migration from other CMS environments, portable portfolios, Open Courseware support, and IMS Common Cartidge. You can learn more about this at the Migration Confluence Site but what I want talk a bit about is Common Cartridge (CC).
For years, the major textbook publishers (Pearson, Thomson, McGraw-Hill, etc.) have made their content available electronically and often augment a textbook with on-line material. Professors who select one of these books can get a "course cartridge" which is a piece of data enabling content access from a course environment. Many of the leading course environments support such things (BlackBoard, WebCT, Angel, etc.)
Early last year, Sakai hosted a meeting out at Foothill College with publishers to discuss support for this kind of content in Sakai. Chuck Severance suggested that what was needed was an industry standard rather than writing custom access for each CMS and volunteered IMS to manage it. Well, this led to a course cartridge guideline last year, and the development of a specification this year. The spec isn't done and won't be until next year, but the key aspects of it are firming up nicely. IMS gave an industry briefing on it last week in Lynnfield, MA.
The course cartridge specification is a profile of IMS Content Package. That means that it perscribes EXACTLY how content package is used to create a common cartridge. It's very specific in what it allows and what it doesn't Data types are limited, but include most of the things that people would like to distribute as content: web materials, learning objects including SCORM, assessments based on QTI, etc. Content can be either in the package, or accessed remotely. Provisions are made to define authorization and the Tool Interoperability Guildlines (also jump started by Sakai) is used.
While the spec has a ways to go, Zach has already got prototype code up and running as part of the new archive module additions in 2.3. This was based on demoware shown at alt-i-lab last June in Indianapolis. With today's code freeze, archiving functionality is final, but we'll be testing it against sample cartridges and tweak it up for robustness. Meanwhile, I'll be attending the CC spec meetings and helping the Sakai development team to stay on track for conformance. I think this will be a very important feature in the future and it's very cool that Sakai is out in front of it.
Requirements WG
Mara Hancock stepped down as the chair of the Sakai Requirements group after doing an outstanding job of establishing this group. I led my first meeting of the group today. There was a lot of discussion on how the process has worked to date and how it can be improved.
Simply put, the requirements group has the job of getting people to make suggestions and working with those people to refine them into a form that will encourage designers and developers to step up and work on it. Refining them means collecting use cases, extracting requirements, and perhaps guiding early design efforts. Naturally, I'm open to any ideas any of you may have in making this process better. Sakai is a community of volunteers and generating work enthusiasm is a big part of getting things done.
Part of promoting this process will include several events at the up coming Sakai Conference in Atlanta. The REQ-WG will report out on the process to date, examine some success stories, and explain how the Sakai development process is very different than developing a commercial product. We are also exploring the idea of have a requirements writing workshop, perhaps in conjunction with the UI Book Camp. All TBD at this point, but interesting.
Integration Workshop
I'll be presenting a Sakai Developer Workshop focused on integrating Sakai into enterprise environment on Oct. 16 - 18, 2006 in Phoenix. There are still places left if you are interested in attending.
Meanwhile, I'm working on finishing up the material for it. I'm writing a small tool that displays a list of Sakai sites. If you click on one of these links, you see a page with all members of that AuthzGroup. You can then click on one of the group members to see their full name and email address. Besides illustrating how to use various Sakai services, this application will serve as a test harness for workshop participants to write Group and User providers. These providers will interface to a dummy student information system that I've put together in a MySQL database that will run locally on a LAN. I'm writing the sample providers now.
Part of the course will also include writing an application to populate course sites using SakaiSpeak (our web services system). While the app could be written in PHP, Perl, or Ruby, we'll probably do it in Java since it's already a requirement for the workshop. The test application (MemberTool) will show new course sites as they are added by the webservice application.
- Mark
posted by Mark J. Norton at 3:09 PM
0 Comments:
Post a Comment
<< Home