[Indigo]<KRL>document>match-seek-brian!1

Page Numbers: Yes First Page: 1
Heading:

April 25, 1979 4:47 PM[IVY]<KRL>document>match-seek-brian

C. -- The Reasoning Process

C.1 -- The Basic Processes Revisited

C.1.a. -- Five Basic Functions

The various functions that the KRL-1 interpreter is designed to handle (i.e. the types of description which RUN will recognize) are organized around the following five basic processes:

1. Creation (creating new anchors such as units and slots)
2. Describing (attaching a description form to an anchor)
3. Seeking (searching for an entity matching a certain description)
4. Comparing (seeing how different descriptions relate)
5. Scheduling (putting things on and off the process agendas)

C.1.e -- The Basic Processes

With the concepts given so far, we are now in a position to informally define what is going on in the basic description manipulation processes. As in any computational system, there are three data structure primitives -- adding new data (CONS), finding existing data (CAR/CDR), and comparing structures (EQ). In describing KRL-1 we will often refer at an abstract level these three processes, rather than using the names of the specific functions which implement them. This is primarily because for each basic process, there is a collection of different function names, corresponding to different paramaterizations of what is to be done.

The informal specification does not make clear just how the input parameters are specified, or just how the result is returned. In fact, for each basic process there are a number of variants on just what is given initially and what kind of object you want back. The simplest analogy for this is with the CLISP iterative statetments, in which the arguments given can be selected from a variety of combinations, and the nature of the output depends, for example, on whether it contains JOIN, EVERY, or simply DO. Section ??? contains a detailed description of the alternatives.

Finding

The process of finding involves two primary inputs: an initial description of the object being sought, and a result description describing what we are after. These descriptions are in two different domains. The initial description is in the domain being modelled -- of people, dogs, biting, etc. The result description is in the domain of descriptions -- of the forms manipulated by a KRL system. Thus a typical example would be:

initial description - The bitten from a Bite with biter = Fido

result description - A PrimaryDescription

In this case, we are trying to answer the question "Who did Fido bite?" The question provides the initial description, and the result description asserts that we will not be happy with the answer unless it is a primary description (in our case, the one in the self slot for the unit for Sally). The great majority of cases in which we are doing finding involve a result description which is either A PrimaryDescription, A PointerCoreference, or one of the forms described below for dealing with sets and sequences of these. A PointerCoreference is essentially what our old Seek looked for -- a description of the object being sought as coreferent to an existing unit or primitive LISP entity.

The initial description contains all of the information necessary to begin the search. In many cases it will contain a MemberOf descriptor, if we are searching for the object in a known sequence or set. Thus, to find a woman in a list of people which was represented by the unit JuryList, we would have the initial description.

A Woman; WhichIs MemberOf JuryList

To search for a woman who is both a lawyer and married to someone on the jury list, we would have initial description:

A Woman; A Lawyer; WhichIs SpouseOf MemberOf(JuryList)

If we want to find someone on the jury list who once was bitten by a dog, we could ask for:

MemberOf(JuryList); The bitten from a Bite with biter = A Dog

Note that if we simply wanted to find anyone who had ever been bitten by a dog, we could have initial description:

The bitten from a Bite with biter = A Dog

However except in a case of shared context (see below), the reasoning process might have a lot of trouble finding the right units to activate in its search.

A definition of finding

The general process of finding can be described as follows:

1) Add the meaning of the entire initial description to an initially empty active context

2) Repeat the following steps until the active context includes a description which is: a) coreferent with the initial description (describes the same thing); and b) fits the result description (e.g. is primary, or a pointer).

2a) Choose either an inference which can be made from the existing active descriptions, or a new description in the long term knowledge base to be activated.

2b) Add the result to the active context

Note: the process can also be terminated by running out of resources, or by limitations set up on the kinds of inference and activation steps it is allowed to do. Section ??? describes the form and role of the process description which specifies these limits.

