Roles and Event Predicates

This section is on roles and event predicates.  Roles are predicates that relate components of events to events.  Event predicates provide a distinct means of representing the ways that events and their components are related to one another.

Roles in Cyc

  Roles are specialized predicates developed for the purpose of relating components of events to events.  There are two general specializations of the collection #$Role.  They are #$ActorSlot and #$Sub-ProcessSlot.  In the following section we will discuss actor slots and in the last section we will discuss sub-process slots.

Roles are arranged in a predicate hierarchy based on #$genlPreds.  The top node of the hierarchy is #$actors.  Every instance of #$Role is a specialization (a.k.a. “spec. pred”) of #$actors.

Roles include many kinds of relations

Roles include many kinds of relations between a situation and its components. For instance, in an event which is a reading of a book, there are many components.  There is the person doing the reading, there is the book being read, there’s the information in the book that’s being transferred to the person doing the reading, and there are sub-events (such as the reading of each individual page).  Roles relate those components to the reading of the book.

In a naval battle there are many components which would be related to that naval battle via roles.  These include the groups engaged in the battle, the attack undergone, the officers who direct the battle, all of the different devices that are used in the battle, and other kinds of sub-events (such as the signals that occur between ships during the battle).

Representing roles in CycL

Here are some examples of CycL sentences with roles in the arg0 slot.  #$performedBy, #$informationOrigin, #$eventOccursAt, and #$topicOfInfoTransfer are all instances of #$Role and they specify a role that an individual plays in a particular reading event.

So, what do you think these mean?

Representing roles in CycL

The translations are italicized.

Representing roles in CycL

 See if you can translate these before going on to the next slide.

Representing roles in CycL

 Here are the translations.

Ontologizing with roles

So, we can use roles to describe particular situations and events with CycL predicates.  But even more importantly, we can use roles to reason in general terms about kinds of situations and the kinds of things that are involved in them.

Using rules with roles, we can state common-sense generalizations such as: “anything reading a book must be an intelligent agent,” “anything being read must be textual material,” or “after a reading event, the reader is familiar with the information contained in the thing read.”

In CycL, we generalize by quantifying over the individual events and their components.  With this ability to generalize, we can infer more information about situations from the information that we already have.  And note that quantification also enables us to ask Cyc questions that cover entire classes of situations and roles.

Rules that use roles

Here are some CycL rules that capture general knowledge about roles, including knowledge about the kinds of things that are related by certain roles.

Can you tell what the first one says?

It says: “In every instance of #$Reading that has a source, that information source is textual material” (a separate assertion should tell us that every instance of #$Reading does have an information source).  In other words, “Whenever someone reads, they read text.”

What does this next one say?

It says: “Any reading event done by a blind person is also an instance of perceiving by touch.”  In other words,  “Blind people read by touching.”

Note that we could further infer that what is being touched is the object containing the textual material.  An important additional use of roles is also to establish inferentially ascertainable relations between items that are related (by roles) to the same situation.

Rules that use roles

  Here are some more examples.

What does the first rule say?

It says: “For every instance of #$SeaBattle, there is some [instance of] #$BodyOfWater where that event occurs.”  Or, “Every sea battle occurs at a body of water.”

The second rule says, “Anyone who is involved in a sea battle is able to swim.”  (Is that true?  Alas, no.)

Inferencing using roles

  Here are some examples of how the common sense knowledge represented in Cyc, with the #$genlPreds relation between roles and some of the rules stated on roles, enable Cyc to make some common sense inferences.

Look at the two assertions.  First of all, #$NelsonPlanningTrafalgarAttack is an instance of #$PlanningToDoSomething.  Second of all, #$NelsonPlanningTrafalgarAttack is done by #$HoratioNelson.  From these assertions, Cyc can conclude that, first of all, #$HoratioNelson is an intelligent agent.  Cyc knows this because Cyc knows that anyone who plans to do something must be an intelligent agent.  Further, Cyc can conclude that Horatio Nelson performs the planning of the Trafalgar attack because Cyc knows that anything that’s done by an agent is also performed by an agent.

#$Role has important sub-types

#$Role has two specializations (i.e., sub-collections or “specs”): #$ActorSlot and #$SubProcessSlot.  #$ActorSlot is the largest sub-collection of #$Role.   Instances of this collection are predicates that relate specific events to things that are somehow “involved” in those events.   Instances of #$ActorSlot account for two-thirds of the instances of #$Role.  Some important instances of #$ActorSlot are #$performedBy and #$objectActedOn.

Another  important specialization of #$Role is #$SubProcessSlot. Sub-process slots account for about one-third of the instances of #$Role. Instances of this collection are predicates that relate specific events to temporal parts of those events.  The most important sub-process slot is #$subEvents.  Every instance of #$SubProcessSlot is a spec pred of #$subEvents.

There are a few instances of #$Role that don’t fall under either the #$ActorSlot or the #$SubProcessSlot collection.  These role predicates typically don’t fall into the other more specialized collections because they aren’t binary.  Every actor slot and every sub-process slot is a binary predicate.  These other #$Role predicates are usually ternary or variable-arity.  For instance, #$objectsInContact could specify any number of different things that are in contact during an event.  It need not just be the event and one thing in contact.  It’s usually going to be at least the event and then two things in contact.

An Alternative Representation: Event Predicates

There is an alternative method for representing events which does not require reifying them: event predicates.

Using the event/role method of describing events and their interrelations and their relation to their components, requires saying something like “There is an attack; it’s an instance of #$MilitaryAttack; that which plays the role #$performedBy in the #$MilitaryAttack is the #$BritishFleet; and that which plays the role of #$maleficiary in the attack is #$NapoleonsEgyptianFleet.”  Instead, we can say something that, on the surface, looks a lot simpler: “The #$BritishFleet attacks #$NapoleonsEgyptianFleet.”

As I said, on the surface the second method looks a lot simpler.  That’s because it’s closer to natural language.  Few people will state something in a way as complex the way the first assertion.  They’ll typically say something like “the British fleet attacks Napoleon’s Egyptian fleet.”  But, in fact, that simple statement can be expanded into the complex one.

The Event Representation can be Recovered

Cyc knows that anything that militarily attacks anything else does so during a military attack.  Cyc also knows that that which is attacked in an attack is the #$maleficiary of the attack.  So, the simple-looking assertion that is closer to natural language can be expanded into something like the more complex assertion automatically by Cyc.

Specializations of #$EventPredicate

There are two important kinds of #$EventPredicate: #$ActionPredicates and #$ScriptPredicates.  We use #$ActionPredicates to make assertions about actions performed by agents and we use #$ScriptPredicates to make assertions about instances of #$ScriptedEventType.

#$ActionPredicates usually relate two agents to each other or an agent to something, and they specify what the agent is doing.  #$ScriptPredicates typically relate various different event types to one another and establish their order in a typical performance of an event.  So, consider the brushing of teeth.  What comes first?  Well, in most cases wetting the toothbrush comes before putting the toothpaste on the toothbrush.  We establish that by using assertions that use instances of #$ScriptPredicate.


  In summary, there are many kinds of roles in Cyc.  Roles relate components of events to events.  We can state general facts using roles and rules, which gives a lot of inferencing power to Cyc.  The two most significant specializations of #$Role are #$ActorSlot and #$SubProcessSlot.  And event predicates are an alternative to roles.