Up: An Open Agent Architecture
In addition to the integration activities discussed
above, a number of future research activities are needed. In order
that an agent be invocable, its capabilities need to be mapped into
terms understood by the ensemble of agents, and also by users.
Moreover, as discussed earlier, the natural language vocabulary needed
to invoke an agent's services, including lexical, syntactic, and
semantic properties, will also be posted on the blackboard for use by
the user interface. In general, however, this advertising of
vocabulary can lead to conflicts among definitions. We intend to
develop an API Description Tool, with which the agent designer
describes the services provided by that agent. The tool will produce
mappings of expressions in ICL into those services, including vocabulary
and knowledge representations that can be merged into a common whole.
Techniques used in developing natural language database porting tools
(e.g., TEAM []) will be investigated.
In order to generalize the simulation approach in
MAILTALK to encompass the entire collection of agents, the API
Description Tool also needs to supply information sufficient to allow the
agent architecture to simulate an agent's behavior.
It will need to characterize the preconditions and
effects of agent actions, thereby also providing a basis for a server's
planning to incorporate the agent into a complex action that
satisfies a user's
stated goal [].
Finally, an interesting question is where to situate the temporal
reasoning subsystem. Currently, it is located with the blackboard
server, but it could also be distributed as part of the agent layer,
enabling other agents to accept complex expressions for evaluation
and/or routing. We intend to experiment with various architectures.
Mon Aug 12 15:12:15 PDT 1996