OK – so I’m a bit slow in responding to Michael Feldstein’s blog post from February 4: When It Comes to Content, Say “Yes” to Wrappers But “No” to Containers. OK – so at least it’s still the same century! In my defense, I just saw it today for the 1st time when Michael tweeted it as a classic post. The post over on Michael’s blog is closed to responses now – so, I’m posting my response over here:
Michael Feldstein posted about six months back some of the issues with using standards like Common Cartridge to package up content and move it around, namely that this wreaks all kinds of havoc with version control, updating of content and digital rights. Scott Leslie had some issues importing some Common Cartridges created on the OER project related in Michael’s post conducted by the Washington State Board of Community and Technical Colleges into Moodle at the time – which caused me reason to post a response to explain. Michael and I got into a bit of a back and forth on the topic of how content should best interoperate. In February Michael posted his view on “wrappers” being better than “containers.”
The issue of digital content interoperability in education is a deep and evolving topic that we all need to work on together – institutions, publishers, platform providers, OER advocates.
Basically I’m good with what Michael is proposing with respect to hosted content. He is right, I think, that the most common case in today’s web based world is that the original asset stays in one place and only changes in that one place. I’d like to get Michael’s specific ideas on the extensions to the IMS e-textbook task force – so, Michael, please pass along to Claude or otherwise get over to us.
The IMS community is definitely evolving Common Cartridges so that they are more containers of links (LTI or otherwise) to hosted material and applications. If people want to call that a “wrapper” than so be it – no difference to us. So, for instance, an alternative way to do the Washington SBCTC content would have been to host, and simply pass a Common Cartridge with a set of links back to the “learning objects” and applications (I don’t know that there are any applications in this particular case – I think not) that might be accessed individually or reordered. The advantage of doing this is that now a “user” can reorganize the links in the LMS. With Michael’s extension idea some of the objects could be passed with licensing rights and therefore edited locally (by the way, Common Cartridge authorization can handle a limited set of licensing scenarios today – I think what Michael is proposing is probably a relook at that – love it!).
There are a couple really nice features that come with thinking about it in this manner, i.e. the skinny cartridge (or wrapper ) of links:
(1) The links can be to any type of application – so rather than having to support exchange of data for all application types across all LMS’s, it can support any type of application – so we don’t have to have that functionality natively inside the LMS – but it could be any LTI-enabled app
(2) These links can come with metadata that enables some nice searching across hosted content sources from within the LMS
Why use Common Cartridge to pass this stuff around? No special reason other than it is a format that exists and is now supported in all the LMS’s – and used as an export feature in about 50% now (Instructure has export now – see http://www.imscert.org/ ). So, a teacher can do some rearranging and save and import to another system if needed. Common Cartridge does really work well – there were specific issues with the Washington SBCTC that were problematic: (1) they were using Angel to create the content and export it – for which Blackboard dropped support at the time and was therefore not up to date on Common Cartridge, (2) the Washington SBCTC guys never tested their cartridge with our free validator – we ended up doing that and manually fixing the broken ones a few weeks later, and (3) Scott was testing with Moodle – which was not certified at the time. It is now.
So, call it a wrapper or container – we don’t care – but there does need to be a way to pass around manifests of combined hosted and downloaded content and Common Cartridge does the best job at that in our world – and we are evolving it to make sure it meets the broad needs of the e-textbook world – I recently posted a view of what that world looks like: E-Textbook: What has really happened so far and what will happen going forward. But, Michael’s thoughts posted are quite consistent I think regardless of whether it’s called a wrapper or container or whatever.
Important notes: LTI links to multi-tenant hosted content and apps are great for publishers or other providers with the resources to stand up such applications. But, this is not easy to do. Also, some OER providers may desire to have something that is completely malleable. These are two important reasons to have packaging formats for passing content around and not force a hosted model on every provider.