Transcript Powerpoint

A Proposal for a Process
Specification Language
(Working Note 21)
Peter Clark and John Thompson
Knowledge Systems, Boeing Research
inspired by comments from:
Pat Hayes, Jim Blythe, Stuart Aitken, UT Group, and others
(http://www.cs.utexas.edu/users/pclark/working_notes)
Pre-notes
• We sometimes use the term “plan” as a shorthand
for “process specification”. The two phrases
should be considered synonymous here.
Three Important Concepts
1. Event instance (PSL: “Activity Occurrence”, Planet:
“Event Occurrence” (?))
–
–
–
–
–
The actual occurrence of an event
Situated in time (e.g., Has a time of occurrence)
E.g., “Pete getting onto the airplane at 5pm 1/26/01”
Each event instance happens only once ever!
KM syntax: (a Move with …)
Three Important Concepts
2. Event description (PSL: “Activity”, Planet:
“Operators” (?))
– A description of a type of event (set of event instances)
– E.g. “Moving” (refers to all moving event instances)
– E.g., “Pete typing on an airplane” (refers to all the instances
of Pete typing on some airplane)
– In PSL and Planet and other planners, denoted by a function,
e.g., the term (NB not predicate!):
move-onto(BlockA, BlockB)
– In KM denoted by a class, e.g.,
• Moving
• PeteTypingOnSomeAirplane
• Non-reified class descriptions, e.g.,
– (the-class Typing with (agent (Pete)) (location ((a Airplane)))
See KM Release Notes, not User Manual
Three Important Concepts
3. Plan-Step (PSL: not reified, Planet: “Events” (?))
– Are instances of “plans” (process specifications), or steps in plans
– They connect together to form a graph, which represents the plan.
Graph might include cycles. This graph is equivalent to a flowchart for doing the process.
– Connections denote the next step in the plan
– In KM, denoted by: (a Plan-Step with …)
Two Graphs
• The Process Specification (“Plan”)
– A network of plan-steps, connected by next-step links
– Flow-chart like, can include cycles, branches
• The Execution Trace
– A network of event instances, connected by temporal
links
– Usually a simple sequence (unless parallel execution
occurred)
– There may be multiple execution traces for one plan
For Example…
• The plan for “Knock-and-enter”:
– Keep knocking on the door until it opens, then
enter.
– Informally, can be sketched as:
no
Knock
on door
yes
Test:
“Door open?”
Enter
– More formally,
looks like:
Plan-Step1
do-a
substeps
A plan-step
Knock-And-Enter
next-step-if-no
Process
Specification
(“Plan”)
Plan-Step2 next-step Plan-Step3 next-step
-if-yes Plan-Step4
do-a
Knock
test
“Door open?”
do-a
Enter
An event description. The syntax for this
will be described later.
Plan-Step1
do-a
substeps
next-step-if-no
Process
Specification
(“Plan”)
Plan-Step2 next-step Plan-Step3 next-step
-if-yes Plan-Step4
do-a
subevents
Knock5
do-a
Enter
An event instance
Knock-And-Enter7
then
test
“Door open?”
Knock
Knock4
Knock-And-Enter
then
Enter6
An Execution
Trace
(“Event Sequence”)
Plan-Step1
do-a
substeps
Knock-And-Enter
next-step-if-no
Process
Specification
(“Plan”)
Plan-Step2 next-step Plan-Step3 next-step
-if-yes Plan-Step4
do-a
test
“Door open?”
Knock
do-a
Enter
occurrence-of-plan-step
occurrence-of-plan-step
Knock-And-Enter7
subevents
Knock4
then
Knock5
then
Enter6
An Execution
Trace
(“Event Sequence”)
Plan-Step1
do-a
substeps
Knock-And-Enter
next-step-if-no
Process
Specification
(“Plan”)
Plan-Step2 next-step Plan-Step3 next-step
-if-yes Plan-Step4
do-a
test
do-a
“Door open?”
Knock
Enter
instance-of
instance-of
Knock-And-Enter7
subevents
Knock4
then
Knock5
then
Enter6
An Execution
Trace
(“Event Sequence”)
Comments
• What we’ve been encoding in the UT component
library so far have been execution traces, not
process specifications (plans).
• This only runs into trouble when we want to talk
about process specifications with loops, etc., in.
(Execution traces can’t have loops!)
Seven* Types of Plan-Steps:
1. Basic-Plan-Step:
Do an action.
2. Disjunctive-Plan-Step:
Alternative next events (“or” split in the plan)
3. Conjunctive-Plan-Step:
Multiple next events (“and” split in the plan)
4. Boolean-Plan-Step:
Choice of next step depends on a binary test.
5. Conditional-Plan-Step:
Choice of next step depends on a test.
M1: Repeat-Until-Plan-Step:
Macro: Repeat a plan-step until some condition holds.
M2: Iterate-For-Plan-Step:
Macro: Repeat a plan-step a specified number of times.
* actually,
five + two
macros M1
and M2.
Seven Types of Plan-Steps (cont):
• Some footnotes:
– The seven types are a pragmatic set, not an exhaustive
set. They should suffice for our purposes, but there are
some processes they are unable to describe, e.g.,
• interrupts
• we haven’t said how to specify temporal relationships or causal
ones either (but could be layered on top)
– As a pragmatic decision:
• The 4 control steps are control structures, denoting branching
and conditionals in the process specification. We haven’t given
them an associated event description (Should we have done
so???).
1. Basic-Plan-Step: parameters:
• next-step: The next step in the plan. There can be only one.
• do-a: The event description associated with this step.
“Doing” this step involves executing an instance of this event
class.
or what should this slot name be?
Sketch:
Basic-Plan-Step3
next-step
do-a
“knock on the door”
KM:
Plan-Step4
An event description. The important
thing is that we can generate event
instances from this. In most planning
systems, they use functions for this,
e.g.,
knock(?agent,?patient)
(Basic-Plan-Step3 has
(do-a ((the-class Knock with
(agent (path))
(object (path)))
(next-step (Plan-Step4)))
In KM, we use class descriptions,
e.g.,
(the-class Knock with
(agent (path))
(patient (path)))
2. Disjunctive-Plan-Step: parameters:
• next-step: Just one of the next steps will be executed next
(e.g., just one branch will be followed). Unspecified which
one it will be. (Can have more than two next steps)
• We’d like the simulator to try each path in (different)
simulations, and report back what happens.
Sketch:
next-step
Plan-Step4
Disjunctive-Plan-Step3
next-step
KM:
(Disjunctive-Plan-Step3 has
(next-step (Plan-Step4 Plan-Step5)))
Plan-Step5
3. Conjunctive-Plan-Step: parameters:
• next-step: All of the next steps will be executed next, i.e.,
parallel execution of the different branches.
• We’d like the simulator to explore different interleavings of
events in the different branches, possibly with constraints on
the allowable interleavings.
Sketch:
next-step Plan-Step4
next-step
Plan-Step6
next-step
Plan-Step8
Conjunctive
-Plan-Step3
next-step
Plan-Step5
next-step
next-step
Plan-Step7
In the above example, 6 possible execution sequences are possible:
• 3-4-6-5-7-8,
3-4-5-6-7-8,
3-4-5-7-6-8,
• 3-5-7-4-6-8,
3-5-4-7-6-8,
3-5-4-6-7-8.
KM:
(Conjunctive-Plan-Step3 has
(next-step (Plan-Step4 Plan-Step5)))
Concerns: Do we need some
sort of a “rejoin” node? This
doesn’t allow simulation of
“race” conditions.
4. Boolean-Plan-Step: parameters:
• test (a proposition)
• next-step-if-true, next-step-if-false: Determines the next step
depending on whether the proposition is true (at the time the
plan-step is “executed”)
Sketch:
next-step-if-true
Plan-Step4
next-step-if-false
Plan-Step5
Boolean-Plan-Step3
test
Proposition (e.g.
“Door is open?”)
KM:
Can add parameters like
this to the plan-step
(Boolean-Plan-Step3 has
(destination (…))
(test (‘(the state of (the Door parts of (the destination of Self)))) = *Open)
(next-step-if-true (Plan-Step4))
A proposition (quoted
(next-step-if-false (Plan-Step5))
KM expression, which
can be evaluated)
5. Conditional-Plan-Step: (generalizes Boolean-Plan-Step).
Parameters:
• if-value: an expression
• conditional-next-step: A <value plan-step> pair. If the
expression evaluates to value, (i.e., the proposition
‘(expression=value) is true), then execute plan-step next.
Sketch:
conditional-next-step/Open
Plan-Step4
Conditional-Plan-Step3
if-value
“The state of the door”
KM:
conditional-next-step/Closed
Plan-Step5
In FOL, this
would look like:
conditional-next-step(Cond-PS3, Open, PS4).
conditional-next-step(Cond-PS3, Closed, PS5).
(Conditional-Plan-Step3 has
(destination (…))
(if-value (‘(the state of (the Door parts of (the destination of Self)))))
(conditional-next-step (
(:args Open Plan-Step4)
(:args Closed Plan-Step5) )))
M1. Repeat-Until-Plan-Step: (macro). Parameters:
• repeat: the plan-step to repeat
• until: A proposition. (Instances of) the event are done until
the proposition evaluates to true.
Sketch:
Repeat-Until-Plan-Step3
repeat
Plan- Step5
do-a
Knock
KM:
next-step
Plan-Step4
until
“The door is open”
Do we also need a
“Repeat-While”?
(Repeat-Until-Plan-Step3 has
(agent (…))
(destination (…))
(repeat ((a Plan-Step with
(do-a ((the-class Knock with
(agent ((the agent of Self)))
(object ((the Door parts of (the destination of Self))))
(until (‘((the state of (the Door parts of (the destination of Self))) = Open))))
M2. Iterate-For-Plan-Step: (macro). Parameters:
• iterate: the plan-step of the thing to do
• number-of-iterations: Number of iterations (an integer)
Sketch:
Iterate-For-Plan-Step3
Plan-Step4
number-of-iterations
iterate
Plan- Step5
next-step
3
do-a
Knock
KM:
(Iterate-For-Plan-Step3 has
(agent (…))
(destination (…))
(iterate ((a Plan-Step with
(do-a ((the-class Knock with
(agent ((the agent of Self)))
(object ((the Door parts of (the destination of Self))))
(number-of-iterations (3)))
RNA Transcription - Informal
(Illustrative - this obviously omits some of the important steps)
RNA-Transcription-Plan
substeps
“Polymerase
“Polymerase
Repeat “Copy a
next-step
next-step
collides
recognizes
nucleotide” until
with DNA”
Promotor”
at terminator.
next-step “RNA is
released”
“Copy a
nucleotide”
substeps
“Move to
“Create
next-step “Attach it
next-step the next
ribonucleotide”
to the RNA”
nucleotide”
KM Code for RNA Transcription
• The following code is not properly debugged…
• We allow both plans and events to be parameterized
by agent, patient etc. In this way, a plan can pass its
actors onto its events, and vice versa.
(RNA-Transcription-Plan has (superclasses (Plan-Step)))
RNA Transcription
KM code
(every RNA-Transcription-Plan has
(agent ((a Polymerase)))
(object ((a DNA with
(parts ((a Promotor) (a Gene) (a Terminator))))))
(the-RNA ((a RNA)))
(substeps ((a Plan-Step called "collide" with
(do-a ((the-class Collide with
(agent ((the agent of Self)))
(object ((the object of Self))))))
(next-step (((the substeps of Self) called "recognize"))))
(a Plan-Step called "recognize" with
(do-a ((the-class Recognize with
(agent ((the agent of Self)))
(object ((the Promotor parts of (the object of Self)))))))
(next-step (((the substeps of Self) called "copy"))))
(a RNA-Copy-Plan-Step called "transcribe" with
;;; A type of Repeat-Until-Plan-Step (PTO)
(agent ((the agent of Self)))
;;; Pass parameters down
(object ((the object of Self)))
(the-RNA ((the the-RNA of Self))))))
(until ('((the location of (the agent of Self)) =
(the location of (the Terminator parts of (the object of Self))))))
(next-step ((the substeps of Self) called "create")))
(a Plan-Step called "release" with
(do-a ((the-class Release with
(agent ((the agent of Self)))
(object ((the the-RNA of Self))))))
(next-step (((the substeps of Self) called "copy"))))))))
(RNA-Copy-Plan-Step has (superclasses (Plan-Step)))
RNA Transcription
KM code for
the iterated step
(every RNA-Copy-Plan-Step has
(agent ((a Polymerase)))
(object ((a DNA)))
(the-RNA ((a RNA)))
(location ((the Nucleotide parts-of of (the location of (the agent of Self)))))
(the-ribonucleotide ((a Ribonucleotide with
(type ((the complement of (the Nucleotide location of Self)))))))
(substeps ((a Plan-Step called "create" with
(do-a ((the-class Create with
(agent ((the agent of Self)))
(object ((the the-ribonucleotide of Self))))))
(next-step ((the substeps of Self) called "attach")))
(a Plan-Step called "attach" with
(do-a ((the-class Attach with
(agent ((the agent of Self)))
(object ((the the-ribonucleotide of Self)))
(destination ((the the-RNA of Self))))))
(next-step ((the substeps of Self) called "move")))
(a Plan-Step called "move" with
(do-a ((the-class Move with
(agent ((the agent of Self)))
(source ((the location of Self)))
(destination ((the next-nucleotide of
(the location of Self)))))))))))
Events and Plans
• Events and plans are related by a homomorphism:
RNA-Transcription-Plan3
RNA-Transcription3
• The event sequence can be either specified directly in the
KB (which is what we’ve been doing), and/or derived
automatically (by the simulator) from the plan.
Some Final Comments
• Need to hide the complexity of the plan structure
from the SME
Plan-Step2
do-a
presented to
SME as:
Knock
?
Knock
• Need to (somehow) hide the event description/event
instance distinction from the SME
• Outstanding issues:
• do we need a “first step” pointer to the first step in
a plan? And a “last step(s)” pointer?
Worry, Worry...
• Does the complexity involved in getting the semantics
right (and we’re probably still not quite there) makes the
whole scheme unusable?
• Perhaps some semantically ugly extension on event
sequences would be easier, and we drop the whole notion
of process specifications?
• Drew McDermott’s “Fundamental Principle of KR”
(presented at KR’2000):
“If KR is done right, the result is too complex to be used.”
Are we in danger here?