a proposal for a process specification language (working note 21) peter clark and john thompson...
TRANSCRIPT
![Page 1: A Proposal for a Process Specification Language (Working Note 21) Peter Clark and John Thompson Knowledge Systems, Boeing Research inspired by comments](https://reader034.vdocument.in/reader034/viewer/2022051618/56649f525503460f94c76aed/html5/thumbnails/1.jpg)
A Proposal for a Process Specification Language
(Working Note 21)
Peter Clark and John ThompsonKnowledge 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)
![Page 2: A Proposal for a Process Specification Language (Working Note 21) Peter Clark and John Thompson Knowledge Systems, Boeing Research inspired by comments](https://reader034.vdocument.in/reader034/viewer/2022051618/56649f525503460f94c76aed/html5/thumbnails/2.jpg)
Pre-notes• We sometimes use the term “plan” as a shorthand
for “process specification”. The two phrases should be considered synonymous here.
![Page 3: A Proposal for a Process Specification Language (Working Note 21) Peter Clark and John Thompson Knowledge Systems, Boeing Research inspired by comments](https://reader034.vdocument.in/reader034/viewer/2022051618/56649f525503460f94c76aed/html5/thumbnails/3.jpg)
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 …)
![Page 4: A Proposal for a Process Specification Language (Working Note 21) Peter Clark and John Thompson Knowledge Systems, Boeing Research inspired by comments](https://reader034.vdocument.in/reader034/viewer/2022051618/56649f525503460f94c76aed/html5/thumbnails/4.jpg)
Three Important Concepts2. 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
![Page 5: A Proposal for a Process Specification Language (Working Note 21) Peter Clark and John Thompson Knowledge Systems, Boeing Research inspired by comments](https://reader034.vdocument.in/reader034/viewer/2022051618/56649f525503460f94c76aed/html5/thumbnails/5.jpg)
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 flow-chart for doing the process.
– Connections denote the next step in the plan
– In KM, denoted by: (a Plan-Step with …)
![Page 6: A Proposal for a Process Specification Language (Working Note 21) Peter Clark and John Thompson Knowledge Systems, Boeing Research inspired by comments](https://reader034.vdocument.in/reader034/viewer/2022051618/56649f525503460f94c76aed/html5/thumbnails/6.jpg)
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
![Page 7: A Proposal for a Process Specification Language (Working Note 21) Peter Clark and John Thompson Knowledge Systems, Boeing Research inspired by comments](https://reader034.vdocument.in/reader034/viewer/2022051618/56649f525503460f94c76aed/html5/thumbnails/7.jpg)
For Example…
• The plan for “Knock-and-enter”: – Keep knocking on the door until it opens, then
enter.– Informally, can be sketched as:
Knockon door Enter
Test:“Door open?”
no
yes
![Page 8: A Proposal for a Process Specification Language (Working Note 21) Peter Clark and John Thompson Knowledge Systems, Boeing Research inspired by comments](https://reader034.vdocument.in/reader034/viewer/2022051618/56649f525503460f94c76aed/html5/thumbnails/8.jpg)
Plan-Step1
Plan-Step2 Plan-Step3
Knock
Plan-Step4
Enter“Door open?”
next-step next-step-if-yes
next-step-if-no
test
substepsKnock-And-Enter
ProcessSpecification
(“Plan”) do-a do-a
do-a
An event description. The syntax for this will be described later.
A plan-step
– More formally, looks like:
![Page 9: A Proposal for a Process Specification Language (Working Note 21) Peter Clark and John Thompson Knowledge Systems, Boeing Research inspired by comments](https://reader034.vdocument.in/reader034/viewer/2022051618/56649f525503460f94c76aed/html5/thumbnails/9.jpg)
Plan-Step1
Plan-Step2 Plan-Step3
Knock
Knock5Knock4 Enter6
Knock-And-Enter7
then then
subevents
Plan-Step4
Enter“Door open?”
next-step next-step-if-yes
next-step-if-no
test
substepsKnock-And-Enter
ProcessSpecification
(“Plan”)
An ExecutionTrace
(“Event Sequence”)
do-a do-a
do-a
An event instance
![Page 10: A Proposal for a Process Specification Language (Working Note 21) Peter Clark and John Thompson Knowledge Systems, Boeing Research inspired by comments](https://reader034.vdocument.in/reader034/viewer/2022051618/56649f525503460f94c76aed/html5/thumbnails/10.jpg)
Plan-Step1
Plan-Step2 Plan-Step3
Knock
Knock5Knock4 Enter6
Knock-And-Enter7
then then
subevents
Plan-Step4
Enter“Door open?”
next-step next-step-if-yes
next-step-if-no
testdo-a do-a
do-asubsteps
Knock-And-Enter
ProcessSpecification
(“Plan”)
An ExecutionTrace
(“Event Sequence”)
occurrence-of-plan-step
occurrence-of-plan-step
![Page 11: A Proposal for a Process Specification Language (Working Note 21) Peter Clark and John Thompson Knowledge Systems, Boeing Research inspired by comments](https://reader034.vdocument.in/reader034/viewer/2022051618/56649f525503460f94c76aed/html5/thumbnails/11.jpg)
Plan-Step1
Plan-Step2 Plan-Step3
Knock
Knock5Knock4 Enter6
Knock-And-Enter7
then then
subevents
Plan-Step4
Enter“Door open?”
next-step next-step-if-yes
next-step-if-no
testdo-a do-a
do-asubsteps
Knock-And-Enter
ProcessSpecification
(“Plan”)
An ExecutionTrace
(“Event Sequence”)
instance-of
instance-of
![Page 12: A Proposal for a Process Specification Language (Working Note 21) Peter Clark and John Thompson Knowledge Systems, Boeing Research inspired by comments](https://reader034.vdocument.in/reader034/viewer/2022051618/56649f525503460f94c76aed/html5/thumbnails/12.jpg)
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!)
![Page 13: A Proposal for a Process Specification Language (Working Note 21) Peter Clark and John Thompson Knowledge Systems, Boeing Research inspired by comments](https://reader034.vdocument.in/reader034/viewer/2022051618/56649f525503460f94c76aed/html5/thumbnails/13.jpg)
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.
![Page 14: A Proposal for a Process Specification Language (Working Note 21) Peter Clark and John Thompson Knowledge Systems, Boeing Research inspired by comments](https://reader034.vdocument.in/reader034/viewer/2022051618/56649f525503460f94c76aed/html5/thumbnails/14.jpg)
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???).
![Page 15: A Proposal for a Process Specification Language (Working Note 21) Peter Clark and John Thompson Knowledge Systems, Boeing Research inspired by comments](https://reader034.vdocument.in/reader034/viewer/2022051618/56649f525503460f94c76aed/html5/thumbnails/15.jpg)
Basic-Plan-Step3
knock(?agent,?patient)
Plan-Step4next-step
(Basic-Plan-Step3 has (do-a ((the-class Knock with (agent (path)) (object (path))) (next-step (Plan-Step4)))
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.
Sketch:
KM:
do-a
(the-class Knock with (agent (path)) (patient (path)))
“knock on the door”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.,
In KM, we use class descriptions, e.g.,
or what should this slot name be?
![Page 16: A Proposal for a Process Specification Language (Working Note 21) Peter Clark and John Thompson Knowledge Systems, Boeing Research inspired by comments](https://reader034.vdocument.in/reader034/viewer/2022051618/56649f525503460f94c76aed/html5/thumbnails/16.jpg)
Disjunctive-Plan-Step3
Plan-Step5
Plan-Step4next-step
next-step
(Disjunctive-Plan-Step3 has (next-step (Plan-Step4 Plan-Step5)))
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:
KM:
![Page 17: A Proposal for a Process Specification Language (Working Note 21) Peter Clark and John Thompson Knowledge Systems, Boeing Research inspired by comments](https://reader034.vdocument.in/reader034/viewer/2022051618/56649f525503460f94c76aed/html5/thumbnails/17.jpg)
Conjunctive-Plan-Step3
Plan-Step7
Plan-Step4next-step
next-step
(Conjunctive-Plan-Step3 has (next-step (Plan-Step4 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:
KM:
Plan-Step5
Plan-Step6
Plan-Step8
next-step
next-step
next-step
next-step
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.
Concerns: Do we need some sort of a “rejoin” node? This doesn’t allow simulation of “race” conditions.
![Page 18: A Proposal for a Process Specification Language (Working Note 21) Peter Clark and John Thompson Knowledge Systems, Boeing Research inspired by comments](https://reader034.vdocument.in/reader034/viewer/2022051618/56649f525503460f94c76aed/html5/thumbnails/18.jpg)
Boolean-Plan-Step3
Plan-Step5
Plan-Step4
Proposition (e.g. “Door is open?”)
test
next-step-if-true
next-step-if-false
(Boolean-Plan-Step3 has (destination (…)) (test (‘(the state of (the Door parts of (the destination of Self)))) = *Open) (next-step-if-true (Plan-Step4)) (next-step-if-false (Plan-Step5))
Can add parameters like this to the plan-step
A proposition (quoted KM expression, which can be evaluated)
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:
KM:
![Page 19: A Proposal for a Process Specification Language (Working Note 21) Peter Clark and John Thompson Knowledge Systems, Boeing Research inspired by comments](https://reader034.vdocument.in/reader034/viewer/2022051618/56649f525503460f94c76aed/html5/thumbnails/19.jpg)
Conditional-Plan-Step3
Plan-Step5
Plan-Step4
“The state of the door”
if-value
conditional-next-step/Open
conditional-next-step/Closed
(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) )))
In FOL, this would look like: conditional-next-step(Cond-PS3, Open, PS4). conditional-next-step(Cond-PS3, Closed, PS5).
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:
KM:
![Page 20: A Proposal for a Process Specification Language (Working Note 21) Peter Clark and John Thompson Knowledge Systems, Boeing Research inspired by comments](https://reader034.vdocument.in/reader034/viewer/2022051618/56649f525503460f94c76aed/html5/thumbnails/20.jpg)
Repeat-Until-Plan-Step3 Plan-Step4
“The door is open”
until
next-step
(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))))
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:
KM:
Plan- Step5
repeat
Knock
do-a
Do we also need a “Repeat-While”?
![Page 21: A Proposal for a Process Specification Language (Working Note 21) Peter Clark and John Thompson Knowledge Systems, Boeing Research inspired by comments](https://reader034.vdocument.in/reader034/viewer/2022051618/56649f525503460f94c76aed/html5/thumbnails/21.jpg)
Iterate-For-Plan-Step3 Plan-Step4
3
number-of-iterations
next-step
(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)))
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:
KM:
iterate
Plan- Step5
Knock
do-a
![Page 22: A Proposal for a Process Specification Language (Working Note 21) Peter Clark and John Thompson Knowledge Systems, Boeing Research inspired by comments](https://reader034.vdocument.in/reader034/viewer/2022051618/56649f525503460f94c76aed/html5/thumbnails/22.jpg)
“Polymerasecollides
with DNA”
next-step“PolymeraserecognizesPromotor”
next-stepRepeat “Copy a nucleotide” until at terminator.
next-step “RNA is released”
RNA-Transcription-Plan
next-step“Createribonucleotide”
“Attach itto the RNA”
next-step“Move tothe nextnucleotide”
substeps
substeps
RNA Transcription - Informal(Illustrative - this obviously omits some of the important steps)
“Copy anucleotide”
![Page 23: A Proposal for a Process Specification Language (Working Note 21) Peter Clark and John Thompson Knowledge Systems, Boeing Research inspired by comments](https://reader034.vdocument.in/reader034/viewer/2022051618/56649f525503460f94c76aed/html5/thumbnails/23.jpg)
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.
![Page 24: A Proposal for a Process Specification Language (Working Note 21) Peter Clark and John Thompson Knowledge Systems, Boeing Research inspired by comments](https://reader034.vdocument.in/reader034/viewer/2022051618/56649f525503460f94c76aed/html5/thumbnails/24.jpg)
(RNA-Transcription-Plan has (superclasses (Plan-Step)))
(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 TranscriptionKM code
![Page 25: A Proposal for a Process Specification Language (Working Note 21) Peter Clark and John Thompson Knowledge Systems, Boeing Research inspired by comments](https://reader034.vdocument.in/reader034/viewer/2022051618/56649f525503460f94c76aed/html5/thumbnails/25.jpg)
(RNA-Copy-Plan-Step has (superclasses (Plan-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)))))))))))
RNA TranscriptionKM code for
the iterated step
![Page 26: A Proposal for a Process Specification Language (Working Note 21) Peter Clark and John Thompson Knowledge Systems, Boeing Research inspired by comments](https://reader034.vdocument.in/reader034/viewer/2022051618/56649f525503460f94c76aed/html5/thumbnails/26.jpg)
Events and Plans• Events and plans are related by a homomorphism:
RNA-Transcription3
RNA-Transcription-Plan3
• 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.
![Page 27: A Proposal for a Process Specification Language (Working Note 21) Peter Clark and John Thompson Knowledge Systems, Boeing Research inspired by comments](https://reader034.vdocument.in/reader034/viewer/2022051618/56649f525503460f94c76aed/html5/thumbnails/27.jpg)
Some Final Comments• Need to hide the complexity of the plan structure
from the SME
Plan-Step2
Knock
Knock
do-a
presented to SME as:
• 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?
?
![Page 28: A Proposal for a Process Specification Language (Working Note 21) Peter Clark and John Thompson Knowledge Systems, Boeing Research inspired by comments](https://reader034.vdocument.in/reader034/viewer/2022051618/56649f525503460f94c76aed/html5/thumbnails/28.jpg)
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?