UI options for advanced queries

[lukavdplas]

Add more UI options to build more complex queries. This suggestion differs from #856 in that it is specifically about enabling more advanced options through a graphical interface, rather than a more complex query language.

Some options we could add:

• Make multiple queries and match all or any of them. (Or at least n, which elasticsearch also supports.) Users can already make and/or in simple query string syntax, but some may find this interface easier to use.
• Make multiple queries for different search fields. E.g. search for speeches with 'grondwet' in the content and 'thorbecke' in the speaker field.
• Mark some of your queries as 'should' instead of 'must'. 'should' queries affect the relevance score but are not hard requirements.
• Use different types of queries, such as a wildcard query (simple query string has prefix search, so govern* but not *ment)

Marked this as major since quite a bit of code is built on the assumption that users can query with only 1 simple query string query (+ filters). A significant amount of revision would be needed for either this or #856.

[jgonggrijp]

Implementation suggestion, since I built something like this for READ-IT: build an intermediate representation (IR) of the (complex) query that the user enters through the graphical interface, such that you can do three things with it:

1. save the IR to a database (so it should be JSON-compatible);
2. reconstruct (i.e., render) the graphical interface exactly as it was filled out by the user;
3. convert the IR to the query representation that ES expects.

The nice thing is that you don't need the inverse of (3) in this case; you don't need to figure out how to convert back from ES's native syntax to the graphical interface, which is likely to be impossible due to information loss.

Essentially, such an IR is a view model, or a "controller model" if you will.

[lukavdplas]

Thanks!

That sounds like a good basis. Since I-analyzer has deep routing for queries, you would also need a conversion step to and from the query parameters of the route. This is doable (e.g., make a conversion of the IR to/from a string), though it may result in very long urls.

I-analyzer's search history requires that you can store queries in the database, as well as restore them from there. This would be covered by point 1. The database currently stores a json of the frontend QueryModel, which could evolve into the more complex IR required for this feature.

That said, https://github.com/UUDigitalHumanitieslab/I-analyzer-django/pull/45 actually changes the database to store elasticsearch queries instead. I-analyzer queries are currently simple enough that you can, in fact, restore them from the ES query without information loss. But perhaps I should rethink this if we want this in the future.