[Indigo]<KRL>document>str-basic-inherit!1

Page Numbers: Yes First Page: 1
Heading:

April 26, 1979 6:23 PM [IVY]<KRL>document>str-basic-inherit

Inheritance and further specification

Further Specification

I have used the quoted unit name as an argument for the functional. Slot names must all be explicitly present in the Unit in order to be inherited. If they have contents, the contents are added, otherwise they can appear contentless, separated by semicolons if on the same line, as in:

# Event
startTime: A Time
endTime: A Time

# Act↑11: WhichIs FurtherSpecified \Event
startTime: ; endTime:
self: An Event
actor: An Animate
object: A Physobj

# Throw↑11: WhichIs FurtherSpecified \Act
startTime: ; endTime: ; object:
self: An Act
actor: A Person
destination: A Place

The Inheritance of Simple Descriptions

Mapping context and coreference context

Inheritance and the types of description

CoReference descriptions

Mapping descriptions

Reflexives

"Or" and "Not"

"Using"

Collections

The inheritance of metaDescriptions

The null description

B. Abstraction Hierarchies

The directionality of mapping descriptors

Examples and the use of "e.g."

Category Hierarchies

The use of "Or" and the use of "e.g."

Defaults and the "Perhaps" functional

C. The Inheritance and Use of Names

Further Specification

Clusters

Level 3 communication between processes

D. Viewpoints

Identification of viewpoint

Viewpoints as descriptions of descriptions

Viewpoint filters

One of the fuzziest notions in the KRL-0 implementation was the mechanism for further specification. The inuition behind it was that there should be a way of linking units in a hiererachy more closely than just by allowing inferences through their self description. Thus, for example in writing units for Go and Drive, without a further specification mechanism, the connections would be specified:

However, this seems a very indirect way of specifying something which is naturally thought of as further specifying a concept. We might rather say something like "Drive is a further specification of Go, which adds a new slot called vehicle and specifies that the goer must be a Person." In a possible notation (not real KRL-1) this might look like:

# Drive↑1 1: FurtherSpecifiedVersion1(Go)
goer: A Person
vehicle: A MotorizedVehicle

In this, it is assumed that all slots are inherited, and will be listed explicitly only if more description is to be given. Additional slots can be added as well. This form corresponds more or less to what was done in KRL-0, but its interpretation is far from simple. There are several different dimensions of inheritance which are at work in this case, in addition to the normal kind of description inheritance illustrated by the first pair of Go and Drive units:

* What needs to appear in the further specified unit definition?

do names need to appear explicitly

* How is procedural attachment inherited

* How is the reasoning different

* Interactions with compiling

* Reduction of redundancy in storage

Slot Inheritance: The first issue is that of slots and slot names. A simple interpretation of the further specified form of the Drive unit is that it actually has a set of slots with names matching those of slots in the Go unit, and slot descriptions containing the contents of those in Go plus whatever is added in Drive (in this case, the additional description A Person for the goer.) The further specification mechanism can be thought of as a kind of "macro expansion" in which the system behaves as though all of the contents of the higher unit wer copied into its further specification. The inheritance of slots abbreviates the form of the unit, while making it possible to mix inherited and additionally specified slots in a perspective, such as:

A Drive with vehicle = A Ford
destination = A Farm

As a first position, we might say that the only thing wrong with the forms given above is that they are awkward to type. The filler pairs such as origin = My origin could be all implicitly included by some kind of "macro expansion". From this viewpoint, we might have the unit for Walk:

# Drive↑1 1: FurtherSpecifiedVersion1(Go)
goer: A Person
vehicle: A MotorizedVehicle

In this, it is assumed that all slots are inherited, and will be listed explicitly only if more description is to be given.

In KRL-1, the separation of semantic meaning from syntactic form gives us much more flexibility in building special mechanisms for inheritance. For example, it is possible to say that a single perspective form has a meaning which is not a single mapping, but a set of mappings, whose prototypes lie along a further specification hierarchy, each of which has pairs corresponding to some of the filler pairs in the form. The different components of the further specification concept can be used independently, and even combined in new ways by the user. The basic facilities provided by the system are:

