From Questions to Dataset Variables#

Questions Produce Variables#

A fielded survey yields a dataset, and every question contributes one or more of its columns. A simple numeric question contributes one variable. A multiple choice question that allows several selections contributes one variable per choice, because each choice is a yes or no of its own. Grids multiply: a choice grid contributes a variable per row, and a question grid a variable per row and column. Computations contribute their output fields as derived variables.

This is why the application talks about outputs in so many places: the Outputs tab on a question, the Outputs page for the whole survey, and the output appendix of the Specification PDF are all views of the same derivation.

Why Names Matter#

Downstream, these names are how analysts, data editors, and archive pipelines refer to the data. A predictable scheme, the question name plus row and choice parts, means the dataset’s structure can be read off the questionnaire. Stable names also keep waves comparable: if the employment question is jbstat this year, analysts want it to be jbstat next year.

The automatic rules produce that predictability without effort, and overrides exist for the cases where a house convention or a legacy dataset dictates specific names. Overriding early is cheaper than renaming a fielded dataset later, which is why the Outputs page makes the full variable list reviewable, and exportable as CSV, before any data is collected.

Onward to Data Tools#

The names defined here travel with the survey. The Specification PDF documents them for people. The DDI 3.3 export carries them as metadata, from which Colectica Designer can generate dataset descriptions that match the questionnaire; see Generate a Dataset Description from a Survey Instrument. In Blaise Colectica Questionnaires, the Blaise 5 generator uses them as the field names of the generated instrument.