Page Comparison

...

• 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.

...

• qt[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'-'M'-'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).noformat

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.

...

{
	"entity1": { ... }, // the "subject"; can be ftext, etext, or entity/entityValue/entityType/entityValue query terms
	"entity2": { ... }, // the "object"; can be ftext, etext, or entity/entityValue/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.

Some things to note while performing entity queries:

• The "entity1" field is processed as follows:
  • "ftext" and "etext" terms are applied across both the "entity1" and "entity1_index" fields within the entity object (TBD link)
  • entity/entityValue/entityType terms are only applied to the "entity1_index" field
• The "entity2" field is processed analogously 
• The "verb" string is applied as an exact text query to the "verb_category" field and a free text query to the "verb" field within the entity object (TBD link)
• For events with a time range ("time_start" and "time_end" fields), any part of the event time range can match the "time" term.
• The difference between "Events", "Facts" or "Summaries" is described here (TBD link).
• If multiple terms are specified then these are ANDed together. There is currently no way of performing more complex boolean equations on individual events (obviously multiple event query terms can be specified and match across all events within a document).
• Event queries with multiple terms can be a bit slower than other queries (due to its implementation in ElasticSearch).

  Code Block
  language javascript title Example event queries
  // Any fact in which Barack Obama is the subject: { "event": { "entity1": { "entity": "barack obama/person" }, "type":"Fact" } } // Travel events involving Sarah Palin: { "event": { "entity1": { "entityValue":"sarah palin", "entityType":"person" }, "verb": "travel", } } // Events in the future: { "event": { "time": { "min": "now" }, "type":"Event" } }

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 qt[0].etext="apple"&qt[1].ftext="pair"&logic="1 and 2"

...

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

TBD Some things to be aware of when making raw queries:

...

• "raw" queries overrides other query terms - so only the "raw" query is performed.
• All other aspects of the query are still take from the URL/JSON Object, ie:
  • Only documents from the specified communities and the specified inputs are processed
  • Once documents matching the "raw" query have been retrieved by the server, they are ranked according to the "score" object
  • The format and number of documents returned to the client are determined by the "output" object.
• It is not currently possible to specify both "raw" queries and "raw" aggregations (facets) within a single query.