LTI certification and news from the IMS quarterly meeting

Steve Lay HeadshotPosted by Steve Lay

Earlier this month I travelled to Michigan for the IMS Global Learning Consortium’s quarterly meeting. The meeting was hosted at the University of Michigan, Ann Arbor, the home of “Dr Chuck”, the father of the IMS Learning Tools Interoperability (LTI) protocol.

I’m pleased to say that, while there, I put our own LTI Connector through the new conformance test suite and we have now been certified against the LTI 1.0 and 1.1 protocol versions.IMS

The new conformance tests re-enforce a subtle change in direction at IMS. For many years the specifications have focused on packaged content that can be moved from system to system. The certification process involved testing this content in its transportable form, matching the data against the format defined by the IMS data specifications. This model works well for checking that content *publishers* are playing by the rules, but it isn’t possible to check if a content player is working properly.

In contrast, the LTI protocol is not moving the content around but integrating and aggregating tools and content that run over the web. This shifts conformance from checking the format of transport packages to checking that online tools, content and the containers used to aggregate them (typically an LMS) are all adhering to the protocol. With a protocol it is much easier to check that both sides are playing by the rules  — so overall interoperability should improve.

In Michigan, the LTI team discussed the next steps with the protocol. Version 2 promises to be backwards-compatible but will also make it much easier to set up the trusted link between the tool consumer (e.g., your LMS) and the tool provider (e.g., Questionmark OnDemand).  IMS are also looking to expand the protocol to enable a deeper integration between the consumer and the provider. For example, the next revision of the protocol will make it easier for an LMS to make a copy of a course while retaining the details of any LTI-based integrations. They are also looking at improving the reporting of outcomes using a little-known part of the Question and Test Interoperability (QTI) specification called QTI Results Reporting.

After many years of being ‘on the shelf’ there is a renewed interest in the QTI specification in general. QTI has been incorporated into the Accessible Portable Item Protocol (APIP) specification that has been used by content publishers involved in the recent US Race to the Top Assessment Program. What does the future of QTI look like?  It is hard to tell at this early stage, but the buzzword in Michigan was definitely EPUB3.

Learning Tools Interoperability fulfills its promise!

Posted by Steve Lay

In previous blog posts I’ve discussed the new specification that the IMS Global Learning Consortium (IMS) has been working on called Learning Tools Interoperability or LTI for short.  See my first post on this subject here and the later update here.

In March, IMS released the final version of the specification.  This clears up any confusion between the earlier variants (Basic and Simple have been used as prefixes in the past) and sets a single standard for embedding tools in learning management systems (LMS) and portals.  The final specification also introduced an important new feature: a method of returning grade information from the tool to the LMS gradebook.

At Questionmark we have developed a number of connectors for integrating with popular learning management systems and portals, such as Blackboard and Moodle.  LTI provides us with an opportunity to replace those connectors with a unified approach to integration, so I can’t wait to get started with the new specification.

To this end we are now working on adding LTI support to our own software.  I recently attended an IMS workshop called “Creating Enterprise Aware, Multiplatform Apps with IMS Interoperability”.  At this workshop we heard about the latest developments in both IMS Common Cartridge and IMS LTI.  It was a great to meet some of the key people in the community and take a deep-dive on some of the technical details involved in implementing the specifications.

So how will Questionmark integrate using LTI?

In LTI terminology there are tool providers and tool consumers.  A tool consumer is typically an LMS or other type of portal that deals with user registration and assignment to courses where learning and assessment activities are aggregated.  A tool provider is a web-based service that provides a specialized experience to the learner such as an assessment.

Our first steps with LTI are aimed particularly at users of the Moodle LMS, though anyone with access to a web server running PHP and a suitable database will be able to integrate this way.  We’ve teamed up with an LTI specialist, Dr Stephen Vickers, to create an open source Community Edition connector that makes it easy for Moodle users to talk to Questionmark software using the new LTI protocol.  The project is hosted on the OSCELOT community development system.

This is just the beginning for Questionmark and LTI – so stay tuned for more updates on the role LTI will play in future Questionmark assessment technology solutions!


Assessment Standards 101: IMS QTI XML

john_smallPosted by John Kleeman

This is the second of a series of blog posts on assessment standards. Today I’d like to focus on the IMS QTI (Question and Test Interoperability) Specification.

It’s worth mentioning the difference between Specifications and Standards: Specifications are documents that industry bodies have agreed on (like IMS QTI XML), while Standards have been published and committed to by a formal legal body (like AICC or HTML). A Specification is less formal than a Standard but still can be very useful for interoperability.

Questionmark was one of the originators of QTI. When we migrated our assessment platform from Windows to the Web in the 1990s, our customers had to migrate their questions from one platform to the other. As you will know, it takes a lot of time to write high quality questions, and so it’s important to be able to carry them forward independently of technology. We knew that we’d be improving our software over the years and we wanted to ensure the easy transfer of questions from one version to the next. So we came up with QML (Question Markup Language), an open and platform-independent method of maintaining questions that makes it easy for customers to move forward in the future.

