Make search forms more flexible - structured queries for mod_search

[mworrell]

Description

• Motivation

Currently we use simple query questions for the search forms.
They are mapped with qargs to a list of query terms with values.
These are all used as an 'AND' query.

If a form is programmed then we need to check for every input element if the element should be checked, filled in etc.
This is quite a bit of code, and can be complex.

• Proposal

Make it possible to represent a search question as a (nested) map.
This could include allof, anyof and noneof nestings.

The query form can use the dotted and bracketed name notation like we use in the rsc updates.

Also add a Javascript function to match the passed query arguments with the input elements and check/uncheck/select/fill-in the corresponding input elements.

[mworrell]

Example search question:

• Free text input AND
• Display list or map (config)
• Categories OR
• Keywords; AND various sub-categories
  • Content: AND multiselect
  • .. AND
• Location names OR
• Language OR
• Date range

Might be mapped to:

#{
    <<"text">> => <<"search text">>,
    <<"category">> => [
        <<"text">>,
        <<"document">>
    ],
    <<"hasobject">> => #{   % Use hasanyobject for an OR
        <<"subject">> => [
            1234,
            5678
        ]
    },
    <<"language">> => [
        <<"en">>,
        <<"nl">>
    ],
    <<"date_start_after">> => <<"some date">>,
    <<"date_end_before">> => <<"some other date">>
}

With query args:

text=search%20text&category[]=text&category[]=document&
hasobject.subject[]=1234&hasobject.subject[]=5678&language[]=nl&language[]=en

[DorienD]

cat: Artists
AND Keyword: wood and abstract
AND Location: Germany

Input text
AND cat Artworks
AND date > 2000
AND Author: person
AND keyword, keyword, keyword (so multiple keywords)

Magazine
AND keyword
AND 2022 (year)
AND author

[robvandenbogaard]

Freely thinking about what would look clear to me as a query url (clarity being a concern), it might be something like (substituting the "subject" predicate with "hasauthor" for disambiguation):

• text="search test"&category=anyof[text,document]&hasauthor=allof[1234,5678]&language=["en","nl"]..

where author= is short for objectof(hasauthor)=, and =["en","nl"] short for =anyof["en","nl"]
so a list can always be considered as OR unless explicitly specified otherwise (no further context needed to explain or understand the query in terms of ANDs and ORs, or NOTs/noneof)

• text="search test"&category=anyof[text,document]&subjectof(hasauthor)=anyof[book1,book2]&language=..

I know this deviates from the way how forms are encoded, which leads me to consider this as a pseudocode for what we really need: to merge form serialisation with configuring queries.
What if we encode the query "configuration" (saying which option lists are AND, which are OR etc) in hidden input fields of the form itself, indicating "query intent/semantics"?

This way the query stays self-documenting, but also is (de)serialisable in a straightforward manner.
Downside is how to address multiple "hasauthor" clauses where one is an AND list, and the other is an OR list?

text=search%20text&category[]=text&category[]=document&hasauthor[]=1234&hasauthor[]=5678&language[]=nl&language[]=en&category.query=anyof&hasauthor.query=allof

The syntax of <fieldname>.query might be ok, but it might also be good to consider alternative encodings.

Another concern (apart from readability and self-documenting/completeness) is that we can't query nested links (as is also not covered in the first proposal), if I'm correct - to be continued..