Subject: [IFETS-Discuss] IMS and the Question and Text protocol
crispinw@dircon.co.uk
Date: Sat 20 May 2000 - 06:17:34 MEST
From: crispinw@dircon.co.uk Subject: [IFETS-Discuss] IMS and the Question and Text protocol Date: Fri, 19 May 2000 21:17:34 -0700
List address to send message to everyone: ifets-discuss@topica.com
Details of current discussion: http://ifets.ieee.org/discussions/discuss.html
---------------------------------------------------------------------------
I am a little confused by the progress of IMS in general, and by the
Question and Test protocol in particular. I should be very grateful if
anyone in the IMS-know could respond to the points below.
The raison d'être of open standards is to provide interoperability between
different components in a learning system. It seems to me that the key need
for interoperability is between interactive courseware units and a
management system. The outline of this relationship is that the management
system should be able to launch the courseware, passing appropriate
parameters to it; and the courseware should be able to pass results data,
bookmark information, user preferences etc. back to the management system.
The reason why this relationship is so important is that learning
institutions need to run a single management system, yet use courseware from
multiple vendors. They want to be able to replace management system and/or
courseware separately, without trashing the rest of their resources.
My problem with IMS is that I cannot find any mention in the specs produced
so far of how this relationship is to be managed, nor any indication of a
protocol in the pipeline which will handle it. Perhaps I have not looked
hard enough. Can anyone help me out here?
I had clearly got the wrong end of the stick, because I had expected the
Question and Test protocol to handle this. But instead, all the Q&T protocol
does is to produce a set of standardised question types (multiple response,
single response, text match etc). This exercise seems to me to be both
unnecessary and undesirable: unnecessary because all authoring tools provide
their own proprietary run-time engines; undesirable because there is an
unlimited wealth of potential interaction paradigms out there waiting to be
implemented and the standard set of interaction types will very quickly be
seen as stifling innovation.
For example:
* the Q&T protocol defines a hot-spot as a rectangle, ellipse or bounded
area. But what if I have an authoring tool which allows the definition of a
hot-spot by a mask, allowing pixel-level accuracy for judging hits? What if
I include an image to show the hot-spot in a selected state, allowing better
feedback to the user and the possibility of multiple response hot-spots?
* the Q&T protocol defines an essay question, which is not computer
assessed. But what if I come up with a really good text analysis engine
which allows computer marking of short essay questions? The data allowing
this to happen will undoubtedly be complex and proprietary.
* what about speech recognition, which will soon allow voice response
interactions: the intelligent language laboratory. This also has no place in
the Q&T protocol.
Will the Q&T protocol be re-written every time someone comes up with a new
interaction type? If so, I think we will soon be up to version 100!
My impression is that IMS envisages that questions will be authored in
proprietary authoring tools, then exported as IMS questions to an IMS
management system, which will take responsibility for running them itself.
This leaves you with one piece of software trying to be both a management
system and a courseware engine, reducing the advantages of specialisation.
It also restricts you to running 'lowest common denominator' interactions.
I suspect that the standard response to this criticism is the magic word
'extensibility'. But what extensibility means is that you can package up
extra data (needed to define each of the interaction types in the examples
above) and bat this extra data around and it will be ignored by all
components which do not understand it: which is likely to be *all*
components which are not provided by me or members of my development
community. If extensibility means any more than "add what you like and I'll
ignore it", then this mystery data needs to end up with a component which
understands it: i.e. a run-time-engine.
But this brings me back to my first question - where are the IMS protocols
for communicating with run-time-engines?
---------------------------------------------------------
Forum website: http://ifets.ieee.org/
Forum's contact person: kinshuk@massey.ac.nz
Info on Join/Leave List: http://ifets.ieee.org/maillist.html
Change your subscription options (digest, vacation hold etc.) at: http://www.topica.com/lists/ifets-discuss/prefs
---------------------------------------------------------
___________________________________________________________
T O P I C A The Email You Want. http://www.topica.com/t/16
Newsletters, Tips and Discussions on Your Favorite Topics
This archive was generated by hypermail 2a24 : Sat 20 May 2000 - 06:18:18 MEST