Page Numbers: Yes First Page: 1
Heading:

April 26, 1979 6:15 PM [IVY]<KRL>document>str-basic-attach-stan

B.4. The Standard KRL-1 Triggers

B.4.a -- Anchor Creation:

One can imagine various sensible uses of a trigger designed to catch the creation of anchors, such as:

1. to maintain a table of units in the system
2. to keep track of how many metaAnchors were being used.

However we have yet yet not specified any standard triggers to catch system events in which anchors are created. The types of restrictions one could put on the acts of anchor creation you wanted to catch might include:

1. labelled anchors

2. unlabelled anchors

3. new slot anchors in some particular unit

4. metaAnchors created for descriptions or other anchors which matched some description.

B.4.b -- Description Attachment:

The primitive act of describing consists of a process attaching a description form to an anchor. For example if in your code (see Chapter 5 for a description of the form and syntax of calls to the KRL-1 interpreter) you say

($ \A Describe with
anchor = SelfSlot(’Fido)
descriptionForm = \a Dog /)

what you want done is for the currently running process to attach the perspective "a Dog" to the self slot anchor in the Fido unit.

The most general way, therefore, to specify a Description Attchment trigger is to:

1. describe the anchor to which the description is attached,
2. describe the process doing the attaching, and
3. describe the description being attached, which in turn involves:

a. describing what kind of description it is (a mapping, co-reference, etc.)

b. specifying the ways in which other anchors that the description mentions participate in the description, including:

i. being at the end of a co-reference description
ii. being at the template end of a mapping pair
iii. being at the instance end of a mapping pair

It is important to realize, in using description attachment triggers, that often what looks like a single act of description from the point of view of an actual program may in fact really represent the creation of several anchors, and the attachment of several descriptions. If a description form given to Describe contains embedded anchors (see [KRL-1]<bsmith>semantics.bravo for a definition of that term) then the interpreter must (at least conceptually) create those anchors, recursively describe them in the manner indicated, and then finally attach the top level description to the anchor specified as an argument in the orginial call to Describe. For example, if you execute the code:

($ \a Describe with
anchor = SelfSlot(’JohnDoe)
descriptionForm = \a Person with father = a Carpenter /)

then conceptually what happens is:

1. An unlabelled anchor is created (call it A1).

2. Anchor A1 is described with the description form \a Carpenter.

3. The anchor SelfSlot(’JohnDoe) is described with a description form which resembles "\a Person with father = A1", except that instead of the filler of the filler pair being a coreference descripion referring to A1, it really is A1 itself. That is, A1 is the embedded anchor of this new description, rather than being a labelled anchor mentioned by a coreference description in it.

Of the infinite number of possible description attachment triggers, we provide numerous standard ones, grouped roughly according to the interpretive processes for which they are relevant, as listed below. However remember that all these triggers are defined as being description attachment triggers.

A. Describing:
1. WhenDescribed
2. WhenGrounded
3. WhenIdentified
4. WhenMapped
5. WhenReferredTo
B. Matching:
1. WhenMatched
2. ...
C. Seeking:
1. ...
D. Scheduling:
1. ...

B.4.b.1 -- Standard Triggers Related to Describing:

There are five standard triggers which are relevant to the normal interpretive function of describing. Two of them, in KRL-0 terminology, would have been called traps, in that they deal with descriptions being added to the very anchors where the trigger is catalogued. Two others would have been called triggers, in that they deal with descriptions which get added to other anchors but which establish mappings onto the place where the trigger is catalogued. The final one falls outside the overly restrictive notions of traps and triggers, and deals with co-reference descriptors. They are each explained below, and units which carefully define their semantics can be found in [KRL-1]<bsmith>standardUnits.KRL-1.

B.4.b.1.i -- WhenDescribed

The WhenDescribed trigger is a simple trigger which will fire any time any process adds another description to the place where it is catalogued. (In KRL-0 it would have been called a trap.) More precisely, when attached with a footnote to an anchor (usually the anchor of a slot), the LISP procedure given it as an argument will be run if any new description gets added to that very anchor. For example, if we had the unit:

# Dog
self:↑1 an Animal1: WhenDescribed(’(NoticeDescription \Dog/))

and then executed the interpreter function:

($ \a Describe with
anchor = SelfSlot(’Dog)
descriptionForm = \a Mammal /)

the interpreter would attach the description "a Mammal" to the self slot of Dog, and then cause the user’s LISP function to be called (note that triggers are fired after the system event to which they are responding). However describing some instance of dog, such as a unit called Fido which has the perspective "a Dog" in its self slot, will not cause the WhenDescribed trigger on the Dog unit to fire.

