Re: [Qtitools-mathassess] QTI - maths

[David M. <dm...@ph...>]

Hi folks,

Some (belated, sorry) thoughts about the recent discussion about QTI and 
Maths:

> -----Original Message-----
> From: R....@su... [mailto:R....@su...]

> As far as maxima is concerned there is a maxima to mathml module that works well
> with everything I have given it to date. I hope that other cas systems have such convertors, 
> but do not know about this.

I've noticed the MathML module for Maxima too but Dick has clearly had a 
lot more experience using it than I have. It does sound like something 
we might need to investigate in more detail for this project.

Maple also has built-in support for importing and exporting MathML. It 
exports Content MathML (with Presentation MathML annotations). It can 
import Content MathML and makes a decent stab at importing Presentation 
MathML (provided it is reasonably semantic).

As for Mathematica, I haven't played with it enough/recently so can't say.

> The interoperability argument that I have hinted at before, is as follows:
> a) It is assumed that a question is authored with a particular cas system in mind, presumably
> the one available to the rendering system to be used (e.g. stack, mapleTA of a particualr QTI renderer).

I think this is a pragmatic approach.

> b) for QTI authoring all the maths should be coded into that cas syntax and labelled as such by 
> the "syntax" attribute, but if authored in some other system and converted to QTI on export, then
> the cas code might as well be kept in the original cas syntax and labelled.
> c) any extra equations can either be coded directly into mathml (using a mathml editor like 
> Mathtype or amaya) or, more likely, into the cas syntax for conversion by the cas system
> at render-time.

There are really two maths-related problems on the go here (plus a third 
that's not relevant to this discussion but needs addressed as well):

(1) Setting up template variables and specifying response processing rules
(2) Marking up item bodies & feedback for presentation to candidate
(3) Input of mathematics by the student/candidate for resp processing

I think we've all agreed that using CAS is the way to go for (1).

For (2), I think we've all agreed that we will be using (Presentation) 
MathML to *deliver* mathematical content within item bodies and 
feedback. The actual *authoring* of this content is where things are not 
so clear.

The simplest option here is to input MathML directly, either hand-coded 
or using a GUI editor. I think most authors would justifiably run a mile 
if they were asked to hand-code MathML; GUI editors are OK but, in my 
experience, people who already know things like TeX/LaTeX find them 
clunky and slow to use.

I can see the appeal in using CAS syntax for (2) as well but am not sure 
whether it would give authors enough control over the resulting outputs. 
(For example, if I input 2+x into Maxima, it will output x+2.)

A third option is to allow authors to use a simpler input format (e.g. 
LaTeX) to enter maths within item bodies, converting it to MathML, 
either at run-time by the QTI renderer or during some kind of "export" 
process. People who already know LaTeX are likely to prefer this type of 
approach, I guess. (Leslie?)

With option (3), we would have to find some way of specifying template 
variable substitutions in the LaTeX. (For example, a placeholder for the 
value of 'iA' could perhaps be specified by #{iA}, which is not legal 
LaTeX but is workable, or by using some kind of custom macro.) Things 
that would still have to be addressed if adopting this approach are:

(i) We're substituting variables from the CAS. How do we merge this with 
LaTeX to make the final MathML? Do we just mark up #{iA} as <mi>iA</mi> 
and let things behave the same way as existing MathML QTI examples? If 
so, how do we then know iA is an identifier rather than a number or an 
operator?

If we're doing all of the conversion during rendering, then an 
alternative approach would be to substitute all of the #{iA} with 
LaTeX'ed versions of the CAS template variables before converting the 
whole lot to MathML. (This is probably less yucky than it sounds; we can 
do Maxima -> Presentation MathML -> LaTeX reasonably well.)

(ii) If we're going to have fragments of LaTeX like this within our QTI, 
then we're not really doing QTI any more so it isn't very portable. (For 
example, there's an implicit assumption that certain things in the LaTeX 
are placeholders for QTI variables but it's not explicit anywhere in the 
XML. I suppose this is similar to how it works with MathML?)

As for (3), it seems like our options are:

(3a) Get candidates to use CAS syntax
(3b) Get candidates to enter MathML using a GUI input
(3c) Get candidates to use an "easy" input syntax (e.g. LaTeX, ASCIIMathML)

Option (3a) is probably the easiest one to implement as it seems that it 
will fit naturally into the response processing. The main issues with 
this approach is that we'd need to find ways of preventing candidates 
from using the CAS syntax to "cheat" or do nasty things to the 
underlying system. Possible things we'd need to consider would be:

* White-listing allowable groupings of characters (which could be hard)
* Black-listing things we don't want them to do (which is usually a 
doomed approach on its own)
* Sandboxing the CAS somehow
* Configuring the CAS to only allow it to do certain types of things. 
(I'm not sure whether this is feasible or easy with Maxima?)

Option (3b) is viable if we can select a suitable (free) MathML input 
control/applet and Option (3c) is something we ought to consider as 
well. The idea here would be that the response processing engine 
receives the candidate input as (Presentation) MathML, which would then 
have to be converted to CAS format. Now, in general this is not 
possible. However, if we restrict the spectrum of mathematics being 
considered to just, say, elementary functions and basic stuff like that, 
then it is feasible to do this using some simple heuristics. (For this 
level of mathematics, it's fairly reasonable to be able to convert 
Presentation MathML <-> Content MathML <-> Maxima.)

Note that one corollary of this discussion is that we will almost 
certainly not be able to use the same approach for (1), (2) and (3).

> d) if the QTI is rendered by a system with the same cas system, then all is well and good,
> otherwise the renderer will have the task of translating cas_code from known source to 
> known destination. This might be impossible for an an expression of arbitrary complexity, but
> that is going to be a limitation when porting maths questions between any two incompatible 
> cas systems.

Agreed. I think this is something we are going to have to live with. I'm 
not keen on trying to come up with some kind of uber-CAS syntax.

> e) The development of some other syntax for representing maths seems to me to be an
> unnecessary complication. It would probably end up looking like one of the existing syntaxes 
> anyway. 

Agreed.

 >  Alternatively, I guess, we could discuss which system should be 
chosen as the
> common format for maths. I am not in favour of using, latex, because it does not include all 
> the operators available to cas systems (as far as I know).

Yes, and as outlined above, I don't think settling on a single common 
format for maths is going to be the best solution for this project.

Cheers,
David.

-- 
David McKain, School of Physics and Astronomy e-Learning Group
http://www.ph.ed.ac.uk/elearning/

The University of Edinburgh is a charitable body, registered in 
Scotland, with registration number SC005336.