A scheme such as that described above for integrating context into problem solving would collapse under the weight of all its c-schemas if every conceivable context were to be represented. Instead, we rely on representing relatively few contexts as c-schemas, but combining them as needed to adequately represent a particular situation. In past work [\protect\citenameTurner, 1989a], this was implemented trivially by keeping c-schemas on a list, ordered by specificity (using a set of similarity metrics). When information was needed about the context, the first c-schema that could supply the information was used. There are two major drawbacks to this approach. It is not clear that any one schema represents the whole context better than all others: when operating on low power under ice, which c-schema best represents the situation, ``operating on low power'' or ``under ice''? It is also likely that by throwing out information from all but one schema, we were often omitting information that was useful in the situation.
Currently, we are investigating ways to merge information from more than one
c-shema on demand, then caching it for reuse while in the same situation. If
only one c-schema in the current set can provide the information required,
that information is used. If more than one can provide non-conflicting
information, then either the most specific piece of information or a
straightforward combination of the pieces can be provided to the problem
solver. However, if the information conflicts, then the context manager has
three choices: (1) disregard all the information and force the problem solver
to rely on whatever context-independent (default) information it has; (2)
disregard all the information except that from the most specific c-schemas
whose information on the subject does not conflict; or (3) engage in
additional reasoning (e.g., conflict resolution rules, case-based reasoning,
etc.) to resolve the conflict. Future work will focus on this issue.
To keep the number of schemas small, yet adequately cover the range of situations the reasoner is likely to encounter, the system designers (and the agent's own learning processes) will need to ensure that the contexts they choose to represent are as nearly-orthogonal as possible. This way, they can be easily used as building blocks to describe other situations. A reasonable heuristic is that a context should only be represented if (1) there are implications for behavior in that context that cannot be inferred by combining information in existing c-schemas or (2) if the context arises so often that the processing time-storage space tradeoff would be favorable.