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. There could be some attempt to put some meaning into this ID, but it is probably easier simply to assign a random number to it, only ensuring that there are no duplicates.
• 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. The enabling answers are determined by the enabled question, not by the enabling question.
• 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 (that is a capital “i”, not an “el”) 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.

Space / place and time are the two factors that hold a special place of neutrality in science, and they deserve special treatment here. These belong to the enquiry as a whole, not to any specific criterion question within the enquiry.

Location isn't the same kind of thing as the other questions. The way that location is envisage to be handled is roughly this. Users do not have a single location, as there are many enquiries that would not be served by that, and most people do not stay in one place all the time. Instead, each enquiry can have its own location.

• Enquiry location can be given as a political drop-down list, as nearly all web users will be familiar with that. This can be used in conjunction with the following.
• Enquiry location can be given as a point on a map
• have the option of giving a place to any enquiry, or specifying that it is “nowhere”
• can optionally specify the maximum distance another chooser may be away from the place of the enquiry, or ask for “anywhere”

“Nowhere” means that neither chooser will be able to use or see the other chooser's location.

• 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”).
• In some cases, people identify with, and like to use, outdated, traditional or old political entities. I'm not clear how we should handle these. One option would be to have bespoke place definitions, added to on demand — as there is no way that we could hope to document all of them in advance.

• Hexagons:
  • See H3 used by Roberto 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 may not appear in a first prototype, or a minimal viable product. However in the same spirit as other questions, it may be extremely useful to specify one or more time windows for an enquiry. Among other options, there could be these.

• Start and/or finish dates, which could be multiple, for multiple time windows – essentially, availability
• Periodic schedule times, because many people's calendars are organised on weekly, fortnightly or monthly cadence
• Proportional engagement, e.g. how many hours per week / month / year
• Minimum and maximum cumulative times

This could be, for instance, derived from a recognisable event that implies a place and a time, e.g.

• a music festival
• any other public gathering with physical presence
• a timetabled journey using some public or open transport — that would allow people to have interesting conversations while travelling, with the (moving) place and times being specified by the relevant transport timetable.

How to implement these without any ambiguity is unclear.

But even without the help of specifying a particular known event, space and time can be used together. This capability is quite complex and quite powerful – not hard to compute, but hard to match without computational assistance. It may not be important to many people and many kinds of enquiry, but in line with the RegenCHOICE philosophy, it could be provided for those to whom it is important.

• on HTML site