Allow alternate / native search syntax

[ralfhandl]

When doing text searches, many of the common algorithms we use have a number of different ways to define a match (Exact match, begins with, synonym, base word or inflection, etc). The $search query parameter defines a search syntax but its definition says it is up to the implementation as to what constitutes a match. This is fine, but in the case where the search engine provides different matching types it would be nice if user had a way to specify how the type of match to be used in the search expression.

This was originally filed as ODATA-1100 / #861 as a request to modify the existing $search syntax to support specifying match type. In discussing the proposal for ODATA-1100 with some users, it was suggested that we do not define our own syntax for specifying match type. There are several common search engines that define a syntax that allows the type of match to be specified. The most common of these is currently is Apache Lucene -
https://lucene.apache.org/core/. Instead of expanding the $search syntax, should we provide a way for the user to specify an alternate or native syntax so that they can utilize the underlying capabilities of the search engine? If we do allow alternate syntax, there is likely a need for some metadata describing what if any alternate syntax a service understands.

Proposal

Make $search a pass-through query option, impose no syntax, and impose no other restrictions than what is necessary to parse the URL.

Make V4 $search syntax just an optional recommendation.

Add a Capabilities term of type URL that allows pointing to the search syntax supported by the service, which may be the V4 $search syntax.

Imported from ODATA-1113

[HeikoTheissen]

Comment by @mikepizzo:

perhaps something like $search:lucene=

could decide if the syntax is a hint or a requirement (since search is fuzzy anyway)

[HeikoTheissen]

Comment by @HeikoTheissen:

An example for context-sensitive search:

StateCode	CountryCode	search predicate	matches?
GA	GE	search(StateCode, 'Georgia')	yes, because GA is the abbreviation of the US state
GA	GE	search(CountryCode, 'Georgia')	yes, because GE is the abbreviation of country Georgia
GA	GA	search(CountryCode, 'Georgia')	no, because GA stands for the country Gabon

In the first row 'Georgia' matches the value 'GA', but in the last row it does not.

Such a behavior could be implemented by mapping OData search expressions to different search models, depending on the property:

OData expression (new syntax proposal)	database predicate
State/search('Georgia')	contains((State,StateText), 'Georgia')
Country/search('Georgia')	contains((Country,CountryText), 'Georgia')

[HeikoTheissen]

SAP wants to use a different search syntax where

• instances that do not contain the term "red" are found by $search=-red
• instances that contain the terms "NOT" and "red" are found by $search=NOT red.

This SAP-specific search syntax is already widely used both with OData V2 (search=-red) and outside OData ("Enterprise search").