Scott's Workblog

scott.bradley.wilson@gmail.com


attention!
This blog has moved! Go to my new blog!


print this article (opens in new window) view printer-friendly version (opens in new window)

IMS's three-pronged strategy

Now a lot of discussion around IMS is about its policies, politics, membership, processes and so on, but I'm not going into any of that here; for now I want to focus on specifications. (Note also this is a personal reflection, and doesn't necessarily represent the view of JISC or CETIS)



IMS currently sets out its stall as offering three key "products" in its specification portfolio; together they make up its "Digital Learning Services Standards" portfolio.



Common Cartridge



The first product is the IMS Common Cartridge. I remember this originating in discussions way back as to whether there should be a SCORM-like profile of standards (packaging, metadata, runtime and so on) that was better suited to Higher Education. Its come a long way since, and has gathered a lot of influential support. However, ultimately it is still a means of putting a bunch of web pages into a zip file to import into an LMS, which seems increasingly an odd thing to do.



CC does add some interesting capabilities - it adds the QTI (Question and Test Interoperability) specification to the profile, enabling automated assessments along with content (something ADL was considering for SCORM a few years back but never got around to), and it also adds a capability for adding "tools" using a version of the IMS Learning Tools Interoperability specification (more on which later). However it misses out things like SCORM's tracking functionality and CMI runtime, which have been a major selling point of SCORM.



Overall CC is an odd mix (one of my colleagues referred to it as the "curate's egg" specification) but is quite likely to gain some traction with publishers and commercial LMSs. But what will the impact be? I'm not convinced a market for common cartridges will open up in HE in the same manner as occurred in commercial training with SCORM; they really are quite different. However, IMS is putting a lot of effort into marketing CC to get adoption, so I remain open minded.



For the moment the key question is whether OER and CC are a natural fit - clearly the UK's Open University considers it an option.



Learner Information Services



IMS Learner Information Services is the latest revision of the IMS Enterprise specification, which was one of the first IMS specifications and the first I was personally involved in. IMS LIS, like its predecessor, is focussed on the connection between an LMS and a student record system; this means being able to provide groups and users to the LMS and to handle reporting back for things like final grades or tracking data. LIS extends Enterprise with new services for areas like course structures (a bit similar to XCRI, though not compatible with it) and continues the service-oriented approach that started with IMS Enterprise Services 1.0.



However, IMS LIS also plans to add batch-file bindings that would also enable REST services; this is important, as some of the most successful applications of IMS Enterprise have focussed on simple REST services and batch processing, and I'm glad to see IMS is recognising this and providing official support.



Learning Tools Interoperability



IMS LTI v2.0 is a specification for enabling LMS's to include external applications running in iFrames that can communicate with the host LMS for things like user information. (There isn't a page for v2.0 yet, but there is a description of LTI on this page)



If you've been following this blog you'll know that I've been contributing to the W3C Widgets familiy of specifications, and have been keen to point out that the IMS specification is rather similar, begging the question as to why IMS is bothering to reinvent this particular wheel. Part of the reason is historical - IMS LTI started earlier than W3C's activity (although that itself is based on earlier technologies, such as Apple Dashboard Widgets and Yahoo! Konfabulator) and so has had time to diverge from common practice. Its also harder to backtrack on the legacy of its "version 1.0" which was really an exploration of a possible common extension mechanism for (back then) WebCT and Blackboard (and later Sakai). Another part of the reason is that many IMS members are not really that well connected into web standards generally, and even though I personally prompted the IMS working group to look into Widgets they never really managed to connect it with what they were working on.



I think IMS is putting a lot of pressure on LTI to succeed, although I think its fundamentally misconceived. For example, the current IMS LTI 2.0 document set consists of 20 word documents covering everything from inter-widget messaging to APIs for passing "outcomes" from widgets to the LMS - most of it involving lots of SOAP and WSDL. Using the W3C Widgets specification I reckon this could be whittled down to one or two very basic documents for things like common education vocabularies and how to use Widgets with an open API on the LMS end (or more likely, just IMS LIS with a REST binding). Already I've seen a lot of European projects working with W3C Widgets and Google OpenSocial to deliver IMS-LTI-like functionality; we've also been working with Sakai 3 and Moodle to integrate both Widgets and OpenSocial applications. Perhaps the main value IMS could contribute would be to sort out the REST APIs that Widgets could call to enable tracking.



Its unlikely that IMS would embrace W3C for LTI for a number of reasons, mostly that the whole approach doesn't just invalidate most of the effort on IMS LTI 2.0, it also calls into question the whole "DIgital Learning Services" strategy: if we used web standards, plus a REST API for things like cohorts, would we even need IMS Common Cartridge or IMS LTI at all? From this perspective, the IMS strategy seems less about opening up education systems so much as supporting an education technology silo into which a few suppliers can offer services with limited external competition. After all, who apart from a few established players in the HE sector is going to implement those 20 IMS LTI documents?



The Missing Specifications



As well as what is IN the IMS strategy, its worth considering for a moment what's OUT of the strategy:



IMS Learning Design is one of the most widely discussed specifications in a European context (or certainly seems to be in the circles I move in) and yet is completely absent. It had some discussion in relation to a K-12 profile of Common Cartridge, but I don't think this progressed anywhere. Its especially unusual that IMS isn't promoting any further development or marketing for LD, given that quite a few of the entrants to its own Learning Impact awards were using LD.



IMS ePortfolio was a relatively recent specification, but was released with some fundamental problems. So far there has been insufficient interest from members to fix it, and CETIS has switched its efforts to looking into practical interoperability between ePortfolio applications using Atom feeds (see PIOP).



IMS QTI 2.x is largely completed, but was recently withdrawn by IMS and then reinstated after a number of complaints. I think its fair to say IMS doesn't really know what to do with it, given that IMS CC uses the older 1.x version of QTI.



Finally, IMS has a number of specifications that really should be retired - IMS LIP, IMS SSP, IMS RLI, IMS VDEX come to mind.



The Rub?



Overall the IMS specifications seem oddly out of step with the wider web. There is still an adherence to SOAP and WSDL doctrine that has slid rapidly into the Trough of Despond elsewhere. Where REST APIs are considered, they are a bit of an add-on rather than at the core - IMS specifications are not based on web architecture, irrespective of binding. And, most critically, there is a big gap between IMS and web standards, as evidenced by the disconnect between IMS LTI 2.0 and W3C Widgets (or even Google OpenSocial). This was pointed out at the plenary of the event by Mark Stiles (who chairs the JISC-CETIS board as well as being on the IMS board of directors): IMS really needs to work more closely with horizontal standards rather than build a silo.



I think IMS LIS is worth a look when it comes out, as is Common Cartridge (though in the short term we can easily convert Cartridges to the more commonly-supported formats such as SCORM 1.2 and using the Content Transcoder). However I'd give IMS LTI 2.0 a miss.



But more generally, is IMS too old-fashioned to remain relevant? Or is its focus on rather "unfashionable" areas of education technology a good bet for longer-term survival? A lot will depend on the success - or otherwise - of the current three-spec strategy

Related items: