[Building Sakai] Moodle export/import suitability for Sakai 3
Keli Sato Amann
kamann at stanford.edu
Mon Sep 21 10:44:08 PDT 2009
Hello
I know Michael has written about Common Cartridge on his blog, but I'd like to provide my perspective on publishers, if it's useful. Prior to coming Stanford last year, I was working at educational publisher Cengage Learning, formerly Thomson. Each book we produced had content such as lecture outlines, ppts, website links, quizzes and test banks that were delivered as cartridges formatted for BB and WebCT. Often two or three different tiers of content were produced for best selling books, with the highest tiers containing video and ebooks, and were charged for accordingly.
The proliferation of new options ( D2L, Angel, Sakai and Moodle) gave rise to a new position--program manager for content delivery to course management systems, which I held for 9 months before I left. Sales reps would ask if we could get content to their customers who were using these newer systems, but it was always a challenge dealing with this. Each system had it's own proprietary format and there was a cost to convert to that format; in addition, the for-profit systems would charge us for delivery in their proprietary format, sometimes even if that format were not passcode protected. We didn't want to do those conversions in advance and for every system, because it might never get used, but yet we had to be able to turn around content within weeks. Several of these systems could take WebCT or BB directly, however Blackboard wanted to charge us for any cartridge we delivered in their format, even if we weren't used in their system.
Because of this, publishers want to be able to publish content in a single non-proprietary format, or at most two, since BB was unlikely to ever commit. This is why CC was of such interest to us--it would allow us to support emerging CMS, as long as those CMS supported it. Because CC is not password protected, it would be used for the lowest tier content--materials, pages, short quizzes, test bank which we would probably give away for free. Higher end content, such as ebooks, video, simulations, and homework systems, would be password protected on publisher servers (various publisher had different strategies for this; I believe Pearson was pursuing LTI). Thus, Michael's observation last May about publisher looking to make money on higher end content (http://sakaiblog.korcuska.net/2008/05/14/common-cartridge-is-cool-lti-is-even-cooler/) was spot on.
So where does this leave CC? It's always been a bit of a chicken-egg problem--two years ago, Angel was the only company to commit, D2L was dealing with the lawsuit from BB, and it was never clear from an outsider position what the open source systems were thinking. So it's hard for a publisher to commit when there's no guarantee on the other end and we'd probably be giving the CC content away for free. Nonetheless, I had started talking to my bosses about developing an internal process for producing CC for lowest tier content, as well as coordinating with colleagues who were working on a proprietary way of protecting our richer media and systems. Publishers are expected to give away some amount of content away as part of the adoption and CC would be a more cost effective way to do this. So there might be incentive for publishers to support this, maybe even spend a little money. But it's not all on the publishers; if publishers decide it's too expensive and simply don't support systems like Sakai, or only deliver BB cartridges, instructors start complaining that they can't get content like they used to, putting pressure on Sakai teams.
I have no idea where the thinking is at my former company on CC (or if they even have someone thinking about it). It might be good to see how publishers are feeling in these economic times. Regardless, CC might still be useful for other use cases, so I'm glad John is thinking about use cases holistically.
Keli Amann
User Experience Specialist, CourseWork
Academic Computing, Stanford University
----- Original Message -----
From: "Mark Norton" <markjnorton at earthlink.net>
To: "Michael Feldstein" <michael.feldstein at oracle.com>
Cc: "sakai-dev List" <sakai-dev at collab.sakaiproject.org>
Sent: Monday, September 21, 2009 6:15:51 AM GMT -08:00 US/Canada Pacific
Subject: Re: [Building Sakai] Moodle export/import suitability for Sakai 3
IMS-CC is very good at what it does: provide a very well defined
container for material to be published and distribute in inter-operable,
compatible manner. To do this, the CC committee created a limited
subset of capability and made extensions NON-COMPLIANT. I think Sakai
should support the CC spec, including 3.x, but we should acknowledge
that it is unlikely to provide comprehensive support, much less be the
basis of migration.
- Mark
Michael Feldstein wrote:
> For the cross-system use cases, I would lean heavily toward IMS Common
> Cartridge, not because it's technically better than the alternatives
> (I have no idea if it is or not), but because some of the bigger
> players are putting resources into developing support for it, which
> means it has a better chance of being a successful exchange format.
> D2L has announced that they support CC (import only at the moment),
> Blackboard (via Ray Henderson) has committed to full import and export
> of CC, it's on the road map for Moodle 2.0, and Pearson has been
> throwing resources into it.
>
> - m
>
>
> John Norman wrote:
>> Sean set me on a different line of thinking. Who would we be building
>> export/import for?
>>
>> Institution:
>> - as part of a year to year migration (export key elements from this
>> years course and reimport them to set up the outline of next years
>> course). This feels like we could/should handle it better with some
>> other solution
>> - as part of a migration from one system to another. In this case we
>> care about matching to the other system. This was in my mind when I
>> suggested we should look at Moodle, Bb and CC formats
>> - as part of a sharing initiative. Something like opencourseware, but
>> where the intent is that the visitor can download and use the course
>> in their system
>>
>> Publisher:
>> - as a way of publishing a 'pre-canned' course to multiple
>> institutions running multiple systems (our interest is primarily
>> import, but see below)
>> Individual
>> - as a way of 'taking their course with them' as they move from
>> institution to institution
>> - as a way of 'adopting' a course created by someone else at a
>> different institution (here the individual sharing is in a similar
>> position to the publisher above)
>>
>> Other???
>>
>> It strikes me that the amount and nature of what needs to move changes
>> according to circumstance. It might be worth describing which
>> scenarios we feel it is important to support.
>>
>> John
>>
>> On 17 Sep 2009, at 07:26, John Norman wrote:
>>
>>
>>> Several thoughts here. You don't say so, but I hope we are talking
>>> about Moodle as an export option (alongside IMS Course Cartridge and
>>> Native). I would hate to think we would loose information
>>> transferring from one Sakai to another because we use an export
>>> format that does not contain all of our concepts. Then in
>>> contemplating secondary formats for interchange with other systems,
>>> we need to consider how stable/how fast they change and the
>>> maintenance burden.
>>>
>>> I suspect it would be a lot of work, but it would be great to have a
>>> comparison that compared Bb export formats with Moodle with CC. I
>>> wonder if the IMS folk have this..?
>>>
>>> John
>>>
>>> On 16 Sep 2009, at 21:35, Speelmon, Lance Day wrote:
>>>
>>>
>>>> I could use a second pair of eyes on the Moodle backup format. I
>>>> managed to get the latest build of Moodle up and running and then
>>>> created a sample backup zip file. We are trying to determine
>>>> suitability of their format as an export/import format for Sakai
>>>> 3. Grab the sample below and provide any feedback you have on the
>>>> wiki page. Thanks, L
>>>>
>>>> http://confluence.sakaiproject.org//x/ERLtAw
>>>>
>>>>
>>>> Lance Speelmon
>>>> Scholarly Technologist
>>>>
>>>> On Aug 17, 2009, at 4:53 PM, Speelmon, Lance Day wrote:
>>>>
>>>>
>>>>> As we prepare to start working on a Sakai 2 -> Sakai 3 migration
>>>>> effort, I would like to help organize community contributions.
>>>>> There are a number of roles and skills that need to be filled and
>>>>> your participation would be highly valued.
>>>>>
>>>>> What can be done immediately:
>>>>>
>>>>> 1) Collaborate on defining the migration project plan.
>>>>> 2) Investigate LTI as an underlying mechanism for exposing Sakai 2
>>>>> tools within the Saki 3 portal.
>>>>> 3) Investigate Moodle's export/import architecture and file formats.
>>>>> 4) Develop a Sakai 2 Resources (i.e. ContentHosting) to Sakai 3
>>>>> JCR data conversion.
>>>>>
>>>>> If any of these tasks sound interesting or you have other ideas
>>>>> you would like to share, please use the wiki space below. Please
>>>>> take the time to declare your area of interest on the Contributors
>>>>> page.
>>>>>
>>>>> http://confluence.sakaiproject.org/display/KERNDOC/Migration
>>>>>
>>>>> Thanks! L
>>>>>
>>>>>
>>>>> Lance Speelmon
>>>>> Scholarly Technologist
>>>>>
>>>>> _______________________________________________
>>>>> sakai-dev mailing list
>>>>> sakai-dev at collab.sakaiproject.org
>>>>> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>>>>>
>>>>> TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe at collab.sakaiproject.org
>>>>> with a subject of "unsubscribe"
>>>>>
>>>> _______________________________________________
>>>> sakai-dev mailing list
>>>> sakai-dev at collab.sakaiproject.org
>>>> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>>>>
>>>> TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe at collab.sakaiproject.org
>>>> with a subject of "unsubscribe"
>>>>
>>> _______________________________________________
>>> sakai-dev mailing list
>>> sakai-dev at collab.sakaiproject.org
>>> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>>>
>>> TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe at collab.sakaiproject.org
>>> with a subject of "unsubscribe"
>>>
>>
>> _______________________________________________
>> sakai-dev mailing list
>> sakai-dev at collab.sakaiproject.org
>> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>>
>> TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe at collab.sakaiproject.org with a subject of "unsubscribe"
>>
>
> --
>
>
> Oracle <http://www.oracle.com>
> Michael Feldstein | Principal Product Manager | +1.818.817.2925
> Oracle Academic Enterprise Solutions Group
> 23A Glendale Road, Glendale, MA 01229
> ------------------------------------------------------------------------
>
> _______________________________________________
> sakai-dev mailing list
> sakai-dev at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>
> TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe at collab.sakaiproject.org with a subject of "unsubscribe"
_______________________________________________
sakai-dev mailing list
sakai-dev at collab.sakaiproject.org
http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe at collab.sakaiproject.org with a subject of "unsubscribe"
More information about the sakai-dev
mailing list