things that need to be added to make jtre work in annotation notebook.

merge rotations and the causing motion
  + actually can prbably just assert it when rotation is asserted
  + need to be careful of utterances though

rotation utterance rule
  ? how should it work?
  ? just assert the motion and let the rotation rule pick it up?
  ? assert the motion and the rotation?
  ? what if it is anchored?

contradictions
  + rotation utterance but no pin joint...
  + ask what it rotates around with the option to have the user click
    a rotation point...
  + this would be nice!
  
what happens if no rules fire off of an utterance can we say "sorry
didn't understand that..."

merge needs to only apply to one verbal and one gestured item... at
least for now.  and they can be separated by more than one input if
the intervening inputs were the same type.
  e.g. "the block pushes the ball" 
       arrow
       arrow
     => the second arrow can merge w/the balls motion


recognize causality
  + a motion by object followed by motion by a nearby object =>
    causality
  + need to link events by annotation input times if all else fails
  + linkages with subevents
  + if nothing else assert causality by input order
  + one end of pulley moves => other end moves

Make a pretty display to show the causality including subevents

rule: LeadsTo => allows or causes

It is harder to make rules that find the closest widget to
something... how can we handle this?  Will this be a problem at all?

------------------------------
Parameter setting:
------------------------------
Constraint prop for paramaters (IA system from web?)
  + Springs
  + external forces
  + parallel and perpendicular
  + balanced levers
  + balanced pulleys


----------------------------------------------------------------------
THESE ARE DONE!!!
----------------------------------------------------------------------
finish/test JTRE
  make sure we check inness of rule triggers
  do we want in/out/intern rules? N0.

DBClass types Type.java -- just use strings for fact types... maybe
have a Type class for constants to use.

make JTRERule take multiple triggers

Event class -- lets use individual event classes instead of a
	       single monlithic one

Structure/balance between: facts, annotations, widgets, and rules
  facts are more general than annotations.  there may be facts that
  are not "important" enough to be annotations.  Ex?

  The only things that are widgets are arrows, bodies,
  sim-constraints, and utterances

Types for triggers:
  Event
  Body
  Spring
  Damper
  Anchor
  Pivot
  Sentence
  Same-Event

LeadsTo class

Need to make annotations JTREFacts and maybe make them smaller/more
     modular so as to go into a jtre instead of being large data
     structures.

add initial bodies and constraints into the jtre
  + need wrapper facts for bodies and constraints?

Sentence class(es?)
  + need to make a function to only check top level tags...
  + need to collapse tags with the same text

How to handle entities?
  The problem:
    1) will it be a problem that the constituents of a merged event
       are used to produce more facts?
    2) how will entities work?

  Solutions: (well, ideas anyway...)
    + it shouldn't be a problem it will just require careful
        contradiction checks.
    + There can be explicit facts that bind names to objects
    - Entities can be part of merge facts -- but does that cary over
        to other facts without changing which rules should be run?
    - Have explicit "best-choice" facts so we don't use facts that
        lead to other things instead of the other things themselves...
        This also requires some propagation so that the merged entity
        can provide support for the old facts
    + I'm being silly and this isn't an issue, just treat things as
        assertions like they are supposed to be.  This means no
        entity objects at all, just the first option above.

What types of equality are there?
  + event equality 
    * two facts describe the same event (one gesture, one utterance)
    * two facts represent the same event 
      e.g.(event falls) (motion-event falls)
    * component-of e.g. (moves a) is a sub-part of (pushes a b)
  + fact equality
    * facts with the same data

How are events structured?
  + Have both a widget and utterance slot
  + Have both widget and utterance based versions of each class


Event merging:
  Events that are asserted to be equal are grouped into equivalence
  classes in order to form a causal story

do we need a pushes composite event?  the problem is that in
"When a then b" if the b is composite i.e. "x pushes y" then we want
to say that a leadsTo b not x and y individually.

lever recognizer

Procedures for building causal structure out of the JTRE

General query functions for JTRE

Multiple types for triggers. e.g. 

how to handle sub events?
  + if a causes b where b=x+y then lets assume a causes x
  + if a casuses x then we should say that a also causes b
  ? should we reduce everything to low level stuff?

pulley recognizer

balanced lever rule
  + when there are opposing forces
  ? should we recognize forces?
  ? how do we match "all forces on lever-L"
  + for now just look at two opposing ones...
  ? maybe just deal with attachments instead of messing with asserting
    forces for tons of things...

rotation recognizer
