;;;; -*- Mode: LISP; Syntax: Common-Lisp; Base: 10 -*- ;;;; --------------------------------------------------------------------------- ;;;; File name: notes.lsp ;;;; System: ;;;; Version: 1.0 ;;;; Author: Ken Forbus ;;;; Created: November 17, 2000 20:51:52 ;;;; Purpose: Implementation notes for FIRE ;;;; --------------------------------------------------------------------------- ;;;; Modified: Wednesday, May 2, 2001 at 17:42:29 by usher ;;;; --------------------------------------------------------------------------- #| 11/17/00: decided to keep domain theory structure intact for now, since we want backward compatibility. need to think about this more later. 12/11/00: one of the design issues with the ask/tell interface is cleanly dispatching through the various combinations of the keywords, which are currently :context -- this is for taking microtheory/domain theory restrictions into account. the simplest example would be the use of cases, i.e., querying with respect to a case, i.e., (ask :context ...) in that situation, presumably we know something somewhere about the logical environment of that case, the inferential analogy of lexical scoping. claim: regarding logical environments, we want them to be lexically scoped, albeit with the ability to evaluate queries with respect to different environments for simulative reasoning. that may require projecting the microtheory structure into the working memory, which isn't something we had considered before, but might be necessary. :number -- controls the number of responses, e.g., the best 3 answers one can come up with, with :all the default meaning exhaustive. a big difference from dte is that we are not caching queries and updating possible responses as new information comes in. this is important, because the chaining part of the reasoner needs to be lightweight and low-impact. :response -- controls what is returned. :bindings, :pattern are the simple cases, otherwise the value is taken to be a custom form on which sublis is done with the bindings returned by the query. :effort -- controls how much work can be done to answer the question. we know we don't know the right answer here, so the idea is to use a simple language (alist) of constraints that can be posted, like :depth, :kb-only, :total-nodes, etc. issue: when and where to cache negative results during backchaining? dte cached everything, which made it a memory hog. prologs cache nothing, counting on the low overhead of their operation to make it unnecessary. the typical desire is to cache only the "expensive" operations, but deterining what those are can be a bear. issue: efficient context-limited retrieval. a simple model is: 1. find things that match, given a pattern. 2. filter those matches by whether or not they are in the logical environment of the specified context. kind of inefficient, if we assume that checking the context is faster than doing the unification required to do the match. if we have two facts about populations in a case, and the whole cia fact book, we really don't want to be handling the cia fact book information about populations when the query is limited to that case. one approach: suppose we have uses relationships between contexts, that is, c1 uses c2 means that c2 should be consulted when the derivational context is c1, in addition to whatever content c1 itself has. thus we can have a uses list associated with each context that can be used to intersect context information associated with facts to filter results. issue: tell needs to know when to propagate information to sources. this is going to be handled by the registry in the reasoner. issue: when information is added to the working memory, when should the ltre rule queue be emptied? presumably this is something we want under tight program control, so that we can deal with contradictions appropriately. maybe we need to add contradiction handler control to the reasoner as one of its jobs? 12/13/00: what should the arguments be to the handlers? need to pass in the input parameters from the signature. source as well? 12/26/00: getting the first analogy done in fire: what needs to be implemented? 1. link from ask of a match-between to the creation of the appropriate cases and an sme. 2. carrying out the match, given the appropriate constraints. if there is already an sme, this may mean re-mapping if the constraints or base and target have changed, or just retrieving results otherwise. 3. reifying the results. reifying an sme means adding (matcherFn ) to the analogy source, with a couple of assertions into working memory. reifying a mapping means adding (MappingFn ) to the analogy source, which in turn means adding (MhFn ) to the analogy source for those mh's in the mapping, and (CandidateInferenceFn ) to the analogy source for each of the inferences of the mapping. these are working memory representations, designed to minimize the load imposed by reification. should the analogy be stored in the kb, these need to be "lifted" by using content-level replacements, e.g., if we need to talk about a match, something like (AnalogyFn ) for the match itself, (AnalogyMappingFn ) for mappings (CorrespondenceFn ) for mh's 1/1/01 implemented genls cache. takes about 141 msec to compute on alice, so i rolled it into the kb creation step. provides tremendous speedup in instance-of calculations. next to do on analogical reasoning in fire: 1. documentation 2. add support for mixed-case kb's 3. design server commands 4. implement analogy server 5. hook up the other match strategies from hpkb. 6. cut binary |# ;;;; --------------------------------------------------------------------------- ;;; END OF CODE