5.1 Generic Structure of Expert Modules

  The overall structure on an expert module is not specific to the class of IMMPSs. Rather, the notion of expert module is generic and suitable for other applications as well. The experts are accessed by other components in a client-server fashion. Requests will be granted taking into account the user model and the context. Experts may require, and vice versa provide, services from/to external knowledge sources, such as the application and the user himself.

Figure 11 shows the overall logical structure of a generic expert module. The core of the expert module is obviously the knowledge it represents. This knowledge can consist of a number of logically distinct knowledge bases, each for a logically different aspect to be dealt with, or only a single knowledge base, when such distinction is not relevant. The Inference Engine provides a uniform and general view of the stored knowledge and of that which is inferable from it. Maintenance involves incorporating new knowledge, which could be inconsistent with the current state. If this is the case, inconsistency must be resolved by some triggered action performed by an Integrity Checking sub-module.

 

Figure 11: General Structure of an Expert Module 

The experts provide services to other components of the system through the Server Manager. Its clients are the layers of the presentation system, other experts or external entities, namely the external sources or the application. The Server Manager transforms the interface operations into (a collection of) messages to the Inference Engine, collects the answers, and responds to the client. Two interfaces allow the inference engine to acquire knowledge respectively from the User Expert and the Context Expert. Finally, the Acquisition Interface supports access to other undefined servers. This is necessary when the knowledge of the expert depends on other factors in addition to user and context. As an example, the Application Expert has to interact with the application to request application data.

It is often useful and intuitive to have a logically structured view of a knowledge base as indicated in Fig. 11. Real systems are not required to satisfy this logical distinction in an implementation. For instance, the implementation could combine all the knowledge in a single knowledge base, or structure it under other points of view. We also stress that this RM is neither concerned with the proposal of a certain format or language for the representation of knowledge, nor with the proposal of a certain language and protocol for the exchange of knowledge between a knowledge-base and other components. Such issues are treated, for instance, in the ongoing standardization effort for KQML [5].