Of course, step 2a had better be guided by something other than blind search, or we will never find anything. In the examples above, there was always a specific instance unit (like Fido, or JuryList) which should be activated. In the case of JuryList we can make a further set of choices based on the fact that it is a sequence and that the initial description refers to its members. This leads to activating the units for each of its members in turn.

There is an important difference between the process as described here, and the process of Seeking in KRL-0. In KRL-0, the signal table was used to fully specify what could be done at any point. In KRL-1 we have separated the specification of allowable inferences from the specification of heuristics as to which ones to try when. It is still necessary to provide guidance, in order for the sytem to make the choice of iterating down the list, rather than going off and activating the prototype for Woman. But the guidance is within a precisely defined framework of activation and inference, rather than being an arbitrary set of manipulations based on specific combinations of descriptors.

The interpreter has built into it a number of generally useful heuristics (e.g. the one which would lead it to activate in turn all the members of a set or sequence when the initial decription includes a MemberOf description.) To these, the user can add any others, using event networks (the replacement for signal tables in KRL-1).

Comparing

Reasoning in KRL-0 was centered around a "matcher" which used description comparison as a framework for organizing reasoning processes. This is equally true in KRL-1. The abstract process of matching involves two descriptions, called the pattern and datum, and two parameters, one indicating whether the pattern is to be treated as referring to an already known entity or not, and the other indicating whether we are looking for a known match in which there is pre-existing information which can verify it, or a possible match in which there is no information indicating that the datum could not match the pattern. The simplest form of output is an indication of whether the match was successful.

There are many elaborations on just how the match is set up, how it will run, and what kinds of results it will return. We have tried to deal with many of the issues of resource limitation, partial results, and binding which were discussed in the Overview but not implemented in any KRL-0 programs. Section ?? goes into these in detail.

Simple examples of comparing

If we want to ask whether Fido ever bit Sally, we could do a comparison with:

pattern - The biter from a Bite with bitten = Sally

datum - Fido

The choices of the other parameters are determined by the presuppositions intended and the answer desired. If a known match is specified, then the comparison will succeed only if information identifying Fido as a biter of Sally can be found. This would be the case for most of the variations on the data base given above. If a possible match is specified, then all that is necessary is that no contradictory information can be found. Given a knowledge base corresponding to only the initial units for Dot, Bite, etc., the match would be successful. On the other hand, if we were asked whether Sally could possibly match the same pattern, the answer would be negative, since a biter must be an instance of Animal, and Sally is a Person.

This isn’t quite the full story, since the knowledge base as given does not specify that Animal and Person are mutually exclusive categories. In order for the match to work as just described, that information would have to be explicitly included.

The specification of the pattern as referring or descriptive provides information to the interpreter about what directions to search. If it is marked as referring, the system uses heuristics based on the assumption that there is already an existing record of an entity which fits the description (in this case, someone who bit Sally), and that the major form of reasoning is to find the primary description (using the process described above for finding) of this entity, and check whether it is coreferential with the datum. If the pattern is marked as descriptive, then the reasoning is based on going through the pattern’s meaning piece by piece (each belief) and seeing that it applies to the datum.

In the simple example used here, it would be somewhat problematical to specify that the pattern was referring, since the question would then carry the presupposition that one and only one thing had bitten Sally. In a specific context (see below) or a carefully controlled knowledge base, this might be reasonable. In fact, for many patterns, this is not a problem since they are based on units (like Person) for which only a single mapping can exist for a given instance. It is reasonable (in fact natural) to view the pattern as referring in the comparison:

pattern (referring) - The gender from Sally viewedAs a Person

datum - Female

As with the other processes, there are often many different forms which are based on the same semantic inferences. The difference lies in the heuristics which will be applied in deciding what should be tried. The match just above is semantically equivalent to:

pattern (descriptive) - A Person with gender = Female

datum - Sally

