From bob Wed Feb 11 14:27:53 1987
Received: by lmi-angel.ARPA (4.12/4.7)  id AA17458; Wed, 11 Feb 87 14:27:37 est
Date: Wed, 11 Feb 87 14:27:37 est
From: Bob Chassell <bob>
Message-Id: <8702111927.AA17458@lmi-angel.ARPA>
To: rg
Cc: picon
Subject: Use of the "focus" action in group-rules


Here is the first cut at using the "focus" action in group rules.
Besides the "focus" action, the "activate" and "send" actions are
discussed.  (So far as I can see, the actions "call", "set",
"increment", "advance", "conclude", and "do nothing" do not require
changes.  Their current form is fine.)

I would appreciate your comments on this.  Attempts to use this
syntax on different kinds of problems would be especially helpful.

(Note on terminology: "generic rules" are called "group rules" in this
discussion so as not to confuse this effort with earlier efforts.  In
the long run, I think that "generic rules" is a better term than
"group rules" but that is another matter.)

The first part of this discussion describes knowledge bases in which
the structure is only one level deep.  The second part details a
hierarchical situation.

The examples are formatted with a new line for each clause.  This kind
of formatting makes it much easier for people to write and review
rules.

Part I. Groups on a single level
================================

When the focus action is used with group rules, rules should be
activated only if they are associated with the sensors that cause the
focus and not otherwise.  For example, in a flood control system, a
rule may be designed so as to focus on the rules that check the
operations of sluice gates in rivers that are flooding.  The focus
action should not activate rules that check sluice gates in rivers
that are not flooding.

This requires a rule such as the following:

    if any member of the group of flood-gages 
       > flood-level
    then focus on sluice-gage-rules for that member

When several sensors in the group are active, the phrasing would be
slightly different:

    if at least 5 members of the group of flood-gages 
       > flood-level
    then focus on sluice-gate-rules for those members

In general, the phrase should look something like the following:

    if <portion of group> of the group of <sensor group name> 
       <expression>
    then focus on <rules-for-assoc-unit> for <that member | those members>

The phrase "that member" is used with "any" and "those members" is
used with the other phrases that denote the portion of the group.

For example:

any:        if any member of the group of flood-gages 
	       > flood-level
	    then focus on sluice-gage-rules for that member

each:       if each member of the group of flood-gages 
	       > flood-level
	    then focus on sluice-gate-rules for those members

at least:   if at least 5 members of the group of flood-gages 
	       > flood-level
	    then focus on sluice-gate-rules for those members

exactly:    if  exactly 6  members of the group of flood-gages 
                > flood-level
	    then focus on sluice-gate-rules for those members

no more     if no more than 7 members of the group of flood-gages 
  than:        > flood-level
	    then focus on sluice-gate-rules for those members

The "activate" and "send" actions are discussed in the next section.

Part II. Groups on more than one level
======================================

Groups can be hierarchically related to other groups.  For example,
groups of modems can be attached to a group of computers.

Using the flood control example, flood-gages will be located in
brooks, the brooks will feed into branches and the branches will
feed into rivers.  A rule will look like the following:

    if at least 5 members of the group of flood-gages 
          of at least 3 members of the group of brooks
          of any of the group of branches
	  of any of the group of rivers
	> the flood-level 
    then focus on sluice-gate-rules 
       for that member of the group of branches
    and send "Flooding is occuring at ***; the depth is ***"
       with the  name of that member of the group of branches,
            the value of that member of the group of flood-gages 
       to operator
    and activate evacuation-preparation rules 
       for that member of the group of rivers

Note that in the "send" action, the NAME of the group is specified as
well as the VALUE.  This is different from the current PICON
implementation which only provides values.

The "activate" action is handled in a manner that is similar to the
"focus" action.

In abstract terms, the syntax of the rule is as follows:

    if <portion of group> of the group of <sensor group name> 
	  of <portion of group> of the group of <name of group>
	  of <portion of group> of the group of <name of group>
	  of <portion of group> of the group of <name of group>
	  ........
	<expression>
    then
        focus on <rules-for-assoc-unit>
          for <that member | those members>
	  of the group of <name of group>
        and send "<message incorporating references>" 
	  with the  name of that member of the group of <name of group>,
	       the value of that member of the group of <sensor group name>
	  to <destination>
        and activate <category> rules
          for <that member | those members>
	  of the group of <name of group>

When the rule is written, the parser needs to use "that" if the
antecedent uses "any" and use "those" if the antecedent uses any of
the other phrases for <portion of group>.

In the rules illustrated above <sensor group name> and <name of group>
are different kinds of groups.  However, the user can use the same
kind of "let statement" to define the groups.

For example, sensors can be defined this way:

    let members of the group of <sensor group name> 
	be sensor1, sensor2, sensor3, sensor4, ...

    let members of the group of flood-gages
	be fg1, fg2, fg3, fg4

and other groups in a similar manner:

    let members of the group of <name of group>
	be item1, item2, item3, item4, ...

    let members of the group of branches
	be west-branch, north-branch, south-branch, east-branch

PICON will have a problem determining which sensors belong to which
groups; for example, which sensors belong to the west-branch and which
belong to the north-branch.

There are two ways for PICON to determine to which group the sensors
belong.  If all groups are labeled as part of the schematic diagram,
PICON can use the knowledge embedded in the connections to determine
group membership.  If this is not done, then a "let statement" can be
used, for example:

    let the group of flood-gages of the west-branch
        be fg3, fg4

In general, this would be:

    let the group of the <sensor group name> of the <name of group>
        be  <name of member1>, <name of member2>, <name of member3>, ...

The same construction can be used to specify membership of groups
higher up the hierarchy; for example:

    let the group of the branches of the big-river
        be west-branch, north-branch

Over all, a user will have specify several groups.  In the flood
control example, the user will have to specify which sensors are
members of the group of depth-gages.  In addition, the user will have
to specify which members of the group of depth-gages are located in
which brooks and which brooks feed into which branches and so on.

When a user fails to specify a group properly, PICON should give
helpful error messages, since this is an area in which it is easy to
get confused.