B.4.b.1.ii -- WhenGrounded

The WhenGrounded trigger is similar to WhenDescribed in that it deals with the state of descriptions attached to the anchor where it is catalogued. Informally, its purpose is to catch any event which causes its anchor to be "known" as an individual, rather than just described with respect to prototypes. For example, if you had a unit such as

# John23
self: a Teacher with pupil = a↑1 Person1: WhenGrounded(’(procedure-31))

then the trigger will fire if someone executes

($ \a Describe with
anchor = SelfSlot(’John23)
descriptionForm = \a Teacher with pupil = David34 /)

A WhenGrounded trigger will be set off either if a) the anchor to which it is attached is described as being a primary anchor, or if b) a co-reference descriptor which refers to a primary anchor is added to the anchor. It is very similar in semantics to the WhenIdentified trigger (below), except that it refers to the place it is catalogued, rather than to an anchor which is described with respect to a prototype. Note that since labelled anchors (i.e. slot anchors) are defaulted to be primary, the WhenGrounded trigger doesn’t make much sense in a labelled anchor unless it is explicitly labelled as NotPrimary.

B.4.b.1.iii -- WhenIdentified

The purpose of the WhenIdentified trigger is to catch the situation of an individual being described as an instance of a specific prototype. For example, if you want to run some procedure every time an individual is described as "a Teacher", you would catalogue a WhenIdentified trigger on the Teacher unit.

The concept of "individual", however, is not primitive in KRL-1, and therefore we cannot actually define this trigger in terms of that notion. Instead a WhenIdentified trigger is defined to fire any time an appropriate mapping descriptor (i.e. one that specifies a mapping onto the specified template) is attached to an anchor which is either a) a primary anchor, or b) has attached to it a co-reference descriptor which ties it to a primary anchor. Both the details of what this means and the consequences of it will be described below, after we consider some examples.

If a WhenIdentified trigger is catalogued on the self slot of a prototype unit, it behaves similarly to its namesake in KRL-0. It will fire any time a unit perspective with this prototype is added to an "individual". For example the Teacher example mentioned above would be implemented as follows: If you had in the system the unit

# Teacher
self:↑1 a Person1: WhenIdentified(’(procedure-23))
subject: a Subject

and then you executed:

($ \a Describe with
anchor = SelfSlot(’John13)
descriptionForm = \a Teacher with subject = a UselessSubject /)

the procedure associated with the WhenIdentified trigger would be run after the description form was added to the self slot of the John13 unit (because the self slot of John13 is a primary anchor).

A WhenIdentified trigger can also be placed on a slot other than a self slot, in which case it resembles KRL-0’s WhenFilled trigger. For example, if our Teacher unit instead had the form:

# Teacher
self: a Person
subject:↑1 a Subject1: WhenIdentified(’(procedure-34))

then the Describe shown above would not cause this new trigger to fire, since the subject pair of the mapping is described but not identified as an individual. However if instead the code read:

($ \a Describe with
anchor = SelfSlot(’John13)
descriptionForm = \a Teacher with subject = Botany /)

then the new trigger would be set off, because the anchor which is at the instance end of the mapping pair that maps onto subject has attached to it a co-reference descriptor which refers to a primary anchor.

In the examples given so far, the WhenIdentified trigger on the self slot was fired because an appropriate description was added to a primary anchor, and the WhenIdentified trigger on an other-than-self slot was fired because the appropriate description was added to an anchor that had a co-reference descriptor in it. These two may be the most common uses of this trigger. However the other two possibilities will also cause the trigger to fire. For example, suppose the Teacher unit has the following structure:

# Teacher
self:↑1 a Person1: WhenIdentified(’(procedure-A))
subject:↑2 a Subject2: WhenIdentified(’(procedure-B))

and there existed in the system some unit Subject23. Then if you executed the code

($ \a Describe with
anchor = SelfSlot(’Subject23)
descriptionForm = \the subject from a Teacher /)

then procedure-B would be run, since the appropriate anchor is a labelled anchor. Or, if you executed

($ \a Describe with
anchor = SelfSlot(’Subject23)
descriptionForm = \the subject from a Teacher thatIs Joe /)

then both procedure-A and procedure-B would be run, since for procedure-A, the appropriate anchor is primary, and for procedure-B, the appropriate anchor (the embedded one) is described with a co-reference descriptor.

Let us return to considering the concept of "individual". We said that since it is not primitive in KRL-1, the WhenIdentified trigger cannot be actually defined in terms of such a notion. In fact, whether something is an individual is determined from how it is used, rather than from its structural form, and it is therefore obviously impossible to catch just those events in which some entity, which in the future will be used as an individual, gets described in a certain way.

