Is every event in a report a reporting event?

No; the communication and its subject are distinct.

Can a report describe a future event?

Yes, without establishing that it will happen.

AI Glossary / Natural language and speech / Advanced

Reporting events

Definition

Reporting events are acts of communicating information, such as saying, stating, or reporting something. In natural-language event annotation, the communication is represented separately from the situation being described. For example, a statement that a machine stopped contains a reporting event and a mentioned stopping event; extracting the statement does not independently verify the stoppage.

What it means

A person or organization may describe an occurrence, repeat another person's account, or announce an expectation. The act of communicating can have its own speaker, time, audience, and content.
The distinction matters because the time of a report need not be the time of its subject. A morning message might describe yesterday's interruption or tomorrow's proposed inspection. Collapsing these into one event can put information on the wrong timeline.
TimeML includes REPORTING as an event class. Its annotation guidelines distinguish this class from classes such as perception and ordinary occurrences. Class membership depends on usage in context, rather than a rule that every occurrence of a particular word receives the same label. Other annotation schemes may organize these distinctions differently.

How it works

An extraction system first identifies relevant event mentions in the text. It then classifies the communication event and connects it with its participants and reported content, according to the chosen schema. Event attributes and temporal relations help preserve when the communication and its subject are presented as occurring.
TimeML separates event-class annotation from instance attributes such as tense, aspect, modality, and polarity. It also provides links for relationships between events. An evidential subordination link can connect a reporting event with an event described in its content; a temporal link answers a different question about their ordering.
Applications can add source identifiers and quotation spans for inspection. These fields are application choices, not universal requirements.
The system must preserve scope. “Mira said the test failed” differs from “Mira did not say the test failed,” and from “Mira said the test did not fail.” The first negation concerns the communication; the second concerns its content. Neither distinction is safely handled by deleting the word not.

Three practical examples

A maintenance assistant separates the date a technician sent a message from the date of the interruption described in it.
A news summarizer preserves who made a statement instead of turning an attributed claim into an unqualified assertion.
A meeting-analysis tool distinguishes an announcement about a planned demonstration from evidence that the demonstration has already occurred.

Think of it this way

Think of a dated envelope containing a dated account. The envelope's dispatch and the account's subject occupy different places in the timeline. Reading the envelope tells you something about transmission; it does not prove that everything inside is accurate. A reporting event is more like the communication act than the entire contents.

Worked example

Consider this fictional passage: “At 10:00, Mira said that the pump stopped at 09:20. At 10:15, Noor reported that the pump restarted at 09:50.” Assume all times refer to the same date and time zone, and the account describes one pump.
Identify four event mentions: E1 is Mira's saying, E2 is the pump's stopping, E3 is Noor's reporting, and E4 is the pump's restarting. E1 and E3 are reporting events. E2 and E4 describe equipment occurrences in the reports' contents.
Attach 10:00 to E1, 09:20 to E2, 10:15 to E3, and 09:50 to E4. Connect E1 to its reported content E2, and E3 to its reported content E4. These content connections are different from the chronological ordering E2, E4, E1, E3.
The reported stoppage-to-restart interval is 30 minutes. Mira's communication follows the described stoppage by 40 minutes, while Noor's communication follows the described restart by 25 minutes. The two communications themselves are 15 minutes apart. Treating that 15-minute gap as the equipment interruption duration would confuse reporting times with reported occurrence times.
These calculations are conditional on the statements' content and shared time assumptions. They do not confirm that the pump really stopped or restarted. If the application needs verified operating history, it must compare the account with suitable additional evidence.
Now evaluate a small reporting-trigger detector on this passage. Suppose the reference set contains said and reported, while the predicted set contains said and restarted. There is one correct reporting trigger, one false positive, and one missed reporting trigger. Precision is 1/2=50%, recall is 1/2=50%, and F1 is 50%.
The detector's mistake does not mean restarted is not an event mention. It means that, in this passage and task, it is not a reporting-event trigger. Trigger classification, correct content linking, time attachment, and factual verification are separate checks. This invented example is not a benchmark result or a complete TimeML annotation.

Illustrative case study

Fictional example: ShiftTrace summarizes workshop messages. Its first version lists an equipment restart at the time a supervisor reported it. Reviewers discover that the message explicitly places the restart earlier.
The team stores the communication and equipment-event times separately and displays the original passage beside the summary. It also retains the supervisor as the source of the restart claim. This fictional revision improves inspectability; it does not establish accuracy.

Common misconceptions and mistakes

A reporting event is not the same as everything reported in a document. Communication time, publication time, and content-event time can differ. A document can also contain nested attribution, where one speaker reports what another speaker said.
Another mistake is assuming that an extracted statement is verified truth. Preserve attribution and uncertainty. Do not assign a reporting class solely from an isolated word, or treat every event mention as an affirmative claim that the event occurred. Negated and hypothetical content still requires interpretation.

Business use

Use separate fields for communication, attributed source, described event, and time where the application requires them. Review examples containing delayed reports, future plans, negation, and nested quotations. Measure errors in attribution and temporal attachment alongside event detection, because a correctly located trigger can still feed a misleading summary.

Check your understanding

How many reporting events appear in the example?

Answer: Two.

What interval separates the described stop and restart?

Answer: Thirty minutes.

Why is restarted a false positive for the detector?

Answer: It describes equipment behavior, not communication.

Related terms

Event extraction
Modality
attribution
temporal relation
TimeML
event trigger
polarity
reported speech

Learn next

Annotate a short passage with separate communication and content events. Check each source, time, and negation before constructing a timeline.

Sources

Jurafsky and Martin, Speech and Language Processing, chapter 21, event extraction: https://web.stanford.edu/~jurafsky/slp3/21.pdf TimeML Working Group, annotation guidelines version 1.1, reporting events and event links: https://timeml.github.io/site/publications/timeMLdocs/annguide_1.1.pdf TimeML Working Group, specification 1.2.1, event classes and instance attributes: https://timeml.github.io/timeMLdocs/TimeML_1.2.1a.html

Previous: Reporting bias Next: Representation