Events in Cyc

This section will survey Cyc’s representation of events.  This section will tie up with later sections where we’ll see how components of events are related to events in Cyc by roles, such as actor slots and sub-events.

Events in Cyc

Events in Cyc are represented as individuals that belong to a collection called #$Event .  These individuals have components; that is, they’re not empty stretches of space or time, they have parts.

They are also situations. By “situation” we mean any configuration or arrangement, such as a group of people, their equipment, etc., in a room, at a specific time; or just that computer sitting on the table; or some birds flying outside.  Situations have structure, precise or “fuzzy.”

Events also have temporal extent.  That is, they occur over time.  So they’re different from arrangements such as geometric configurations or abstract mathematical series, which are also configurations of individuals, but they’re not extended temporally.

Finally, events are dynamic.  That means that they can change over time.

Most individual events in Cyc are classified, not just as instances of #$Event, but as instances of a more specialized collection of #$Event.  So you wouldn’t see #$Event001 reified in the Cyc KB, you’d more likely see #$Reading001, #$Negotiating001, or #$PoliticalCampaign001, or some other instance of some more specialized collection.

Partial hierarchy for #$Event

  This slide provides a glimpse of the #$genls hierarchy of the collections surrounding #$Event.  As you can see, #$Event is indeed a specialization of #$Situation-Temporal, and that’s how Cyc knows events are arrangements of objects that extend over time.  Also, you can see that #$Event is not a specialization of #$RelationalStructure, and that’s how Cyc knows that events are different from abstract geometric or mathematical series.  Events are dynamic, so #$StaticSituation is a sibling collection for #$Event.  #$StaticSituation collects situations that are extended in time but don’t change, whereas the collection #$Event collects the situations that are extended in time but do change.  Under #$Event you see some of the more general specializations of event.

This is really just the tip of the iceberg.  There are many many more specializations of #$Event.

Why Reify Events?

Why do we reify individual events (instances of #$Event) in Cyc?  If our knowledge changes about an event, having a reified data structure to represent the event enables us to add information or alter the representation in Cyc very easily.

Also, because kinds of events are related to each other in the #$genls hierarchy, we can use that hierarchy to inherit knowledge downward from the more general types of events to the more specialized types of events.  So for instance, if we have the general event collection, #$TransportationEvent, and we state about that collection that anything that travels during a transportation event moves from an origin to a destination, then Cyc will know that this is also true of specializations of #$Transportation event, such as #$SubmarineTransportationEvent or #$BicycleTransportationEvent.  More specialized knowledge will also hold in those cases.  We’ll know that for an instance of the #$BicycleTransportationEvent the device used was a bicycle, and still the more general assertions hold.

As we will see, roles too have a hierarchy that extends Cyc’s ability to reason about the components – the participants and sub-parts – of events.

Components of events

There are all kinds of things that can be components of events.  Events can have performers, and there can be devices that performers use during the events.  Events can have sub-events, or sub-stages.  Events can occur at places, and those places are somehow involved in the events.  Events take place at time, and times of events are also somehow involved in events (we have special predicates to relate times to events).  We state how components of events are involved in events with roles predicates – predicates that are instances of the collection #$Role.

Using Roles

For example, consider the event that is the Battle of the Nile.  It is a fairly complex event in which a number of things are involved.  In a sense, the year 1798 is involved in the Battle of the Nile, because that’s the year in which the battle occurred.  Abu Qir Bay is in involved in the event, because that’s where the event occurs.  Horatio Nelson is an actor in the event.  The British Attack is a sub-event of the battle, as is the French Defense.  And so on.

Roles and Events

In CycL we use special predicates called “roles” to relate reified events to their components.  We build a lot of knowledge into the construction of role predicates to help Cyc understand how these roles function to relate components of events to reified events.


In summary, events are a certain kind of individual that we find useful to reify in order to increase inferential efficiency.  Events are the sorts of things that have components.  We use roles to relate components of events to events.