Page Numbers: Yes First Page: 1 Not-on-first-page
Heading:
April 22, 1979 11:35 PM[IVY]<KRL>document>stray-odyssey
Slides For Papers and Talks On Odyssey
Cognitive Sciences Seminar Outline (55 minutes)
Introduction (2 minutes)
Tape (23 minutes)
Forms and Data Bases (5 minutes)
KRL characterization. (10 minutes)
Dependency mechanism. (10 minutes)
Complex updating. (5 minutes)
Forms and Data Bases
ZA form is an input/output device that provides a view on a portion of a data base.
Forms Subsystem -- Some of its Properties
ZAdds areas to forms based on the semantics of the task.
ZRemoves and merges areas in response to user commands.
ZMonitors the data base and responds to changes in it.
ZProvides flexible input formats.
Data Base Subsystem
ZData base includes descriptions of travel steps, lodging stays, and day activities that redundantly describe the trip plan.
Z Data base is independent of the forms subsystem.
ZData can be entered or changed at any time in any of these descriptions.
Z The data base provides default values.
Z Attached procedures have the tasks of:
9 Maintaining the redundencies,
9 Inferring new descriptions,
9 Incorporating new descriptions into the data base.
o Same object test
o Merging descriptions
9 Removing descriptions upon request.
KRL as an Extended Record Package
Z Record declarations
9Default values for fields,
9Extended typing of fields using instance descriptors,
E.g.,A Date with year = 1979
9Uniform internal representation,
9Can associate actions with fields and records,
9Inheritance from parent declarations (i.e., subclassing).
Example Declarations
#Activity -- A step in a task plan.
parentActivity: An Activity
status:↑1Or(’Created, ’Enabled, ’Initiated, ’Completed)
InitialValue(’Created)
1: Trigger(WhenFilled, ’(InvokeStatusChangeAction))
#TripPlanningSubActivity↑1 -- A trip planning step.
1: FurtherSpecified(Activity)
parentActivity: A PlanATrip
trip:↑2 A Trip2: Trigger(ToFind, ’(FetchTripFromParent))
#PlanTripDay↑1 -- A trip planning step that plans a given day.
1: FurtherSpecified(TripPlanningSubActivity)
self:↑2 2: Trigger(WhenInitiated, ’(InitiatePlanTripDay))
date: A Date -- The day being planned.
KRL (continued)
Z Anchors and Instances
9An anchor is a location in the data base containing the description of some entity.
E.g.,"the start date for Trip1"
"TravelStep3"
9An anchor is describable:
o With a Lisp value,
o With a pointer to another anchor,
o As an instance of a record,
E.g., A Date with
year = 1979
month = October
dayOfMonth = 4
o As a field in an instance of a record,
E.g., The month fromA Date thatIs date22
9An anchor can contain multiple descriptors,
E.g.,A Traveler; An Employee
9An anchor can have associated with it a second anchor containing a meta description.
E.g.,anch:↑1 SFO1: An Assumption
KRL (continued)
Z Attached procedures (actions)
9Attached to instances, in record declarations, or globally;
9Uniformly invoked by system during fetches and stores;
E.g., ToFind, BeforeFilled, WhenFilled, etc.
9User can define action types and invoke actions.
E.g., WhenInitiated, ToRemove.
o Allows message passing, ala SmallTalk.
Z Operations
9Fire actions.
9Fetch and store via path specification or simple pattern matching.
E.g., "Seek the date fromA TravelStep thatIs
the postTravelStep fromA LodgingStay
thatIs x"
"Seek the middleName fromA Person with
firstName = Richard
lastName = Fikes
whose homeTown is PaloAlto"
A Truth Maintenance Facility for a Frame Structured Repreentation
The Computational Problem
ZConsider a computation that uses the values in a set of anchors (the source anchors) to produce a value for some other anchor (the result anchor).
Z The computation is to occur in a context where:
9The source values may be provided in any order and at any time,
9 Source values may be changed at any time,
9More than one function may be available for determining a value for the result anchor.
Specification and Activation
Z Computations are specified as:
9 A Pusher function attached to a source anchor, or as
9 A Puller function attached to the result anchor.
Z A Pusher is activated by a value being stored into its anchor.
9 Always attempts to compute a result,
9 Overrides other results.
ZA Puller is activated by a fetch operation on its anchor when the anchor has no value.
9 Computes a result only when needed,
9 Is overriden by any other result.
Properties of The Facility
ZIf a source value is missing, then that source anchor is marked so that the computation can pause and be retried when the value becomes available.
ZIf any of the source values for a completed computation change, then the computation will be redone.
ZIf a computation’s result anchor is given a value by some other function, then the computation is deactivated.
Z A computation can be made immune to deactivation so that it behaves as if it had been specified as a pusher on each source anchor.
ZA paused puller is deactivated when all computations that requested its result have been deactivated.
ZIf a computation is specified as a pusher, then only one pusher attached to one of the source anchors is needed.*
ZA puller will not be invoked while it is paused.
ZA description of each active computation is accessible from the source and result anchors.
Example Pushers and Pullers
#TravelStep -- A travel step in a trip.
self:
from:↑1 Or(An Airport, A City)
1: Trigger(ToFind, ’(GetFromPreTravelStep to))
Trigger(ToFind, ’(GetPrincipalCity))
Trigger(WhenFilled, ’(PutMetroArea))
fromMetroArea: A MetropolitanArea
to:
toMetroArea:
date:↑2 A Date
2: Trigger(WhenFilled, ’(PutInPostLodgingStay
’arrivalDate))
Trigger(WhenFilled, ’(PutInPreLodgingStay
’departureDate))
departureTime:
arrivalTime:
means:
comments:
preLodgingStay:
postLodgingStay:
travelActivity:
preTravelStep:
postTravelStep:
Making complex changes in the data base
ZMulti-step changes produce momentary inconsistencies.
ZNo general solution.
ZBasic strategy:
9Remove the values from all anchors that are to be changed,
9Remove any structures,
9Put in the new values.
ZThe changed anchors should be blockaded during the value removals to prevent the removed value from being recomputed.
ZRemoving a Structure:
9Unlink it from all structures that are not being removed.
E.g.,Unlink a travel area from its form,
Unlink a travel step from its adjacent travel steps.
9Initiate the removal of associated structures.
E.g., Removing a travel area implies removing its
travel step,
Removing a travel step implies removing its day
activity.
Answer questions about the office, its people, and its procedures.
Where is there video tape equipment in the building to show a tape?
How do I go about getting a tape made? Who do I contact? What are the steps in the process and how long do they typically take?
How do I get a tape cleared for showing outside Xerox? How long does it take?
I need a stop watch for the day. How do I get one?
Additions to Odyssey:
Provide it with a capability to determine approximate flight times between cities.
Allow statements of preferences and constraints outside the forms
Add other forms.
[GetFromMetroArea (LAMBDA NIL
(PullFiller(Seek with sources the principalCity from a MetroArea thatis
my ’toMetroArea]
[PutInPostTravelStep (LAMBDA (slotName)
(PushFiller(Overwrite the !N slotName from a TravelStep that is my
postTravelStep with FILLER returning sources]
Merge Areas Example
Merge "Pittsburgh to Boston" with "Boston to JFK".
MergeTravelAreas -- Save postArea, postLodgingStay, to, and arrivalTime from the Boston-JFK step. Also, save dates from both steps. Remove the Pittsburgh-Boston step’s date, postArea, postLodgingStay, to, toMetroArea, and arrivalTime..
RemoveArea -- Remove the area for the Boston-JFK step. Delete area from the subArea list of the ellipsis. Unlink the area from its pre and post areas. Remove the links to the fatherArea and to the form.
RemoveTravelArea -- Call RemoveTripPart to remove the travel step.
RemoveTripPart -- Unlink the step from its pre and post steps. Change the step’s inTrip? status to REMOVED and delete the step from the trip’s list of travel steps. Remove the link to the trip.
RemoveTravelStep -- Unlink the step from its pre and post lodging stays and from its travel activity. Remove the travel activity.
Link the "Pittsburgh-Boston" area to the "La Guardia-?" area -- The corresponding travel steps are linked. The linking causes the Pittsburgh-Boston step to get La Guardia as a "to".
Notes on data base changes
Basic strategy is first remove all fillers that are going to be changed. Then putting in new ones one at a time doesn’t produce inconsistencies. For that to work, one would need to be able to prevent any other filler from being put into the anchors whose fillers are being removed until all the removals were completed. The blockade is needed to ensure that a removed filler is not recomputed using fillers that are to be removed.
One can block fillers from being put into an anchor by attaching a BeforeFilled trap to the anchor that aborts the Describe.
Removing a structure involves removing all its links to structures that are not to be removed and initiating the removal of other structures.
Data Flow Between Stays and Steps
arrivalDate -> date. arrivalTime -> arrivalTime. Dates, times, city.
Dates are pushed between adjoining lodging stays.
Metropolitan areas are pushed between adjoining travel steps. If a step does not have a "to", then it is obtained from the postStep’s "from". If a step does not have a "to" and the postStep does not have a "from", then the principal city of the step’s toMetroArea is used.