But the heuristics are different. The first example would lead to placing a high priority on activing the unit for Female to get a look at its self description, while the second would place a higher priority on activating the unit for Sally. The two would eventually come to the same answer given sufficient resources and freedom to do all kinds of inferences and activations, but might well differ in cases where resources are limited and types of reasoning are restricted. In general, they would not provide conflicting answers, but one would provide an answer while the other indicated "Unknown"

A definition of the comparision processes

In describing the different comparison processes, we will separate out the cases for referring and descriptive paterns.

Referring:

1) Create a new active context, and use it for all of the following operations.

2) Find a primary description, using the pattern as initial description (using the finding process described above)

3) Find a primary description, using the datum as initial description (using the finding process described above)

4) If the same primary description was found for both, answer Yes

If two different primary descriptions were found, answer No

If primary descriptions could not be found for both, then

If a known match is desired, answer Unknown

If a possible match is desired, use the procedure for a descriptive pattern

Descriptive:

1) Create a new active context, and use it for all of the following operations.

2) Try to find a primary description, using the datum as initial description

3) Create an entity for the referent of the pattern, and add to the active context all of the description of it given by the pattern, with all of the beliefs and entities specially labelled as hypothetical. Include a hypothetical belief that this entity is coreferent with the datum

This special labelling is necessary because we do not want reasoning to procede on the supposition that an entity described by the pattern actually exists in the concept set

4) Search though the space of possible derived concept sets by doing inferences and activations. The hypotherical beliefs can be used in these inferences, but any belief derived from a set of beliefs including a hypothetical is itself marked as hypothetical.

5) If any of the following happens the process ends:

The concept set includes a set of beliefs, not derived from hypothetical beliefs, which include a belief for each one in the initial set from the pattern, with the datum entity substituted for the pattern entity, in which case the result is Yes

A contradictory set of beliefs is discovered, including both the hypothetical and non-hypothetical beliefs, in which case the answer is No

Resources run out, or no new inferences and activations can be made given the limitations, in which case:

If a known match is specified, the answer is Unknown

If a possible match is specified, the answer is Yes

There are differences between the processes for known and possible match not only in choosing the final answer, but also in the set of heuristics used in deciding what inferences and activations to try. In the case of possible match, the emphasis is on those things likely to produce contradictions, such as establishing that two coreferent entities either have different primary descriptions, or are instances in mappings from prototypes of conflicting categories. In the case of known match, the process is directed towards trying to infer non-hypothetical versions of the specific beliefs specified in the pattern. This will often involve looking at the units associated with prototype entities for mappings appearing in the pattern, looking for cross-linkages between slots (i.e. the description in one slot relates it to the contents of others) and for explicit procedural attachment telling how to identify the entities mapped from specific slots (see section?? below).

Adding Description

the "primitive" function Describe in KRL-0 really did a variety of jobs:

1) A quick consistency check was done to see if the new description was obviously incompatible with something already in the structure to which it was being added. In KRL-0 this consisted only of looking for multiple units appearing in a single description. A number of more general checks, both for coreference and category, are possible. This was used for a style of programming in which new things are asserted which are really hypothetical, and a resulting inconsistency indicates that the hypothesis is not valid.

2) Procedures attached in two different places were activated:

a) Traps associated with the actual description structures being modified

b) Triggers associated with the prototype units for mappings or filler pairs being added.

3) Permanent modifications were made to the knowledge base, with the new description (in more or less its exact syntactic form) merged into existing descriptions.

In the framework presented above for KRL-1, these jobs belong in two different conceptual arenas. The consistency checking and triggering are essentially "semantic" in that they deal primarily with the set of entities and mappings implied by the meaning of the description, rather than with the syntactic forms or data structures in which it is couched. The permanent modification and trapping are more closely tied to the actual description forms, and the data structure operations which deal with those forms.