The trigger is instead defined in terms of labelled anchors and co-reference descriptions, a convention that is based on the following assumptions about KRL-1 programming style:

1. If you use a co-reference descriptor on an anchor tying it to another anchor, you are treating the entity associated with that anchor as an individual. For example, in the description "a Teacher with subject = Economics", there is an embedded anchor described with the co-reference descriptor "Economics", and the assumption is that you are treating Economics as an identified individual subject. This assumption is parallelled in the fact that co-reference descriptors take an "individual" rather than a "prototype" meaning of the descriptions in the unit to which they point (see Brian’s thesis for more about this).

2. If, during the operation of the interpreter, you define a labelled anchor with a perspective (such as describing Fido as "a Dog"), you probably will be treating the entity associated with that anchor as an individual. This is based on the assumption that you will define your major category hierarchies in the units that get read in, not in units that you create and describe on the fly in your program. This is a weaker assumption than the previous one, and may be violated in large systems (for example if a unit for a new class of dogs, called Beagle, was created by the program, and described as "a Dog", a WhenIdentified trigger on the Dog unit might be inappropriately fired). If such situations arise, the programs will have to do extra reasoning in the specified procedure to see if the assumption about individuality is warranted. The interpreter function Seek allows an arbitrarily more sophisticated notion of identification, and could be used in such a case.

B.4.b.1.iv -- WhenMapped

The WhenMapped trigger is very much like WhenIdentified, except that it makes no attempt to restrict the "individuality" of the anchor to which the mapping description gets added. If catalogued under some slot in a prototype unit, it will be fired any time a description when specifies a mapping onto that slot gets added to anything. It will catch every system event that would be caught by a corresponding WhenIdentified, as well as those cases when the anchor to which the description is being added is neither primary nor described as being co-referent with a primary anchor. For example, it would have caught the case discussed above where the subject of a Teacher was described as "A UselessSubject", whereas the WhenIdentified trigger did not.

B.4.b.1.v -- WhenReferredTo

The WhenMapped trigger described in the last section can be thought of as catching any occurrence of a mapping descriptor which mentioned the anchor where the trigger was catalogued. The final standard "describing" trigger is the corresponding analogue for co-reference descriptors, and is called WhenReferredTo.

A WhenReferredTo trigger gets fired any time a co-reference descriptor being added to another anchor establishes a coreference to this anchor. For example, if you attach such a trigger to some unit called Column19, then any time the co-reference description Column19 gets attached to an anchor, this trigger will be fired. For example, suppose that Column19 looks like

# Column19
self:↑1 a Column1: WhenReferredTo(’(procedure-C))

and furthermore some unit Column18 exists in the system. Then procedure-C will be run if the following code is executed:

($ \a Describe with
anchor = SelfSlot(’Column18)
descriptionForm = \the rightNeighbour from
a NeighborRelationship with
leftNeighbour = Column19 /)

B.4.b.2. -- Standard Triggers Related to Seeking:

(This section can be written only after we design the rest of the interpreter!)

B.4.b.3. -- Standard Triggers Related to Matching:

(This section can be written only after we design the rest of the interpreter!)

B.4.b.4. -- Standard Triggers Related to Scheduling:

(This section can be written only after we design the rest of the interpreter!)

Notes: (OUT OF DATE -- BUT NEED REVIEWING:)

At level 1:

-- only 2 things get done:

1. mappings are established

2. co-references are established

-- there are only 3 ways that an entity can participate:

1. it can be part of the establishment of a co-reference

2. it can be the instance entity of a mapping pair

3. it can be the template entity of a mapping pair.

-- since the issues of where beliefs are attached etc. is only meaningful at level 2, one cannot have any finer resolution and talk about beliefs being added, or mappings attached, or anything.

At level 2:

-- these things get done:

1. Descriptions get added to anchors

2. MetaDescriptions get added to any kind of structure

3. Descriptions get matched

4. Descriptions are used as search patterns.

-- whole question of referring vs. descriptive, which occurs in matching. How do these relate?

-- question of establishing identity. How does it fit in the description of the interpreter?

-- descriptions can participate in the following ways:

-- anchors can participate in the following ways:

1. they can have descriptions added to (or removed from) them

2. they can have metaDescriptions added to (or removed from) them

3. descriptions which mention (refer to) them can be:

i. added to some other anchor

ii. used in matching

iii. used in seeking

-- note that anchors can be identified in two ways:

1. by attaching a mateDescription directly, if it is labelled

2. by attaching a metaDescription to the description in which it is embedded, which is always the case if it isn’t labelled.

From the point of view of the interpreter: (what level is this at?)

-- descriptions get activated.