Basically, to formulate a knowledge model in KSM, three perspectives are defined: (1) the knowledge-area perspective, which plays the role of the central structure of the model as a structured collection of knowledge bodies, (2) the task perspective, similar to the task layer of KADS and (3) the vocabulary perspective, which includes the basic terms shared by several knowledge modules.
The knowledge-area perspective is used for presenting a general image of the model where each module represents what is called knowledge area. In general, a knowledge area identifies a body of expertise that explains a certain problem-solving behaviour of an intelligent agent. Typically, a knowledge area is associated to a professional skill, a qualification or speciality of an expert. The whole knowledge model is a hierarchical structure of knowledge areas in such a way that there is a top-level area representing the entire model. This area is divided (using the part-of relation) into other more detailed subareas that, in their turn, are divided into other simpler areas and so on, developing the whole hierarchy (where some areas may belong to more than one higher level area). A bottom level area is called primary knowledge area and corresponds to an elementary module that may be directly operationalized by using basic software tools.
Knowledge areas are not passive modules but, in general, they can provide different services represented by a set of tasks. The task perspective presents a functional description for each task using a tree of task-method-subtasks. A task defines a goal to achieve (with a set of inputs and a set of outputs) and the method describes how to carry out the task. In KSM methods are formulated using a particular language called Link (supported by an interpreter at run time). This language allows to represent the line of reasoning of problem-solving methods with two main parts: the data flow section, that defines how tasks are connected, and the control flow section, that uses rules to establish the execution order of tasks. KSM uses an additional descriptive component called knowledge unit that is defined by the triple <A, K, T>, where A is the area associated to the knowledge unit, K is the set of subareas in which A is decomposed into and T is the set of tasks provided by A. The purpose of the knowledge unit is to serve as a package that encapsulates the components associated to a knowledge area.
Finally, the vocabulary perspective is formulated with a set of components called conceptual vocabularies. A conceptual vocabulary defines a basic terminology used by several knowledge areas. A vocabulary is not a description of the whole domain knowledge, but it defines a partial view including the basic terms that are common to different knowledge bases. In KSM vocabularies are formulated using a particular language called Concel that uses a concept-attribute-facet representation together with an organization in classes-subclasses-instances.
In order to operationalize a knowledge model defined by the previous three perspectives, KSM provides computable constructs implementing basic problem-solving techniques that are called primitives of representation. The knowledge level model is operationalized by associating these components to knowledge areas. A primitive may be viewed as a generalization of the concept of shell, considering also non knowledge based techniques. Each primitive include a knowledge acquisition user interface, a set of inference procedures and explanation facilities. In order to produce the operational version of the knowledge model, the developer associates a copy of a primitive to each primary knowledge area. KSM has an open library of such primitives to support the knowledge model. The library can be extended with other more specific primitives. Thus, the use of an open library allow to manage a multi-representation environment where it is possible to select the most appropriate technique for each case. This is particularly important in real systems where efficiency must be taken into account.
The structure of knowledge-areas, tasks and vocabularies (with the associated primitives of representation for operationalizing) is called generic model, given that it is general and reusable. To develop a model for a particular domain the developer creates a quasi-isomorphic structure of knowledge areas specialized in the domain as an instantiation of the general description. For each generic knowledge area there will be one or more domain knowledge areas, following the same relations established by the generic model. The developer particularizes the domain structure writing particular knowledge bases (using the set of knowledge acquisition facilities provided by primitives), creates domain conceptual vocabularies and he/she also may redefine at domain level the generic control knowledge defined in methods using the Link language. After this process, the model is ready to be executed for solving problems. Then, KSM also assists the operator during the maintenance and the execution of the final model.