The interaction between these two kinds of processes was ill-specified in KRL-0. It was not clear what would happen if a Describe triggered an action, which in turn led to a contradiction at some later point. It was also not clear how triggering should interact with further specification. Since the code for triggering dealt with explicit descriptor forms and their associated prototype units, it did not extend easily to handle cases where a trigger associated with a unit high up in in the further-specification hierarchy needed to be activated when a perspective (or new slot filler) based on one of it descendants in the hierarchy was added to a description. This was one reason why the whole further specification mechanism was under-defined and difficult to use reasonably. In KRL-1, the meanings and forms are dealt with separately, making it possible to treat the operations in a more consistent way.

Consistency checking is a specialized case of description comparision, as described above. It is a form of "possible" match, in which only some of the possible inferences are to be tried. We have already discussed the basic notions involved, and will describe the details below when giving the syntax for the various functions which add descriptions. The triggering of demons, both triggers and traps, is also discussed below in a general section on servants and demons. The part of the process which is specific to this class of operations is the modification of description structures to incorporate new descriptions.

The operation of adding a description involves two central arguments (with parameters and process description as usual), specifying a new description and a structural position where the new description is to be added. The structural position indicates a data structure already in the knowledge base, which can be interpreted as a description whose referent is the same as the intended referent of the new description. The argument is a description of a data structure, not a description of a thing in the world domain of the new desctiption. This is similar to the status of the result description in the finding process described above. It is a description of the description which we want to find. In this case, the structural psosition is q description of the place (in the permanent structures) where we want to put the new information. We have a great deal of generality in specifying the structural position, but there are three standard cases which should cover almost all of the descriptions normally added (for reasons, see below). These are handled by three built-in functionals associated with the units for basic system objects such as units, slots, and descriptions. They are:

SelfOf(unitName)
SlotOf(unitName, slotName)
PrimaryFor(initialDescription)

The SelfOf form indicates that the new description is to be added to the description in the self slot of the indicated unit. The SlotOf form indicates that the description to be modified is the top-level description in the indicated slot of the indicated unit. Note that SelfOf(x) is equivalent to SlotOf(x, self) but is abbreviated because it is the more common form. Finally, PrimaryFor calls for a finding process which begins with the given intial description, finds a primary description which represents the same thing (as described above), then adds the new description structure to that primary description.

Simple examples of adding description

Let us begin with the initial data base (repeated here from above):

# Animal|# Bite
|biter: An Animal
# Person|bitten: A Person

# Woman|# Sally
self: A Person|self: A Person

# Dog|# Fido
self: An Animal|self: A Dog

Assume that we want to add the fact that Fido bit Sally to our memory structure for Fido. We would do an addition with:

structural position - SelfOf(Fido)
new description - The biter from a Bite with bitten = Sally

If we now knew that Fido had bitten a woman, we would further do an addition:

structural position - SelfOf(Fido)
new description - The biter from a Bite with bitten = A Woman

Note that this does not commit us as to whether a biter can take part in more than one Bite (as pointed out above, many relations represented by mappings have a one-one nature not exibited by Biting). The procedure for adding new information needs to look at the unit for Bite to see whether it is declared as unique for a given biter. If not, the two new descriptions would be separate:

# Fido
self: The biter from a Bite with bitten = Sally
The biter from a Bite with bitten = A Woman

If it were unique, the resulting unit would be:

# Fido
self: The biter from a Bite with bitten = [Sally; A Woman]

In neither case would the unit for Sally be changed. Of course, we could also do additions in which the structural position was SelfOf(Sally). There is a common case, in which we would want our knowledge that Fido bit a woman to be applied to the description of whoever it was he bit. In this case, we would do an addition with:

structural position - PrimaryFor(The bitten from a Bite with biter = Fido)
new description - A Woman

The process would first involve finding a primary description, using the initial description The bitten from a Bite with biter = Fido. As described in the section above on finding, this would use the information in the Fido unit and eventually return a primary description -- in this case, the self descripton from the unit for Sally (since the default is for top level slot descriptions to be primary). The modification would then be done to that unit, leaving the Fido unit unchanged, and resulting in:

