Querying on string properties

With Report Builder, you can use strings for conditions for both string and numeric properties.

Consider the following rules for querying on string properties:
Case sensitivity
  • The following case-sensitivity applies to queries for is and is not operators:
    • Case-insensitive for tags, such as dcterms: subject.
    • Case-sensitive for all other string properties.
  • Queries for other operators such as contains, does not contain, starts with, and ends with are always case-insensitive.
Quoting
Strings might include quoted strings anywhere in them in which the quoted text is enclosed in either paired single quotation marks (') or paired double quotation marks ("). When paired quotation marks are used, the quotation marks themselves are not part of the text. The text between the quotation marks is parsed literally without removing white spaces or treating characters, such as comma or asterisk.

The underscore (U+005 F) is used to represent a space in the following examples.

  • The string 'abc_,_def' is parsed as the single value abc_,_def.
  • The string "_abc_" is parsed as _abc_.
An unpaired quotation mark and any text that follows it is parsed literally, which helps in differentiating between English and French phrases, for example:
  • John’s laptop is an English possessive.
  • Doesn’t is an English contraction.
  • L’ecole is a French contraction.
Leading and trailing white space
In unquoted strings, leading and trailing white space is removed.
The underscore (U+005 F) is used to represent a space in the following example.

The string _abc_ is parsed as abc.

Comma-separated values
Unquoted commas are used to separate multiple values. Each unquoted value from the multiple values must not contain leading and trailing white space.
For example, abc,def is parsed as two values: abc and def.
Backslash escapes

When the string is initially parsed, valid backslash escape sequences are replaced with their equivalent character. The invalid backslash escape sequences are removed. The Report Builder shows a warning if an unsupported escape sequence is specified. The user might ignore the warning and save the query condition.

For example, the string \"Hello\" is parsed as "Hello".

The following backslash escape sequences are supported for querying on string properties:
Table 1. Unicode code point for backslash escapes
Escape Unicode code point
\t U+0009 Tab
\n U+000A Line feed
\" U+0022 Quotation mark or double quotation mark
\' U+0027 Apostrophe or single quotation mark
\\ U+005C Backslash
Querying rich text
When querying strings that contain &, <, >, or newline, only solutions whose rendered value contains those characters are shown.
LQE SPARQL
The LQE SPARQL filter parses the OR conditions for any string condition value that contains &, <, >, or Newline.
  • For datatype rdf:XMLLiteral rich text strings, the SPARQL filter matches a string with the following replacements:
    Table 2. String replacements for XMLLiteral strings
    Character Replaced with string
    & &amp;
    < &lt;
    > &gt;
    newline <br></br>
  • For all the other string literals, the SPARQL filter matches the original string.
Lifecycle Query Engine relational store
The following normalization applies to all query condition values for strings:
  • XMLLiteral strings store text as supplied.
  • Non-XMLLiteral strings are normalized at indexing time:
    Table 3. Normalization of non-XMLLiteral
    Character Replaced with string
    & &amp;
    < &lt;
    > &gt;
    newline <br></br>