Sunday, 21 March 2010

App Store

If you own a smart phone it is likely that it comes pre-loaded with a suite of programs that cover what most phone users want to do most of the time.

An address book program is a must, and a calendar program is common.

But what if you have more specialized needs than what most phone users want to do most of the time? A currency conveter program, for example? A foreign language dictionary, a simulation game?

Many smart phones now come with the ability to "plug-in" a new program - personalizing the phone and extending it's functionality - and allowing the new program to securely share some of the core data and  functions of the phone. The Apple iPhone App Store is a good example of this approach - with a selection of more that 150,000 additional programs available (March 2010).

The IMS Common Cartridge specification aims to support what what most educational publishers want to do most of the time - by defining a set of educational resources common to educational publishing: content pages, external web links, discussion forums, assessment questions and so on.

But what if you have more specialized needs than what most publishers want to do most of the time? A molecular modelling environment for a chemsitry course perhaps? A foreign language dictionary, a simulation game?

The IMS Common Cartridge specification comes with the ability to "plug-in" new programs also - allowing the new program to securely share some of the core data about the learner's profile. This extensibility is afforded by the addition of the IMS (Basic) Learning Tools Interoperability specification to Common Cartridge.

Here's how it works - in three steps:

First, an educational publisher creates an XML file that describes an external program - and adds this file as a resource within a cartridge. For example, here is an XML descriptor file that references an eBook app:

<?xml version="1.0"encoding="UTF-8"?>
<basic_lti_link>
  <title>Organic Chemistry Chapter 1</title>
  <custom>
    <parameter key="ISBN">9780321598745,1</parameter>
  </custom>
  <launch_url>
http://ebooks.coursesmart.com/CSEbook.jsp
</launch_url>
  <vendor>
    <name>CourseSmart</name>
    <description>
      A link to the CourseSmart eBook Chapter 2 
of Organic Chemistry, 
7th edition, by Leroy G. Wade, published 
by Pearson Prentice Hall, copyright 2010.
    </description>
  </vendor>
</basic_lti_link>

It's easy to follow along with the description in the XML. There is an eBook app hosted by a vendor called CourseSmart. Note that the vendor can include some custom parameters that have meaning to the eBook app. In our case, the vendor has included a single custom parameter - which appears to be a unqiue identifier for the book (it's ISBN) followed by a chapter index. That's a guess (probably correct) - but the point is that the parameters only have meaning to the publisher and the eBook app - a learning system that implements IMS Common Cartridge does not have to understand these parameters, just honour them.

Second, the cartridge, and its XML descriptor file, are added to an e-learning system that support IMS CC - such as the Icodeon Common Cartridge Platform. The XML file is parsed and the e-learning system sets up a HTML form to be posted to the launch URL defined in the XML, along with the custom parameters. A number of other parameters are added also - such as an indentifier for the user, the course the user is studying, which school the user is attending and so on. But hang on - isn't that very insecure? A user on one system is getting free access to a publisher's valuable eBook! And the publisher's eBook app is being sent the private profile of the user! There's a third step to resolve this ambiguity.

Third, the e-learning system and the eBook app exchange a pair of keys - one public key and one private key. Whenever the e-learning system makes a request to the eBook app, the request is signed - a parameter string is added the request that only a party owning both the public and the private key can decode. In this way the eBook app knows unambigously which system sent the request - because the only party that owns the pairs of keys, apart from itself, is the e-learning system.

You can see how this works in the screen shot below of the Icodeon Cartridge Explorer application (click for full size image):


Details from the XML descriptor file have been made available and the HTML form has been set up with the custom parameters and the user profile. The launch button is clicked, the request is signed, the eBook app decodes the signature and  reads the parameters, and the eBook is made available to the user in a new window (click for full size image):


By using IMS (Basic) Learning Tools Interoperability with cartridges, like using the Apple App Store for the iPhone, there is a great potential for adding new programs to extend standard functionality.

You can see how this might be used within education on our Organic Chemistry page - a demonstration page that shows how a college chemistry tutor might mash-up  YouTube video, Common Cartridge assessments and eBook launch into a single blog page.


See the video by Dr Charles Severance (IMS) introducing IMS (Basic) Learning Tools Interoperability.


IMS Basic Learning Tools Interoperability from Charles Severance on Vimeo.

No comments:

Post a Comment