# Sally
self: A Person; A Woman

If there were no primary description findable (for example if the previous additions had only stated that Fido bit some person) there would be an error (mistaken presupposition?) signalled by the functions for adding descriptions.

Finally, we could use a more elaborate form of the structural position descriptor to specify changes directly to embedded descriptors. Assume we already had:

# Fido
self: The biter from a Bite with bitten = Sally

Then it would be possible to achieve the same effect as the case above in which the two fillers were merged by doing an addition with:

structural position -
A FillerPair with slotName = ’bitten
MemberOf
(FillerPairsOf
(A Perspective with prototype = Bite
MemberOf(DescriptorsOf
(The selfDescription from
\Fido viewedAs a Unit))))
new description - A Woman

The interpreter would do a finding process, in the domain of descriptors and descriptions, eventually finding the desired filler pair. It would then add the new description, resulting in:

# Fido
self: The biter from a Bite with bitten = [Sally; A Woman]

Since KRL is completely self-describable, the user has the power to carry out this kind of direct intervention in the data structures to any degree necessary. It should be clear, however, that this is a dangerous venture, since there are a number of reasons (see discussions on footnotes, embedded implicit and descriptors, worlds and contingencies, etc.) why the data structures may not have the detailed form which would be expected in the simple case, even though they express a semantically equivalent description. In such cases, the addition done in the standard way (giving the structural position with SelfOf) will work correctly, while the more direct specification of the data structures will fail.

C.2 -- Details of The Five Main Interpreter Functions

C.2.a. -- Create

C.2.b. -- Describe

C.2.b.1 -- Parameters

The act of describing consists of a process attaching a description to an anchor. The corresponding argument to RUN is therefore a description of an instance of the standard unit Describe, which has roughly the following structure (all standard units shown in this document are given for pedagogical purposes, and therefore usually only a simplistic version is presented. The complete and correct version is on [KRL-1]<bsmith>standarUnits.krl1):

# Describe
self: an InterpreterProcedure
anchor: an Anchor
newDescriptionForm: a DescriptionForm
process: a Process

The meaning of the slots, which would be filled in in a specific call to RUN, is owing:

1. anchor: This description describes the anchor to which the description will be attached. There are three standard descriptions known about by the interpreter:

selfAnchor(unit) -- the anchor which is in the self slot of the unit unit.

slotAnchor(unit, slotname) -- the anchor in the slot named slotname of the unit unit.

PrimaryAnchorFor(descriptionOfAThing) -- the primary anchor for the thing represented by the entity which is the referent of the argument description.

If there is any other description: a) it should describe an anchor, and b) the user will have to provide sufficient support to enable the interpreter to find it.

2. newDescriptionForm:This should be a description form to be attached to the anchor. If it is a complex description of a description form, the user will have to provide sufficient support to enable to interpreter to find the description form referred to. (Note that since this new description form is as yet unattached to an anchor, it does not yet have a level 2 meaning -- i.e. it is not yet a real description; a (level 2) description will be established only when the attaching is done.)

3. processDescription:A description of the things which the Describe process should do in adding the description. Note that the issues dealt with by each of the following groups are orthogonal -- and you can therefore specify a description from each of the groups. The default that is taken, if no argument is given, is listed separately for each issue.

i. Consistency-checking: There is a general description of consistency checking in the overall manual. The following two descriptions are standard and orthogonal -- either or both may be specified. The default is to do neither.

a. A CategoryCheck: A possible match is done as specified in the section on category checks in section V.

b. A MultipleIdentityCheck: ???

ii. Triggering: The default is to check for triggers on the anchor to which the description is being added, and also on all anchors mentioned by the new description form. However if you specify the process description "A NoTrigger", none of those anchors will be checked. The main use of this is as a declaration of intent so that the access compiler doesn’t need to waste time looking. However this declaration over-rides the intents of any triggers which have been placed; even if there are triggers which have asked to be woken up in this case, they will be ignored.

