Here I specify the data structure (as I currently envisage it: please suggest improvements) of questions (or “criteria”) for RegenCHOICE. Please refer also to the question structure. I'll be addressing the main one first, for these types:

• Option list, range, or level on scale
• Likert format
• Alternative preference

Please let me know of any improvements that you can think of.

• Question ID: could be a 32-bit integer
• List of enabling answers, if any.
  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.
• Question type: one of the types listed in the question structure page
• Language: pick the most used language list (the same question in different languages share the same ID) and for each language:
  • Question topic:
    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 …”
  • Question description:
    a longer text field aiming at explaining any vague terms and clarifying any ambiguity (optional)
  • Number of options: integer between 2 and (I guess) 10
  • For each option, optionally:
    • Option short text, for display purposes, less than 80 chars
    • Option long text, explaining the option, if needed
    • Option value, in case of scales

• Question ID: could be a 32-bit integer
• List of enabling requirements, if any.
  The point here is that some questions only make sense given certain prior answers. Here we need to specify just what those answers are.
• Question type: “numerical range”
• Unit of measurement
• Lowest possible value in that unit
• Highest possible value in that unit
• (optional) Granularity: value will be rounded to the nearest allowed value
• Language: pick the most used language list (the same question in different languages share the same ID) and for each language:
  • Question topic:
    a short text field, probably not exceeding 80 characters, that can be transformed into a requirement by prefixing something like “I accept any answer within this range …”
  • Question description:
    a longer text field aiming at explaining any vague terms and clarifying any ambiguity (optional)

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.
  • Continent/subcontinent
  • Nation/State
  • State/Region
  • Municipality / local government area, e.g.
    • in USA: municipality
    • in UK: local authority
    • in France: commune
    • in Italy: comune
  • In Europe, we could use Nomenclature of Territorial Units for Statistics.

• Hexagons:
  • See H3 used by Roberto, 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

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.