When creating widgets.

Widgets should not be specific.  Our goal is for the widget hierarchy
to be shallow and relatively static.  Methods are provided for
accessing basic properties of all objects recognized by the system
(e.g. name, start and end times, id, etc...).  Each widget then has
several delegates which handle the bulk of the processing.  They are:

1) Semantic representation
   In the meche domain this would be where information about the
   component is stored.  e.g. mass, spring constants, behavioral
   descriptions of the parts, etc...
2) Interpretation graph node that corresponds to this object
   This is a pointer to a node that represents the sub components that
   this widget was recognized from and the component(s?) that this
   widget is a part of.
3) Geometric information for the vsible widgets
   This is a representation of the spatial properties of the widget
   including bounding boxes, location, size, and object specific
   properties like the endpoints of a spring.


----------------------------------------------------------------------
November 21, 2001

Blackboard structure:

The main components are:
Blackboard
Blackboard Monitor
Scheduler
SchedulingQueue
KS's: Condition and Action parts

The blackboard holds all of the levels and the hypotheses on each
level.

On each iteration of the cycle the scheduler chooses a widget, KS
action or condition from the scheduling queue.  (How?)

  + For widgets, it finds KS's that may apply to that widget and then
    schedule that KS on the queue.

  + For actions, it creates a set of bindings for the hypotheses on
    the BB that the action can be applied to and adds the combined
    bindings and KS to the scheduling queue.

  + For actions, it executes the KS action with the bindings that were
    found by the condition of the KS.  This is where the modifications
    to the BB occur.

When the blackboard is modified the change is recorded in the monitor.
The monitor then adds the widget to the scheduling queue.

New user input (i.e. a new stroke or utterance) can be buffered in an
input queue and inserted into the BB before running the scheduler at
each stage.  The initial strategy will be to add all of the new
inputs (if there are more than one) to the BB before starting the
schedular.  This provides the scheduler with the maximum information
before having to make a decision.

Who knows which KS's exist and what their triggers are?
How does the scheduler pick what to execute?  Start with sequential.

What things in the DB trigger KS's?  What is a new addition?  If there
are 2 things to choose from after the first runs the previous state
will have chnaged but we may still want to run the second KS.
SUGGESTION: also add BB objects to the scheduling queue so that we can
find appropriate KS to run on them.