gift

<entry-title>GIFT Syntax</entry-title>

short URL

http://bit.ly/giftax

The GIFT picoformat allows writing multiple-choice, true-false, short answer, matching, missing word, and numerical quiz questions in a simple text format.

The GPLed Moodle Course/Learning Management System can import and export questions in the GIFT format.

Format

GIFT quiz questions must be encoded in utf-8 characters, and are delimited by blank lines. A question may be preceded by a title inside a pair of double colons and must include or be followed by an answer specification in curly braces. Examples are shown below.

Symbols	Use
// text	Comment until end of line (optional)
::title::	Question title (optional)
text	Question text (becomes title if no title specified)
{	Start answer(s) -- without any answers, text is a description of following questions
{T} or {F}	True or False answer; also {TRUE} and {FALSE}
{ ... =right ... }	Correct answer for multiple choice, (multiple answer?) or fill-in-the-blank
{ ... ~wrong ... }	Incorrect answer for multiple choice or multiple answer
{ ... =item -> match ... }	Answer for matching questions
#feedback text	Answer feedback for preceding multiple, fill-in-the-blank, or numeric answers
{#	Start numeric answer(s)
answer:tolerance	Numeric answer accepted within ± tolerance range
low..high	Lower and upper range values of accepted numeric answer
=%n%answer:tolerance	n percent credit for one of multiple numeric ranges within tolerance from answer
}	End answer(s); additional text may follow for fill-in-the-blank
\character	Backslash escapes the special meaning of ~, =, #, {, }, and :
\n	Places a newline in question text -- blank lines delimit questions

Examples

       // true-false
::Q1:: 1+1=2 {T}            // not sure if comments are okay here

// multiple choice with specific feedback
::Q2:: What's between orange and green in the spectrum?
{=yellow # correct! ~red # wrong, it's yellow ~blue # wrong, it's yellow}

// fill-in-the-blank
::Q3:: Two plus {=two =2} equals four.

// matching
::Q4:: Which animal eats which food? { =cat -> cat food =dog -> dog food }

// math range question -- note: {#1..5} is the same range
::Q5:: What is a number from 1 to 5? {#3:2}

// multiple numeric answers with partial credit and feedback
::Q7:: When was Ulysses S. Grant born? {#
   =1822:0      # Correct! You get full credit.
   =%50%1822:2  # He was born in 1822. You get half credit for being close.
}

// essay
::Q8:: How are you? {}

// alternate layout
::Title 
:: Question {
=Correct answer 1
=Correct answer 2
~Wrong answer 1
#Response to wrong answer 1
~Wrong answer 2
#Response to wrong answer 2
}

Note: the table and examples above were adapted from and then migrated back to the GPL-licensed Moodle site, not copied from there.

Categories

Question categories may be specified by preceding them with

$CATEGORY: path/name

with a blank line before and after. That sets the following questions' category name or pathname.

Case insensitive

Alphabetic case-sensitive comparison is off by default, but may be enabled for short answer (fill-in-the-blank) questions that need them with:

$question->usecase = 1;

Extensions for learner adaptation

Still to be done to extend the format for learner adaptivity (per, for example, del Soldato, T. & du Boulay, B. (1995) "Implementation of Motivational Tactics in Tutoring Systems," Journal of Artificial Intelligence in Education, 6(4): 337-78) is to add optional prerequisite and relative difficulty links to other questions (titles can be used) and optional question help text at two levels of specificity:

• relations to other questions
  • set of questions which help answer this question
  • set of questions which answering this question helps answer

(Can some of the directed graph of which questions assist in the answering of other questions be derived from categorization or must it be stored completely explicitly?)

• set of relations to other questions by relative difficulty; for each:
  • another question
  • more or less difficult, and how much
• general help (optional)
• specific help (optional)

It would also help to be able to specify the state of the question in a review system:

• incomplete
  • (ungrammatical, ambiguous, non-sequitur, implies false assumption, circular, dependent on future circumstance or decision, etc.)
• open
  • hypothetical (also open -- but less so?)
  • answered ("proposed"?)
    • reviewed
      • complete (passed review)
        • asked
          • scored
            • challenged
              • assessed
      • rejected (failed review or assessment)

(source)

Possible choices

Perhaps more special symbols ("control characters" in some GIFT specifications) can be used inside {}s. For example:

::milk-color                     // title; not sure if comment ok here 
:: What color is milk? {         // question
=white                           // answer
@helps-answer: latte-color       // helps if you know this
@easier-than: sky-color,         // this question is easier
              shroedinger-eqn%1% // need a numeric quantity for relative difficulty
? Think about full milk bottles. // general help (maybe @help: ...?)
?? It's the same color as chalk. // specific help (@specific-help: ...?)
@state: proposed                 // not sure about this ($proposed or *...?)
}

That would have a possible advantage of being tightly syntacticly bound to the answer, but the disadvantage that it would introduce additional special characters in the answer. That would probably be a lot better than introducing them in the question text.

There is a backward-compatibility advantage to only introducing one new special "control" character, such as @, because characters such as ?, $, and * are already possibly in answer codes somewhere the format is being used. So we could have:

@helps-answer: title[, title...]
@helped-by: title[,...]
@easier-than: title[%n%][,...]
@harder-than: title[%n%][,...]
@help: text
@specific-help: text
@state: text

That would apparently cover all the extension requirements. The reflexive links (helps/helped, easier/harder) can be implicit where they aren't specified.

Not sure whether it's a good idea to specify summary statistics from question fields as they might exist in a database. But if most of the database needs to be serialized in human-readable format, why not? One reason why not is that doing so could detract from the readability, especially since the answer statistics grow each time the question is answered. Maybe that should be specified but discouraged in practice?

See also

• 5-page reference (PDF)
• picoformats