Declarative interaction through interactive planners

1
Declarative interaction through interactive
planners
Conn V Copas Defence Science Technology
Organisation Australia Ernest A
Edmonds Loughborough University of
Technology Great Britain
2
Presentation aims

• To introduce concepts of planning and declarative
  interaction
• To describe an implementation of an interactive
  planner
• goal description languages
• To compare planning with HCI formalisms
• model-based UIMSs
• Petri nets

3
Concepts of Planning - 1
A
C
B
A
B
C

• Initial state
  Goal state
• (on C A) (on A Table) (on B Table)
  (on A B) (on B C)
• Operator definitions
• operator (move ?What ?From ?To)
• precondition (clear ?What) (clear ?To)
• effect (on ?What ?To) (not
  (on ?What ?From))
• (clear ?From) (not (clear ?To))

4
Concepts of Planning - 2

• Plan (move C A Table) (move B Table C) (move A
  Table B)
• Planner searches (nondeteministically) for
  operator combinations which will achieve the goal
• Operators could be user-level commands
• A form of automatic programming

5
A GIS goal

• I would like to see the roads data on a white
  background, containing a legend in the bottom
  right corner and a scale-bar on top

6
A GIS command line

• d.mon startx0
• d.erase colorwhite
• d.rast -o maproads
• d.scale at0,0
• d.frame frameframe0 at0,40,75,100
• d.erase colorblack
• d.legend maproads
• General purpose, low-level application

7
Graphical GIS user interfaces

• Pull-down menus reflect the command-line
• The interface reflects the underlying programming
  language
• Direct manipulation possibilities limited by
  ability to represent actions by gesture

8
Declarative interaction

• Users describe goals machine infers procedures
• Intelligent interfaces, or just constraint
  satisfaction?
• Planners as indirect manipulation
• acceptability?

9
UCPOP (Penberthy Weld 92)

• Public-domain planner supporting conditional
  effects, dynamic object universes, universal and
  existential quantification
• Proveably sound and complete
• regressive
• first-principles
• partial-order
• domain-independent
• closed world assumption instantaneous effects

10
GIS domain knowledge

• (operator d-rast
• parameters (?container ?name ?data ?map)
• precondition (and (selected ?container
  ?name) (data ?data) )
• effect (and
• (displayed-in ?container ?name
  map ?map)
• (kind map ?map two-d)
• (refers-to map ?map data
  ?data) )
• (forall (?A ?B)
• (when
  (displayed-in ?container ?name ?A ?B)
• (not
  (displayed-in ?container ?name ?A ?B))))
• (forall (?frame ?id ?X ?Y)
• (when (and
  (contains ?container ?name ?frame ?id)
• 
  (displayed-in ?frame ?id ?X ?Y))
• (not
  (displayed-in ?frame ?id ?X ?Y)) ))
• (forall (?colour)
• (when
  (background-colour ?container ?name ?colour)
• (not
  (background-colour ?container ?name ?colour))))
• (forall (?frame1 ?id1
  ?colour1)
• (when (and
  (contains ?container ?name ?frame1 ?id1)

• The d-rast command
• requires a currently selected
• container, and some data.
• Its effects are that a map
• is displayed in the container,
• and that, if anything is
• already displayed, then all
• contents are overwritten

11
Goal description languages

• problem of Lisp/Ucpop syntax
• problem of mastery of predicate calculus
  conjunction, disjunction, negation, universal
  quantification
• lack of guidance about possible goal statements
• analogy with SQL the language is declarative,
  demanding, and limited by its first-order nature

• goal (exists (window ?x)
• (exists (frame ?y)
• (exists (scale-bar ?z)
• (and
• (background-colour ?x white)
• (displayed-in ?x map roads)
• (contains ?x ?y)
• (position frame ?y "0 40 75 100")
• (displayed-in ?y legend roads)
• (displayed-in ?x scale-bar ?z)
• (position scale-bar ?z "0 0") ))))

12
A GIS data model
DISPLAYED
SCALE
position
IN
BAR
WINDOW
background
DISPLAYED
kind
REFERS
MAP
IN
TO
DATA
kind
DISPLAYED IN
CONTAINS
FRAME
LEGEND
REFERS TO
position

• Planners model state transitions, with domain
  structure only implicit
• Data model necessary for methodical UI design

13
A planner form-filling interface

• Resembles a graphical data-base interface, but
  with explicit quantifiers
• Irrelevant (to the user) whether the plan is
  retrieved or derived
• Possibility of sketching the goal?

14
HCI specification

• Individual UIMS, CSCW and TA models?
• Specification causes inflexibility?
• Run-time generation of dynamics as a solution
• Formalisms
• transition networks
• context-free grammars
• event languages
• production rules
• Petri nets

15
HCI specification

• Individual UIMS, CSCW and TA models?
• Specification causes inflexibility?
• Run-time generation of dynamics as a solution
• Formalisms
• transition networks
• context-free grammars
• event languages
• production rules ATNs
• Petri nets causal
  models
• 
  high-level rules

16
Uses of causal knowledge
Model-based UIMS (UIDE)
projection
Knowledge base
Operators preconditions effects
Planner - progressive - regressive
path finding algorithm
dependency analysis
Predicate transition net
17
Dependency analysis
Operator-1 preconditions A effects C,D
Operator-2 preconditions B,C effects G
Operator-3 preconditions D,E effects B,F
18
Petri net challenges

• Why generate a net manually?
• Expressiveness
• conditional effects
• universal quantifiers
• (also a problem for model-based UIMS)
• Ontological clarity
• inhibitor arcs? places? tokens?
• Scalable reachability analysis

19
Conclusion

• Contemporary planners are sufficiently expressive
  and have sufficient performance to support
  declarative interaction
• Graphical goal description languages are possible
• Planning supports constraint satisfaction, as a
  general solution to inflexible system dynamics
• Shortcomings
• performance (?)
• the formalist fantasy?

20
Any questions?