Page Comparison

...

For example, { "qt": [ "ftext": "barack obama" ] } will match on any documents containing either "barack" or "obama", with documents containing both scored more highly (TBD link to scoring params). { "qt": [ "ftext": "+barack +obama" ] } requires both be present (but not necessarily in the same phrase), and { "qt": [ "ftext": "'barack obama'" ] } is equivalent to the "etext" query described above.

Other examples:

• qt[0].ftext="+obama -palin": documents containing the word "Obama" but not containing the word "Palin"
• qt[0].ftext="title:\"palin\"": documents with the word "Palin" in the title.

...

In both cases, the optional "entityOpt.expandAlias" boolean term will allow matching not just on the entity but also on common aliases. This will tend to have the effect of matching on more documents, some of which will be false positives however. This query type is also slower.

Some examples:

• qt[0].entity="facebook/company": will match on documents containing references to the company Facebook, but not the technology.
• qt[0].entityValue="facebook"&qt[0].entityType="company": equivalent to the above
• qt[0].entityValue="facebook": will match on both uses of the term Facebook
• { "qt": [ { "entity": "barack obama/president", "entityOpt": { "expandAlias": true } } ] }: will match on documents containing references to Barack Obama, but also other common text strings such as "Barry Obama", "President Obama" etc.

...

The "dist" string is a distance in the format "<distance><unit>" where <distance> is an integer or floating point number, and unit is one of "m" (miles), "km" (kilometers), "nm" (nautical miles).

Examples:

•  qtqt[0].geo.centerll="40.12,-71.34"&qt[0].geo.dist="100km": within 100km of the specified lat/long.
• { "qt": [ { "geo": { "centerll": "40.12,-71.34", "dist": "100" } } ] }: uses the default unit (km), ie is the same query as above.
• qt[0].geo.minll="(4.1,-171.34)"&qt[0].geo.maxll="40.12,-71.34": bounding box showing lat/long format with and without parantheses.

...

• "now" which always resolves to the current time, 
• any Unix time (ie milliseconds after "Jan 1 00:00:00 1970"), 
• and the following date/date-time formats:   "yyyy'-'DDD", "yyyy'-'MMM'-'dd", "yyyyMMdd", "dd MMM yyyy", "dd MMM yy",   "MM/dd/yy", "MM/dd/yyyy", "MM.dd.yy", "MM.dd.yyyy", "dd MMM yyyy hh:mm:ss", "yyyy-MM-dd" (ISO Date), "yyyy-MM-ddZZ" (ISO Date-Timezone", "yyyy-MM-dd'T'HH:mm:ssZZ" (ISO DateTime-Timezone), "EEE, dd MMM yyyy HH:mm:ss Z" (SMTP DateTime).

Examples:

• { "qt": [ { "time": { "min": "1284666757164", "max": "now" } } ] }: from 16 Sep 2010 until now.
• qt[0].time.min="now": any time in the future.
• qt[0].time.max="20100201": any time before 1 Feb 2010.
• { "qt": [ { "time": { "min": "02/10/2000", "max": "10 Feb 2001 13:00:00" } } ] }: from 10 Feb 2000 until 10 Feb 2001 at 1pm.

...

The event query format is slightly more complex than the others. It is also slightly more limited.

The event format is as follows:

{
	"entity1": { ... }, // the "subject"; can be ftext, etext, or entity/entityType/entityValue query terms
	"entity2": { ... }, // the "object"; can be ftext, etext, or entity/entityType/entityValue query terms

	"verb": string,

	"geo": { ... }, // geo query term
	"time": { ... }, // time query term

	"type": string // "Event", "Fact", or "Summary"
}

As can be seen from the above code block, the event query term is a composite of other query term types.

TBD

Combining query terms

Multiple query terms can be combined in 2 ways:

• Using the "logic" field as described under "Overview of querying". This is the standard way of combining separate queries.
• In addition, within a single query term multiple elements of different types can be merged into a single object - this has the effect of ANDing them together. For example:
  • { "qt": [ { "entity": "barack obama/person", "time": { "min": "1284666757164", "max": "now" } } ] }: documents containing the entity Barack Obama, from 16 Sep 2010 until now.
  • qt[0].etext="apple"&qt[0].ftext="pair": this is equivalent to qtto qt[0].etext="apple"&qt[1].ftext="pair"&logic="1 and 2"

Raw ElasticSearch queries

At present ElasticSearch is used as the front end of the search engine. 

The system provides a "passthrough" interface for full (or "raw") ElasticSearch queries. Obviously this capability is for advanced use only, and should be avoided where possible.

The ElasticSearch API and Query DSL is described in detail on their web-site, and it is beyond the scope of this documentation to go into any more details. Only the "search" call and the "facet" call (accessed from the "aggregation" object link TBD) are available.

The search call can be placed inside the "raw"

...

XXXobject from the top level as follows:

// Syntax:
{
	"raw": {
		// Put fields and objects from the top level ElasticSearch "query" object here
	}
}
// Example:
{
	"raw": {
		"match_all": {}
	}
}