Although QML did solve the problem of moving questions between Questionmark versions, we met many customers who had difficulty bringing content created in another vendor’s proprietary format  into Questionmark. We  wanted to help them, and we also wanted to embrace openness and allow Questionmark customers to export out their questions in a standard format if they ever wanted to leave us. So we worked with other vendors within the umbrella of the IMS Global Learning Consortium to come up with QTI XML, a language that describes questions in a technology-neutral way.  I was involved in the work defining IMS QTI as were several of my colleagues: Paul Roberts did a lot of technical design, Eric Shepherd led the IMS working group that made QTI version 1, and Steve Lay (before joining Questionmark) led the version 2 project.

Here is a fragment of QTI XML and you can see that it is a just-about-human-readable way of describing a question.

<?xml version="1.0" standalone="no"?>
<!DOCTYPE questestinterop SYSTEM "ims_qtiasiv1p2.dtd">
<questestinterop>
<item title="USA" ident="3230731328031646">
<presentation>
<material>
<mattext texttype="text/html"><![CDATA[<P>Washington DC is the capital of the USA</P>]]></mattext>
</material>
<response_lid ident="1">
<render_choice shuffle="No">
<response_label ident="A">
<material> <mattext texttype="text/html"><![CDATA[True]]></mattext> </material>
</response_label>
<response_label ident="B">
<material> <mattext texttype="text/html"><![CDATA[False]]></mattext> </material>
</response_label>
</render_choice>
</response_lid>
</presentation>
<resprocessing>
<outcomes> <decvar/> </outcomes>
<respcondition title="0 True" >
<conditionvar> <varequal respident="1">A</varequal> </conditionvar>
<setvar action="Set">1</setvar> <displayfeedback linkrefid="0 True"/>
</respcondition>
<respcondition title="1 False" >
<conditionvar> <varequal respident="1">B</varequal> </conditionvar>
<setvar action="Set">0</setvar> <displayfeedback linkrefid="1 False"/>
</respcondition>
</resprocessing>
<itemfeedback ident="0 True" view="Candidate">
</itemfeedback>
<itemfeedback ident="1 False" view="Candidate">
</itemfeedback>
</item>
</questestinterop>
.
QTI XML has successfully established itself as a way of exchanging questions. For a long time, it was the most downloaded of all the IMS specifications, and many vendors support it. One problem with the language is that it allows description of a very wide variety of possible questions, not just those that are commonly used, and so it’s quite complex. Another problem is that (partly as it is a Specification, not a Standard) there’s ambiguity and disagreement on some of the finer points. In practice, you can exchange questions using QTI XML, especially multiple choice questions, but you often have to clean them up a bit to deal with different assumptions in different tools. At present, QTI version 1.2 is the reigning version, but IMS are working on an improved QTI version 2, and one day this will probably take over from version 1.

Understanding Common eLearning Standards

tomking_tn80x60-21

Posted by Tom King

I’ve prepared a video podcast which is your introduction to key interoperability standards for elearning. It also serves as my introduction to video podcasts. Your feedback on both the content and the style will be put to use as I continue the series—so please post comments or send email.

The video for Part 1 provides a quick overview of the need for interoperability standards, the names of the keys standards, and the types of interoperability they support. Part 1 addresses AICC, ADL SCORM, IEEE LTSC and IMS specifications at a high level. It introduces the concepts of run-time communication, content packaging, and meta-data.

I hope you find it a good refresher if you are already somewhat knowledgeable about these standards, and an excellent introduction if you are new to most of this.

Why QTI really matters

john_small Posted by John Kleeman

Questionmark has been a long time supporter of QTI XML. QTI XML is a language that describes  questions in XML in a way that is platform and technology neutral.

Questions take a long time to write, and it’s important that they can survive in computerized form as technology changes. At Questionmark, our customers often need to take questions constructed in an older system, sometimes a discontinued system, and move them into Questionmark software. When the legacy questions are in QTI XML, this is reasonably straightforward. When the questions are held deep inside a proprietary database or other structure, it can be more challenging to move them into another system.

Eric Shepherd, Paul Roberts and myself were part of the original IMS team that created QTI XML, and Eric led the team that created and evangelized it for many years. Steve Lay, before he joined Questionmark was one of the leaders of the QTI version 2 initiative. Questionmark as a company is a keen supporter of QTI XML – it’s a good way for our customers to be confident that questions are likely to survive into the long term future.

Version 1.2.1 of the IMS QTI specification was finalized in 2003 and is supported by Questionmark Perception and in our Content Converter application .

image

IMS has been working for many years on a version 2 of IMS QTI, and version 2.0 was introduced and finalized, and then a draft version 2.1. You may have seen some controversy recently as the IMS has withdrawn the draft version 2.1 of QTI, removing it from their website saying that they want to review it and change it.

Version 2.1 of QTI XML has been in draft form for a couple of years, and although Questionmark hasn’t yet supported it, very many projects have done so, and there is concern from those who have implemented it that their work might not be valid when 2.1 or 2.2 is finalized. See Rowin Young of CETIS’s blog for one perspective on this.

I’d like to reassure our customers that Questionmark continues to support QTI XML version 1.2.1 and will expect to support later versions of QTI XML when formally released as final and open specifications.