fields which are only used for filtering should be moved out of the query section of the mapping

[harrisonpim]

We currently have four top-level objects in our mapping

• display: the document we show in the api, not indexed
• debug: for developers' eyes only, nothing indexed apart from indexedTime
• query: the mashed up, heavily analysed fields which are all indexed and used to control relevance, with some keyword subfields used for filtering
• aggregatableValues: which are used for aggregations, also indexed as keywords

There's a chance that we're indexing too many fields in the query section - devs working filters assume fields are there for relevance, and those engineering relevance assume they're there for filtering. The end result is a bloated index with unused fields, or fields serving multiple purposes which are hard to disentangle.

We could be more explicit about the separation of filtering and relevance-scoring by splitting the top level into

• display: as above

• debug: as above

• query: only used for relevance scoring

• filters: which might be structured like

  {
    "filters": {
      "fieldName": {
        "filterableValues": ___,
        "aggregatableValues": ___
      }[]
    }
  }

  in which all indexed fields should be keywords or dates

[agnesgaroux]

Has this been completed?