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.

• 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.

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 (“NUTS”).

• 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

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.

• on HTML site