iii. (Are there others?)

C.2.b.2 -- Standard Functionals:

To avoid innordinate typing, the following standard functionals have been defined as abbreviations for common versions of Describe descriptions:

1. selfDescribe(unitName, newDescriptionForm) as an abbreviation for:

a Describe with
anchor = selfAnchor(unitFor(unitName))
newDescriptionForm = newDescriptionForm

2. slotDescribe(unitName, slotName, newDescriptionForm) as an abbreviation for:

a Describe with
anchor = slotAnchor(unitFor(unitName), slotName)
newDescriptionForm = newDescriptionForm

3. (Should there be others to deal with the same arguments as the above two, but with different choices other than the defaults for process descriptions?)

C.2.b.3 -- Examples:

To describe a unit called Fido with the perspective "a Dog with colour = brown", you would write:

Ex 1a:($ \a Describe with
anchor = selfAnchor(unitFor(’Fido))
newDescriptionForm = \a Dog with colour = Brown /)

or equivalently, using the standard abbreviations:

Ex 1b:($ \selfDescribe(’Fido, \a Dog with colour = Brown) /)

As a second example, consider describing something in terms of a LISPValue descriptor. If you wanted to describe some slot named total in a unit called Column as being the sum of two other slots know as top and bottom, you might execute something like:

Ex 2a:($ \a Describe with
anchor = slotAnchor(unitFor(’Column), ’total)
newDescriptinoForm = \LISPValueOf ’(Plus x y) with
x = my top
y = my bottom /)

or equivalently

