## A note on #$ActorSlots and their use

E-Mail Comments to: opencyc-doc@cyc.com
Last Update: 3/28/2002
Copyright© 1996-2002 Cycorp. All rights reserved.

Return to Documentation Contents
Return to Vocabulary Contents

## What is an #$ActorSlot?

Actor slots are the predicates that Cyc uses to express relationships between an event and the participants in it (in other systems similar things are called participant roles, (deep) case roles or thematic relations). Because an actor slot is a binary relation, the collection #$ActorSlot (the collection of all actor slots) is a subcollection of #$BinaryPredicate. The first argument of an actor slot is an instance of #$Event; the second is an instance of #$SomethingExisting. For example, the assertion (#$buyer #$BikeBuying001 #$Kim) means that in the #$Buying event #$BikeBuying001, the buyer is #$Kim. The assertion (#$objectPaidFor #$BikeBuying001 #$Vitus002) means that #$Vitus002 is the bike that is purchased in #$BikeBuying001, and so on.

Currently (July, 1997), there are about a hundred actor slots used in Cyc (you can view the complete list). Because there are so many, their use is at times bewildering. This note discusses the hierarchy of actor slots and what criteria are used to define an actor slot's meaning.

Some slots are very specific (like #$vehicle); others quite broad (like #$objectMoving). It is useful to have actor slots of varying degrees of specificity, because we need to express genralizations about broad and narrow classes of participants in events. There are many events in which it makes sense to talk about an #$objectMoving, and in some subset of those events we can additionally characterize that participant as a #$vehicle (a device that moves under its own power and transports people or goods). Thus, although it may seem that there are an excessive number of actor slots, each one is motivated by the need to express certain statements in the knowledge base, and they are organized in a hierarchical way, with more specific actor slots inheriting information from more general ones.

## The organization of the #$ActorSlot hierarchy

Actor slots are arranged in a hierarchy. Since they are predicates, not collections, the relation that holds between a more general and a more specific actor slot is #$genlPreds. For example, (#$genlPreds #$vehicle #$transporter) means that the actor slot #$vehicle is a specialization of #$transporter. By arranging actor slots in a hierarchy, we can economically represent knowledge about a large and diverse set of participant roles. Everything we know to be true of #$transporters, for example, will also be true of #$vehicles, and every participant in an event that is deemed a #$vehicle is also a #$transporter. One type of information that #$vehicle inherits from #$transporter is its argument types. The first argument of #$transporter must be an instance of #$TransportationEvent, so the first argument of #$vehicle must be a specialization of #$TransportationEvent. As we can see, the first argument of #$vehicle is an instance of #$TransportationUsingADevice. The second argument of #$transporter must be an instance of #$SolidTangibleThing, and the second argument of #$vehicle must be an instance of #$TransportationDevice-Vehicle, a subset of #$SolidTangibleThing.

The most general actor slot is called #$actors. In other words, for any participant ?X in an event ?E we can assert, at a minimum, (#$actors ?E ?X). Hopefully, we can say something more specific than that about a participant's role in an event, but #$actors does impose some restrictions. Most importantly, the participant and the event must "temporally intersect"; i.e., the participant has to exist while the event is happening.

As we look at more specialized actor slots the restrictions increase. Most commonly, the restrictions involve more specialized argument type constraints on both the kind of event that a slot makes sense for, and the kind of object that can participate in a given fashion. Thus the actor slot #$transporter can be sensibly used only with reference to participants in #$TransportationEvents that are capable of motion.

Other kinds of assertions differentiate actor slots from one another as well. #$preActors is a specialization of #$actors for participants that pre-exist the event. So things that are changed by an event, like a house being painted in a #$Painting event, are #$preActors in that event, while things that are created in the course of an event, like a house being built in a #$BuildingConstructing event, are not #$preActors in that event. There is also the actor slot #$postActors, for participants that exist after an event; a house that gets painted or otherwise modified is one of the #$postActors, but a house that gets dismantled or demolished in an event is not. You will often see pairs of actor slots in the hierarchy like #$preActors and #$postActors, #$deliberateActors and #$nonDeliberateActors, #$inputs and #$outputs, and so on.

If you're interested in seeing actor slots hierarchically arranged by their #$genlPreds relations to one another, you can view this Actor Slot Hierarchy.

## Is the current set of #$ActorSlots final and unchangeable?

The existing set of actor slots should not be regarded as complete or definitive. However, a considerable amount of organized effort has been put into the current inventory and arrangement of actor slots, so modifying the use of old ones or adding new ones without some thought is discouraged.

As a rough generalization, we want to have different actor slots available for each of the different kinds of participants in an event. Sometimes we can get around this without creating new actor slots because there are other ways besides actor slots of telling one participant from another. For example, given the assumption that there is one bride and one groom in a #$Wedding, we can use the actor slot #$eventHonors to refer to either one, and distinguish the bride as a member of #$AdultFemalePerson. So we don't necessarily need actor slots for bride and groom.

New actor slots will be created for a couple of reasons. Particularly at the more specific level, we may find, as more knowledge is entered into the system, that there is a need to distinguish two participants that current actor slots don't serve to distinguish. Also, a new actor slot may be created for the sake of convenience and efficiency in inference, if we find the same combination of literals used in rule after rule to designate a particular participant in a type of event. As one example, the actor slot #$vehicle refers to a #$TransportationDevice-Vehicle which is both the #$providerOfMotiveForce and the #$transporter in a #$TransportationEvent. #$vehicle is a useful actor slot to have because this combination occurs quite frequently in rules. Rather than repeating these formulas every time we wish to refer to the vehicle involved in an event, we have created this actor slot.

### Return to Actor Vocabulary

Search for Constants by Name (In all files, not just this one.)

Go to Top