1 / 28

A Proposal for a Process Specification Language (Working Note 21)

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.

kaili
Télécharger la présentation

A Proposal for a Process Specification Language (Working Note 21)

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. 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)

  2. Pre-notes • We sometimes use the term “plan” as a shorthand for “process specification”. The two phrases should be considered synonymous here.

  3. 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 …)

  4. 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

  5. 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 …)

  6. 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

  7. For Example… • The plan for “Knock-and-enter”: • Keep knocking on the door until it opens, then enter. • Informally, can be sketched as: no yes Knock on door Enter Test: “Door open?”

  8. More formally, looks like: Plan-Step1 do-a substeps Knock-And-Enter A plan-step next-step-if-no Process Specification (“Plan”) next-step next-step -if-yes Plan-Step2 Plan-Step3 Plan-Step4 do-a test do-a “Door open?” Enter Knock An event description. The syntax for this will be described later.

  9. Plan-Step1 do-a substeps Knock-And-Enter next-step-if-no Process Specification (“Plan”) next-step next-step -if-yes Plan-Step2 Plan-Step3 Plan-Step4 do-a test do-a “Door open?” Enter Knock An event instance Knock-And-Enter7 subevents An Execution Trace (“Event Sequence”) Knock4 Knock5 Enter6 then then

  10. Plan-Step1 do-a substeps Knock-And-Enter next-step-if-no Process Specification (“Plan”) next-step next-step -if-yes Plan-Step2 Plan-Step3 Plan-Step4 do-a test do-a “Door open?” Enter Knock occurrence-of-plan-step occurrence-of-plan-step Knock-And-Enter7 subevents An Execution Trace (“Event Sequence”) Knock4 Knock5 Enter6 then then

  11. Plan-Step1 do-a substeps Knock-And-Enter next-step-if-no Process Specification (“Plan”) next-step next-step -if-yes Plan-Step2 Plan-Step3 Plan-Step4 do-a test do-a “Door open?” Enter Knock instance-of instance-of Knock-And-Enter7 subevents An Execution Trace (“Event Sequence”) Knock4 Knock5 Enter6 then then

  12. 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!)

  13. Seven* Types of Plan-Steps: * actually, five + two macros M1 and M2. 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.

  14. 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???).

  15. 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: next-step Plan-Step4 Basic-Plan-Step3 do-a An eventdescription. The important thing is that we can generate event instances from this. In most planning systems, they use functions for this, e.g., “knock on the door” KM: 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)))

  16. 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: Plan-Step4 next-step Disjunctive-Plan-Step3 Plan-Step5 next-step KM: (Disjunctive-Plan-Step3 has (next-step (Plan-Step4 Plan-Step5)))

  17. 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 Plan-Step6 next-step next-step Plan-Step8 Conjunctive-Plan-Step3 next-step next-step Plan-Step5 Plan-Step7 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. KM: Concerns: Do we need some sort of a “rejoin” node? This doesn’t allow simulation of “race” conditions. (Conjunctive-Plan-Step3 has (next-step (Plan-Step4 Plan-Step5)))

  18. 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: Plan-Step4 next-step-if-true Boolean-Plan-Step3 test Plan-Step5 next-step-if-false Proposition (e.g. “Door is open?”) Can add parameters like this to the plan-step KM: (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)) A proposition (quoted KM expression, which can be evaluated)

  19. 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: Plan-Step4 conditional-next-step/Open Conditional-Plan-Step3 if-value Plan-Step5 conditional-next-step/Closed “The state of the door” In FOL, this would look like: conditional-next-step(Cond-PS3, Open, PS4). conditional-next-step(Cond-PS3, Closed, PS5). KM: (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) )))

  20. 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. next-step Sketch: Repeat-Until-Plan-Step3 Plan-Step4 until repeat Plan- Step5 “The door is open” do-a Do we also need a “Repeat-While”? Knock KM: (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))))

  21. M2. Iterate-For-Plan-Step: (macro). Parameters: • iterate: the plan-step of the thing to do • number-of-iterations: Number of iterations (an integer) next-step Sketch: Iterate-For-Plan-Step3 Plan-Step4 number-of-iterations iterate Plan- Step5 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)))

  22. RNA Transcription - Informal (Illustrative - this obviously omits some of the important steps) RNA-Transcription-Plan substeps “Polymerase collides with DNA” “Polymerase recognizes Promotor” Repeat “Copy a nucleotide” until at terminator. next-step next-step next-step “RNA is released” “Copy a nucleotide” substeps “Move to the next nucleotide” “Create ribonucleotide” “Attach it to the RNA” next-step next-step

  23. 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.

  24. RNA TranscriptionKM code (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"))))))))

  25. RNA TranscriptionKM code for the iterated step (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)))))))))))

  26. 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.

  27. Some Final Comments • Need to hide the complexity of the plan structure from the SME presented to SME as: ? Plan-Step2 Knock do-a 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?

  28. 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?

More Related