Managing Questions in DDI3.1 – “Other, please specify”
A still difficult problem in managing complex questions in DDI is those questions that ask a respondent to pick from a list of options, and if no suitable ones exist, that they write in their own. Below are examples of this kind of question from the US, UK and Australian Censuses (censii/census/censes?):
In all three questions, respondents are asked about their origins, and are given the option to select from a list of common responses or provide a write in response. The easiest way to manage this is through the use of a DDI <MultipleQuestionItem>. A <MultipleQuestionItem> is a way to capture a complex question that asks two or more separate questions that are highly linked.
In the above examples we can split the questions into two, as illustrated in the generic answer below:
<MultipleQuestionItem>
<SubQuestions>
<QuestionItem>
<QuestionText>
<LiteralText>
What is your ancestral origin?
</LiteralText>
</QuestionText>
<CodeDomain>
<!-- This CodeDomain would include a reference to the list of countries or races -->
</CodeDomain>
</QuestionItem>
<QuestionItem>
<QuestionText>
<LiteralText>
Please Specify:
</LiteralText>
</QuestionText>
<TextDomain/>
</QuestionItem>
<SubQuestions>
</MultipleQuestionItem>
Here we have been able to split the question, while still managing it in a single item. This is needed as without each other, each subquestion is incomplete. This is not a new concept, and is quite an obvious solution to many people who have tried to solve this issue.
However, there is still the problem that this metadata doesn’t contain the restriction that a respondent should only be able to enter a free text option if the “other” option is selected. While there have been a number of published and attempted solutions, none have been satisfactory. Spliting the question outside of a MultipleQuestionItem and using IfThenElse clauses complicates the structure, and leaving this out makes designing self-interviewed computer systems difficult to manage directly from the metadata.
A possible solution, that resolves both of these issues is through the use of the <SubQuestionSequence>. This is illustrated in the DDI Fragment below:
<MultipleQuestionItem>
<SubQuestions>
<QuestionItem>
<!-- Ancestral origin QuestionItem -->
</QuestionItem>
<QuestionItem>
<!-- Please Specify QuestionItem -->
</QuestionItem>
<SubQuestions>
<SubQuestionSequence>
<ItemSequenceType>Other</ItemSequenceType>
<AlternateSequenceType formalLanguage="Name Of Language Here" >
<!-- Proprietary command to control logic -->
</AlternateSequenceType>
</SubQuestionSequence>
</MultipleQuestionItem>
In this we have used the SubQuestionSequence to hold the logic used to indicate when the “Other” field should be allowable. This field is used to control the specific sequence that the SubQuestions are shown, and in this sense we are controling this ordering, just to specify when a member is not shown – an excusable use of the field. This choice can be further rationalised, as an unfamiliar agent, for example when moving to a new piece of software, can still interpret the bulk of the metadata, however when presenting the above question would allow a respondent to fill in both sections. But this is no different to how a respondent of a paper-based survey may answer, so it is no great loss of granularity.
How any given agency may choose to populate the commands contained in the AlternateSequenceType will be an individual choice, and a standard way of expressing this may be needed, but this should help other groups more easy solve this problem by indicating where the solution can go and reducing the problem size.
In the next day or two I will be putting a more solid example up into the DDI Examples Repository for people to work with. As always critiques of these ideas and examples are welcome.
