Wikisoba project/JSON specification for version 2
This is the working page for designing the JSON specification for Wikisoba Mark II.
Working assumption
The JSON for any one "slide" (adopting the term in Mark I) reads as
[configuration array, data array]
The configuration array starts by giving the "slide type", which would be 1 for questions, out of about five types in all, the other types being ways of including supporting material. The array will have about a dozen items, including some the legacy of Moodle export as in the JSON-GIFT sample.
Overall structure
This should be as:
[intro, section array, outro]
with the section array as:
[section(1), section(2), ..., section(K)]
and a section as
[nav1, slide array, nav2]
Here a slide array is like
[slide(1), slide(2), ..., slide(K)]
and the slides are expected to be of about five types, type #1 being the question type.
Choice-cloze type
This is to be a versatile question type, including a number of typical multiple choice and missing text (cloze) formats. Its data array will look like
[S-array, T-array]
Here the S-array will be
[S(1), S(2), ..., S(N + 1)]
and the S(i) will be strings, possibly null, subject to JSON constraints[1] and the constraint that S(N + 1) is either null or ends in a terminating punctuation mark.[2]
The T-array will be
[T(1), T(2), ..., T(M)]
Example would be the case M = N, each T(j) is a single word, and the piece of text to reconstruct reads S(1) T(1) S(2) T(2) ... S(N) T(N) S(N + 1). Then the software should display boxes between the S(i), and display the words T(j) below in a random order. The user is supposed to drag the words into the boxes.
In general T(j) will be an array
[T(j) strings, T(j) annotations]
Here
T(j) strings
is an object, consisting of strings each of which is an acceptable answer in the place between S(j) and S(j + 1).
T(j) annotations
has to carry the other information in the question, namely any dummy answers,[3] custom hints, responses, special reset information, special scoring information. The array part for dummy answers need to contain pairs like [dummy answer, response]; where response can be set to null as the default.
Five examples
Going beyond simply matching phrases into boxes (type A question), there are two types of added complexity, namely multiple choice, and colour coding. Colours can identify which answers relate to which box (i.e. calibrate the missing phrases a bit).
Type | Plain | Coloured |
---|---|---|
Matching | A | n/a |
Check box | B | C |
Complex | D | E |
The colouring option clearly should be operated by the question subtype field, but may also be a custom hint. The dummy answers should be listed in the annotations.
Traditional multiple choice
There is only one box, so N = 1 for multiple choice, and S(2) is null. Also M = 1. Only types B and D are relevant, and correspond to ...
Configuration list
This is a provisional listing of some fields that should occur in the configuration array, mostly with default values.
- (Slide type) 1
- (question type) choice/cloze
- (question subtype) A to E[4]
- (equality test) non-case sensitive equality of Unicode strings[5]
- (display type) graphical[6]
- (wikidata item) Use as a tag for topic area
- (response type) enabled[7]
- (hint type) go back | wikidata | custom
- (reset type) back to question start
- (scoring type) none
- (timing type) none
- Legacy fields: allow for some carried forward from Moodle
- Provenance and attribution of question
Notes
- ↑ I.e. can be Unicode, but with certain characters escaped.
- ↑ I.e. ends in . or ? or !.
- ↑ I.e. false answers, in multiple choice terms.
- ↑ See previous section
- ↑ Caveat about JSON's use of escapes
- ↑ As opposed to buttons
- ↑ I.e. display responses in the feedback area before moving on to next question. The default would be like this. Standard messages for: question completed correctly; question partially completed, as far as it goes; some incorrect answers where wrongly matched. If some dummy answers are chosen, use the response settings for those if some relevant ones are different from "null".