Note that we have not included the kind of definition time type-in abbreviation which allows slots to be inherited by a unit without being mentioned explicitly in its syntactic form. This is in line with a general "well-structuring" philosophy of minimizing the number of invisible but semantically significant elements in a structure. The Drive example above would be expressed:

It is also possible to further specify a slot with a new name:

# Drive
self:↑1 origin:↑1 destination:↑1
driver:↑2 A Person
vehicle: A MotorizedVehicle
1: FurtherSpecified(Go)
2: FurtherSpecifiedSlot(Go, ’goer)

A single unit can include slots which are further specifications of slots in any number of other units. Note that there are no poblems of name conflict, since each slot in the inheriting unit explicitly specifies which of its slots correspond to which slots in each ancestor. Name conflicts are avoided in KRL-1 because we have given up the implicit inheritance of all the slots in an ancestor. If the slot origin (or another slot linked to it by FurtherSpecifiedSlot) did not appear explicitly in the unit for Drive, then even though the self of Drive indicates that it is a further specified Go, the form A Drive with origin = Denver would be ill-formed, to exactly the same degree as A Drive with biter = Fido.

The following points summarize the action of the interpreter in dealing with FurtherSpecified. As with many parts of this document, they express what is happening in a general way which captures all of the semantics. In fact, in most uses of further specification hierarchies, the interpreter or compiled code does not need to actually produce all of the redundant data structures and actions implied in this description.

* Whenever a mapping

interactions with compiling

clusters, etc.

Within a unit, all descriptions are local. Some of them may specify the existence of mappings which involve other contexts. Depending on the type of the mapping, the further descriptions available by interpreting the mapping will be classifed as either immediate or remote. In general, immediate descriptions can be followed without worse than a linear search, while remote ones involve exponential search or arbitrary computations.

Getting the values back

Residues

Process descriptions known to the system

Structure of the code

Specification of Further Specified

At the message level, one unit (Son) is designated as a further specification of another (Father) by the following notation:

# Son↑11: FurtherSpecified(Father)

At cataloging time, this footnote will cause a direct link from the self slot of the Father unit to the Son unit to be cataloged and placed in the tree called FurtherSpecified (see the Tree Mechanism document for further information about trees).

The way the desired effect is obtained from this can be loosely characterized as follows, couched in pre All things are MATCH terms:

Describe is smart, and given a perspective distributes the attached filler pairs to the highest possible prototype in the FurtherSpecified tree. Thus if we have:

# Father
self:
s1:
s2: A Bar

# Son↑11: FurtherSpecified(Father)
s2: A Mumble
s3:

then a call to Describe with new description A Son with [s1 = d1] [s2 = d2] [s3 = d3] would add two mappings, one the equivalent of A Father with [s1 = d1] [s2 = d2] and the other the equivalent of A Son with [s3 = d3].

Mappings with prototypes for all the entries in the further specified chain are always added, even if no filler pair is present which necessitates this.

All relevant triggers will be activated, regardless of position in the hierarchy. Thus in the above example, WhenFilled triggers attached to either s2 in Son or s2 in Father would be activated.

Conflict resolution and order of firing yet to be determined, dependent on general issues of process activation. Activation environment yet to be determined, dependent on same, and on particular trigger involved.

The access compiler converts calls to Seek to look for a filler pair attached to the highest prototype in the tree, and if that fails then it invokes servants from the bottom up. Thus a Seek with main argument the s2 from G00354 viewedAs a Son would look first for the filler of a pair with name s2 in a mapping with prototype Father, then check for servants on the s2 slot of Son, then on the s2 slot of Father.

How smart inferencing mechanisms will be about finding and distinguishing the two separate descriptions of the slot s2 in the above example is not yet determined, as in the case of matching The s2 from g0024 viewedAs a Son/Father with A Bar/A Mumble.