The KQL syntax supports a sequence of expressions (the expression-list element) without any operator between the expressions. In this case, there is an implicit operator between the expressions. The implicit operator is either AND (section 2.1.2) or OR (section 2.1.8).
If the query contains any non-property operator (ALL (section 2.1.1), AND (section 2.1.2), NOT (section 2.1.6), XRANK (section 2.1.10), and so forth), the query MUST be evaluated as if the implicit operator is AND (section 2.1.2).
There are other special cases regarding the use of the implicit operator. See section 220.127.116.11 for the use of the implicit operator in combination with qualified string tokens, and section 2.2.4 for the use of the implicit operator in combination with property restrictions.
eDiscovery seems to use implicit
OR by default, and only switches to
AND when things get more complex. To force
AND wrap keywords in parenthesis.
Microsoft makes this claim:
The following [sets of] queries match the same items:
cat +dog cat AND dog
But in testing with eDiscovery Standard, this query:
(participants:"user1" OR participants:"user2")
This may be related to the handling of Implicit operators mentioned above.
However, the claim below that appears to be correct:
cat -dog cat AND NOT dog
This rendered correctly as
(participants=user1 AND (NOT (participants=user2))).
“Condition cards” are built in the Purview (previously Compliance) eDiscovery Standard, and the property name
c with values
s (must be inside parenthesis) are reserved there to separate compiled card queries.
(c:c) is similar to logical
(c:s) is similar to logical
OR. They are used to separate keywords into groups, so that each group can be individually tracked for the number of results returned for that particular group, and so that queries can more easily be transformed into raw KQL and back.
:) vs equality (
Equality is an exact match to the property, while contains is a word match and supports suffix wildcard with
*. KQL does not support prefix wildcards.