Search Query Language
The search functionality has a syntax that allows for more precise searches. The highlights of the syntax is described below.
The data in the Search! index comes from different sources. The exact source of every field and facet is decsribed in this article.
|Mag niet bevatten||-zoekterm|
|Bij elkaar in de buurt||[manager sales]|
|Of de een of de ander||(rotterdam amsterdam)|
Java developer Amsterdam
If a keyword contains special characters, such as [#$%.+/’], it will be interpreted as a phrase (see phrases below) and the special characters will be ignored. There are a number of cases where special characters are not ignored:
- internal apostrophes: e.g. O'Reilly, O'Reilly's
- acronyms: e.g. U.S.A., I.B.M.
- company names with & or @: e.g. AT&T, Excite@Home
- email addresses and host names: e.g. firstname.lastname@example.org, www.geocities.com
- common technical terms: e.g. C++, C#, and SQL*Plus
Keywords are not case sensitive, that is "Java", "JAVA" and "java" are the same.
Adding keywords to a query further limits the result set. In the example above, adding Ams- terdam will return results containing Amsterdam in addition to Java and Developer. An empty query, that is without any keywords, returns all.
There is a limit of keywords when searching. 50 to 60 keywords should not cause any problems. Of course it may work when using over 60 terms, but there is the risk of making the query too large and hence producing an error.
"Java developer" Amsterdam
Phrases are used to match a sequence of words. Special characters are ignored inside a phrase.
[Java developer] Amsterdam [developer C++ Java]
Query terms within  match if they occur in the document in any order, possibly with one or two words in between. Proximity matching is more flexible than phrases, e.g. the above query [Java developer] also matches documents containing “java software developer” and "java en- terprise software developer".
Search! allows to perform wildcard queries. If a query term ends with a trailing * it gets ex- panded to the most common completions. Documents containing any of the found completions will match. For example, the above query develop* will match on developer, development, de- veloped, etc. A few restrictions apply:
- The * symbol must be placed at the end of a word.
- The * symbol needs to be preceded by at least 2 characters for it to work on external searchers.
- Wildcard terms cannot be part of phrases or proximity expressions.
For external searchers that do not support wildcard search by themselves, Search! uses its own auto-completion engine to generate completions for the wildcard expression. In that case, the expansion terms are based on the configured dictionaries.
developer [software engineer] #1.5 "software architect" #0.8
Terms are weighted within a query by adding a number weight behind the term. If no weight is specified, a term receives a default weight of #1.0. The weight influences the ranking of doc- uments of the weighted query expression in relation to the other expressions of the same field. Weights can also be assigned to more complex query expressions, such as phrases, conditions or range queries.
In the example above [software engineer] contributes 1.5 times as much to the result score as normal and "software architect" 0.8 times as much. Weights only influence the relative impor- tance among query parts belonging to the same field. Example:
developer experience:[software engineer] #1.5 "software architect" #0.8
The weight of 1.5 given to [software engineer] will be ignored in this case. Since [software en- gineer] is the only query expression on the experience field, there is no other query expression where the weight would relate to.
Also, weights inside an OR-combination are ignored.
Java developer city:Amsterdam
experience:[Java developer] Amsterdam
If a term, phrase or proximity expression should be matched on a certain metadata field or section of a document, the query expression needs to be preceded by the field name and a colon. The above query searches for the word Amsterdam only in the city field of the document, respectively for java developer only in the experience section.
All fields are described in a seperate article.
Numeric / Date Range Conditions
Java developer experience:>2
Java developer experience:5..10
Java developer date:<2010-10-01
Numeric or date (range) conditions are expressed by "<",">","=" and "..". Dates must be of yyyy-mm-dd format. Numeric or date conditions are always assigned to a specified field.
Java developer location:Amsterdam+20
Java developer location:1018+20
Java developer location:"New York"+25
Location (+radius) conditions are expressed by naming a location (city name, postal code, geo coordinates) followed by a radius in kilometers after the "+" symbol. If the radius is omitted only exact matches are returned.
If a query consists solely of nice-to-have expressions, than the result consists of all documents ranked by the nice-to-have expressions.
In the API the nice-to-have query parts are marked with condition FAVORED.
Java developer -city:Amsterdam
Query expressions marked by a preceding - are banned expressions, they exclude all docu- ments matching this expression from the result.
OR Groups / Specifying Synonyms
compskills:(C C++) Amsterdam
([java developer] [software developer])#2 Amsterdam
Alternative search terms can be combined in an OR group by surrounding the expressions in brackets (). This is useful for specifying a list of synonyms or to allow multiple required facet items. In the example above, capturing both C and C++ in an OR-group ensures that all docu- ments contain either C or C++ as a computer skills as well as containing Amsterdam. The sec- ond example shows that weights can be used within an OR-group. OR-groups may be used on the full text (second example) or on a specific field (first example), they may not be nested.
A user can indicate which hard criteria are relevant for a certain job and based on that the matching is started. As a result, the application will provide a list of candidates sorted from the highest to the lowest score on the hard criteria that are used in the matching. Via Connexys Setup > Application Settings > All settings > Hard criteria you can set the default language in which Hard Criteria are entered.