Ex 2b:($ \slotDescribe(’Column, ’total, \LISPValueOf ’(Plus x y) with
x = my top
y = my bottom /)

Note that no closure is taken for the reflexive descriptors since this quoted description form is not within the context of a unit (How would you quote someone esle’s reflexive descriptor in a unit -- do we have a way?).

The third example illustrates the use of the prefix character "!". Suppose you had some variable x which was bound to som unit, and you wanted to describe that unit as a Person. The following code would do the right thing (although it could not be access compiled because it is not a simple case -- see the next section):

Ex 3:($ \selfDescribe( !x, \a Person) /)

Note that this examples pre-supposes type-coercion from units to unit names (since selfDescribe expects its first argument to be a unit name. However this is standardly done -- see section V.E on data types).

The fourth example illustrates a more complex Describe with embedded interpreter calls. It might be the sort of code executed by a debugging or programming assistant type of program:

Ex 4:($ \a Describe with
anchor = !($ \a Seek with
sought = the anchor from a Description
thatIs Description23 /)
newDescriptionForm =
!(ConstructDescription
\a Perspective with
prototype =
the unit from Event23
viewedAs a DescribeOperation /) /)

C.2.b.4 -- Simple Cases:

The following so-called "simple cases" define the varieties of Describe which the access compiler will be able to do directly:

1. The anchorDescription must be an immediate, quoted version of either of the first two possibilities listed -- selfAnchor(...) or slotAnchor(...). Furthermore, the description of the unit must be the standard functional UnitFor(...), and its argument must be a simple quoted LISP atom which is the name of the unit. A slot name, if specified, must also be a quoted LISP atom.

2. The newDescriptionForm must be a quoted description form. (how about the value of a LISP variable?).

3. The processDescription may either be defaulted (i.e. omitted), or any immediate quoted combination of the allowed possibilities.

C.2.c. -- Seek

C.2.c.1 -- Paramters

The normal version of Seek takes four arguments which describe the process, the thing being looked for, how it should know when it has found it, and what it should return. There is also a function called CompositeSeek which takes in addition a fifth argument describing the form of the result to be returned which it finds a set or sequence.

1. initialDescription: A description form which describes an entity which represents the thing being looked for.

2. resultDescription: describes the structure that you want back which represents the same thing as the initialDescription. There are only three possibilities (since that is all there are in the language):

a. An AnchorForm:

b. A Pointer:

c. A DescriptionForm: (There are a host of issues here which I haven’t worked out in the semantics about whether the interpreter can really return a description or only a description form. The issue arises for the arguments to all the interpreter functions. The only clear case seems to be the newDescription argument to Describe which needs to identify a description form. Note that a quoted description is really a description of a description form.)

3. stopDescription: describes when the Seek process can know that it has found the appropriate descriptive structure that was wanted. Possibilities are:

a. whichIs Primary: Stop when you reach a primary anchor for the thing.

b. A LabelledAnchor: Stop when you reach a labelled anchor (an anchor in a slot) which represents the thing.

c. IdentifiedAs(identifyingDescription):

4. processDescription: A description of the process to be used by Seek in finding the described thing. Two process descriptions are standard:

a. whichIs AccessOnly:

b. a TriggerAccess

Any other description must describe a process and be supported by the user.

5. compositeDescription (CompositeSeek only): describes the form of the result to be returned in the case of a seek which finds a set or sequence. Possibilities are (There are still issues about whether it necessariy returns all the items, how it describes whether it knows that it has all the items vs. that it is returning all the items it could find, what it does when it runs out of resources and has some of the members, etc.):

a. ListOf: returns a LISP list of the members

b. SequenceOf: returns a KRL sequence enumeration of the members

c. SetOf: returns a KRL set enumeration of the members

d. GeneratorOf: returns an INTERLISP generator, usable in iterative statements etc, which will return a new member each time it is pulsed.

C.2.c.2 -- Standard Functionals:

C.2.c.3 -- Examples:

C.2.c.4 -- Simple Cases:

The simple cases for Seek are restricted as follows:

1. The initialDescription must be grounded (as defined below). Note that if there is more than one ground in the description, they will all be used if necessary, in the order written, but in the obvious recursive way. If you want a clever control structure you should take control of the Seek yourself.

2. The resultDescription may be any of the allowable possibilities.

3. The stopDescription must be either whichIs Primary or a LabelledAnchor.

4. The processDescription must be either An AccessOnly or A TriggerAccess.

5. The compositeDescription, if present, may be any of the allowable possibilities.

C.2.d. -- Match

C.2.d.1 -- Parameters

Match takes ??? arguments which describe the pattern, the datum, the type of match, the process, and what information Match should return (???):

1. datumDescription: A description to be matched against the pattern description given in the patternDescription argument. If you want the datum description to be used in a referring way to identify a specific individual whom you know about, and then want to see whether all that you know about that individual will match some pattern, then you should use Seek (giving it the description by which you want to refer to this individual, and specifying the appropriate conditions for identification), and then use the result of that Seek as the datumDescription to Match.

2. patternDescription: A description against which the datumDescription is to be matched. This is intuitively the more "general" description, in the sense that a call to Match with a datumDescription of "A Dog" and a patternDescription of "An Animal" could be expected to succeed, since a dog is an animal, whereas it would probably not succeed the other way around, since in general an animal is not a dog.

3. resultDescription

4. processDescription

C.2.d.2. -- Standard Functionals:

C.2.d.3 -- Examples:

C.2.d.4 -- Simple Cases:

The simple cases for Match are restricted as follows:

1. The datumDescription must be of such a form that an anchor can be found with no more effort than type-coercion. This means that it must be an anchor, a co-reference description, or a unit or slot.

2. The patternDescription may be an arbitrary description. However in the simple case Match will use no inheritance (it will follow no mappings) and will not follow any co-reference descriptors to any non-primary anchors. The intuition is that whether or not the match will succeed should be determinable from structurally well-defined descriptions without getting into possible loops or dealing with mapping inheritance. It will use any grounds in the patternDescription, will deal with "simple" cases of Using, and will also deal appropriately with the following standard functionals:

a. MemberOf(a grounded set description)
b. Or( ... )

c.2.e. -- Scheduling: