Relation, Event, and Temporal Extraction › From Mentions to Statements

The following one-way pipeline illustrates how an early decision can affect later records.

1. Mention detection: find entity, event trigger, and timex spans. One way to do this is sequence labeling, covered in Part VI.
2. Entity linking: map mentions to canonical identifiers in a knowledge base. We'll cover this in the next chapter.
3. Relation and event extraction: build typed structures over those canonical entities.
4. Temporal grounding: attach times and compute orderings.
5. Aggregation: merge structures across mentions, sentences, and documents into a knowledge base.

Steps 3 and 4 are this chapter. Step 2 is Entity Linking and Knowledge Graph Construction, and step 5 is really a data engineering discipline as much as a modeling one.

This is one useful pipeline order, rather than a requirement for every architecture. The explicit span pipeline illustrated above detects mentions before classifying structures over them; joint and generative models can predict these outputs together. Entity linking supports aggregation across aliases, although a system can aggregate surface strings before resolving their identities. Relation and event extraction recover statements, temporal grounding attaches time information, and aggregation must preserve unresolved identities and contradictions rather than silently merging them.

Each stage also has its own error profile. Mention detection misses spans, entity linking conflates entities, relation extraction invents links, event extraction confuses roles, and temporal normalization assigns the wrong date. In a one-way pipeline, an early mistake can survive all the way to the final knowledge base. A missed organization mention in the first stage can cause a relation to disappear, which can cause an event to lose an argument, which can cause a timeline to be incomplete. Keeping provenance lets a reviewer trace a suspicious final record back to its claimed supporting span.

These tasks predict structures anchored in text. Relation arguments and event triggers can identify spans, while temporal normalization also outputs values such as dates and durations. A system can use token labels for recognition and then assemble structured records. That has three consequences.

First, the output space is combinatorial. Enumerating all ordered pairs of distinct entity mentions gives $n(n-1)$ candidates. A document with 40 mentions has 1,560 such pairs; one with 100 has 9,900. Positive-label prevalence depends on the corpus and schema. Candidate pruning can reduce computation, although batching or joint scoring can also handle many pairs without discarding them.

Count the candidate pairs before choosing an exhaustive scoring design. The following computation makes the candidate space explicit before any model scores a pair.

The candidate count sets the number of pair scores in an exhaustive design. Type constraints and distance filters can discard candidates; batching can instead change how those scores are computed. A filter can also discard a true relation, so compare its recall and computational cost.

Second, records can retain span provenance. A record can point back to the text using evidence strings and offsets. These references enable substring and location checks, although a wrong relation can pass both checks when its strings occur in the source. The Evidence and Grounding example shows offsets. The LLM example checks whether selected strings occur in the document. If a system extracts Acme’s report that it acquired Bolt, it should be able to identify the tokens that support that attributed claim. That evidence is useful for debugging, for audit, and for deciding whether to trust a prediction.

Third, the schema is a design decision. Deciding whether Acme acquired Bolt is one relation or an Acquisition event with fields for the buyer, target, price, and time, and whether Acme and Acme Corp are the same node, determines what your downstream system can answer. Open IE leaves the relation phrases open while still choosing output fields, such as subject, predicate, and object. Canonical queries require a mapping between those predicates and the requested relation types.

The three tasks differ in output structure, which constrains what a model must predict and informs its design.

Keeping these apart matters. A paper reporting "F1 on event extraction" may mean trigger classification, argument identification, or argument role classification. These scores can differ within one experiment: the JRNN result discussed below reports 69.3 trigger-classification F1 and 55.4 argument-role F1. Comparing the numbers without checking their prediction units can produce a ranking of systems measured on different tasks.

The same ambiguity exists in relation extraction. Mention-level F1 and entity-level F1 measure different decisions, and a system that looks strong at the mention level may look much weaker when it must aggregate evidence across a document. Temporal extraction has an analogous split between timex recognition, timex normalization, and pairwise temporal relation classification. These are separate prediction targets; report each metric when its corresponding task is in scope.