User Tools

Site Tools


ch:ia:question-info

RegenCHOICE

  • ia information architecture
  • qs question structuring

Question information structure

The questions themselves are a different kind of information from the rest, and there needs to be a separate system around the maintenance and development of the question bank as a whole.

This is the data structure (as currently envisaged: please suggest improvements) of questions (or “criteria”) for RegenCHOICE. Please refer also to the separate individual question structures, which use this as a common base, but have their own specific extensions.

Specification common to all question structures

  • QID mandatory global question ID: could e.g. be a 32-bit (or longer) integer
  • List of enabling answers, optional.
    The point here is that some questions only make sense given certain prior answers. Here we need to specify just what those answers are, which will not be language-dependent.
  • Language-dependent fields: for each language formulated for this question:
    • Lang: the natural language (1st listed is the default)
    • QTitle mandatory question title:
      a short text field, probably not exceeding 80 characters, that can be transformed into a requirement by prefixing something like “I accept these responses for …” and into an answer by prefixing something like “This is the response I most closely identify with for …”
    • QDesc optional question description:
      a longer text field aiming at explaining any vague terms and clarifying any ambiguity (optional)
  • QRelB: Boolean, mandatory, whether or not the question is relational or a property.
  • QnI number of items: for itemised questions, integer between 2 and 10; for non-itemised question = 0 (default)
  • QStruct: mandatory; one of the structures listed on the qs page.
  • QLearn: link to a page explaining anything here in more detail, with further links to learning resources as may be needed.
  • QDetails depend on which structure it is.

Two special cases: place and time

Location

As there are various options for this, we will need to specify them separately

  • Political units
    This is important in some cases, because several needs have constraints that depend on the political governance. These units are not homogeneous across different countries, so the aim here is to use whichever makes most sense to people locally.
  • Hexagons:
    • See H3 used by Roberto Valenti among others, taken from Uber.
  • Geolocation
    • Geographical centre of enquiry (at any chosen level of precision)
      • latitude (as normally defined)
      • longitude (as normally defined)
    • radius of interest
      • unit of distance measurement
      • value in that unit

Time window

This is altogether optional, so need not be implemented to begin with.

I imagine a single event format, covering definite periods and windows of opportunity; and a repeated time format, for instance covering a repeating schedule at a weekly or other cycle.

Commentary

see also

ch/ia/question-info.txt · Last modified: 2024-11-02 08:19 by simongrant