`q` parameter semantics?

[m-mohr]

The q parameter is not really defined in depth. Currently, I'd understand that a strict matching of the given string is applied, e.g. if q=hello world it would not match "Hello World" and also not "hello my world", but "this is hello world". What about "hello worlds"?

In STAC there's a proposal for a q parameter that is defined at https://github.com/cedadev/stac-freetext-search#examples I feel it is too complicated and such expressions should be formed via CQL better. So maybe we should aim for a "q" queryable as well?

Some important questions should be answered at least for the current q parameter, I think:

• Are multiple words strictly matched (see examples above)? If not, is the modus operandi "and" or "or"? Can users use "and" and "or" explicitly?
• Is it case (in)sensitive?

My point of reference was https://docs.ogc.org/DRAFTS/20-004.html#_parameter_q

[pvretano]

@m-mohr item C of the requirement says that searches using the Q parameter are case insensitive.

There is a pull request that defines what the response should be if q is specified and it says that resources that contain one OR more of the specified search terms should be included in the response. So if q=hello world, then hello my world, 'this is hello worldand 'hello words would all be hits because each one contains one or more of the specified search terms.

[m-mohr]

Thanks, yeah, I found C later. The PR mentioned helps clarify. I've added a comment to the PR for clarification. If the comment has been solved, this issue can be closed with the PR.

• Case insensitive
• OR operator used for search term
• No explicit and/or/search term exclusion/... etc.

[pvretano]

06-JUL-2023: Will create PR to address #295 and will close this one along with that one.

[pvretano]

11-AUG-2023: Closing since PR that addressed #295 (i.e. #301) also addresses this issue.