Event queries
Odinson also supports event queries, which are look for a trigger, and then one or more required (or optional) arguments. These arguments are defined in terms of their connection to the found trigger.
As an example, consider this simple event rule that finds the subject and object of the verb cause:
- name: example-event-rule
label: Causal
type: event
priority: 1
pattern: |
trigger = causes
subject = >nsubj []
object = >dobj []
The result of applying this rule to a sentence such as "Rain causes puddles" is a Mention, which has a trigger (causes), and two arguments: a subject
(Rainfall), and an object
(puddles).
Since we did not specify any labels for the type of the subject and object arguments, they will have the same label as the overall event (Causal
).
Priorities
One element of an event query is the priority
. This is the order in which the rule(s) should be applied. This is useful when you wish to rely on the output of a previous rule in another rule.
For example, in these two rules, we first find Person
Mentions, and then extract Construction
events:
- name: person-rule
label: Person
type: basic
priority: 1
pattern: |
[Hamilton]
- name: construction-rule
label: Construction
type: event
priority: 2
pattern: |
trigger = [lemma=build]
subject: Person = >nsubj []
Here, the engine will first apply person-rule
, then construction-rule
, due to the order indicated with the priorities.
By adding the type specification to the subject
argument (subject: Person
), we indicate that the subject of the trigger must be a previously found Person
.
However, if we instead want to allow the rule to match even if the found subject is not a Person
, we can make use of promotion.
Argument Promotion
Argument promotion allows us to extract nested events in the moment, without requiring them to have been previously found.
This feature must be enabled, using the ^
, as shown here:
- name: construction-rule
label: Construction
type: event
priority: 2
pattern: |
trigger = [lemma=build]
subject: ^Person = >nsubj []
Here, if the subject was not already found as a Person
, we will still extract the event, and we will assign the label Person
to the found subject.
Optional and Required Arguments
Event arguments can either be optional or required, where required is the default. An optional argument will be extracted if present, but will not prevent the event from succeeding if not. Required arguments, on the other hand, will cause the event query to fail if they are not found.
Optional arguments are indicated with a ?
, as with the second argument below.
- name: construction-rule
label: Construction
type: event
priority: 2
pattern: |
trigger = [lemma=build]
subject: Person = >nsubj []
structure: Building? = >dobj []
Quantifying arguments
Arguments can be quantified, using the quantifiers described here. For example:
- name: lots-of-quantifiers
label: Eating
type: event
priority: 2
pattern: |
trigger = [eats]
subject: Person{1,2} = >nsubj []
food: ^Dessert+ = >dobj
tool: ^Utensil* = >nmod_with
In order to succeed, this query must find an instance of the word eats
with one or 2 Person
mentions as the subject(s), and one or more Dessert
mentions as food arguments. If available, it will also match 0 or more Utensil
mentions as tool arguments.