A Purpose Driven Method for the 
Comparison of Modelling Frameworks[*]

 

Frances M.T. Brazier and Niek J.E. Wijngaards[*]

February 28th, 1998
Artificial Intelligence Group
Department of Mathematics and Computer Science
Vrije Universiteit Amsterdam
de Boelelaan 1081a, 1081 HV Amsterdam, The Netherlands
Email: {frances, niek}@cs.vu.nl
URL: http://www.cs.vu.nl/~wai
Keywords: purpose-driven comparison, knowledge engineering, modelling frameworks.
 
Abstract. During the past decade a number of modelling frameworks for knowledge based systems have been developed. In this paper an approach to the comparison of modelling frameworks is proposed, based on the aims and purposes behind the frameworks. Comparison is based on the purposes included in the instrument proposed. The purpose oriented comparison of the frameworks DESIRE, CommonKADS, PROTÉGÉ-II, MIKE, VITAL, TASK and RDR illustrates the value of its use: differences and similarities between the modelling frameworks are made explicit. The instrument can be used to support cross-modelling framework reuse.
Contents  

1 INTRODUCTION

During the past decade much research within the field of knowledge engineering has focussed on the development of frameworks to support the design of knowledge based systems. A number of knowledge engineering modelling frameworks have been developed with different aims, and for different purposes. These aims and purposes, however, are often implicitly embedded in the modelling frameworks and have not often been made explicit.

To understand and appreciate the differences between the different modelling frameworks a number of comparisons between languages and frameworks have been made. Different approaches have been taken, some based on problem-oriented comparisons, others based on specific characteristics of a modelling framework, and still others based on the goals behind modelling frameworks.

Problem-oriented comparisons (comparisons based on the application of an approach to one given problem) to both languages (Treur & Wetter, 1993; Harmelen, Lopez de M[daggerdbl]ntaras, Malec & Treur, 1993) and modelling frameworks (Linster, 1991, 1994; Schreiber & Birmingham, 1996), have been successful in stimulating discussion and understanding of different modelling frameworks. One of the conclusions of these comparisons, for example of the comparison of modelling frameworks, (Schreiber & Birmingham, 1996) on the basis of the VT-example (Marcus & McDermott, 1989; Marcus, Stout, and McDermott 1988; Yost & Rothenfluh, 1996), however, is that a well-defined basis for comparison is essential. This same conclusion was reached by Fensel and van Harmelen (1994) for the comparison of KADS-based languages, on the basis of a comparison of modelling primitives.

Another approach to the comparison of modelling frameworks to acquire insight in the strengths and weaknesses of the different modelling frameworks is to analyse the purposes and aims behind a framework. A method for purpose-driven comparison of languages, is proposed in (Revise, 1996). In (Revise, 1996) a number of goals behind the design of two formal specification languages are identified and compared. Design choices are related to the goals pursued.

For each of these types of comparisons (problem-driven, modelling primitive-driven and purpose-driven comparisons) advantages and disadvantages can be identified.

Advantages and disadvantages of a problem-driven comparison are:
 

+ A well-described problem in which specific aspects of a problem are highlighted, provides a concrete basis for comparison.
- The problem needs to be sufficiently broad to be able to identify strengths and weaknesses of approaches.
- Solutions may differ significantly and thus make comparison difficult.
Advantages and disadvantages of a modelling primitive-driven comparison are:
+ Within the well described scope of application, a good comparison can be made.
- The scope of such a comparison is limited to already similar approaches.
- A comparison based on modelling primitives does not take into account the reason why a modelling primitive is present, but does compare modelling primitives on syntactical (`superficial') similarities.
Advantages and disadvantages of a purpose-driven comparison are:
+ a list of possible purposes provides a well-defined basis for comparison
- the purposes behind an approach are not always known (have not been made explicit)
- concrete implications of differences are not always obvious.
In this paper a purpose-driven approach to the comparison of modelling frameworks is proposed: purpose-driven and not problem-driven, modelling framework comparison and not language comparison. Modelling frameworks have been characterised on the basis of the goals they have been designed to pursue, and on the design choices made to achieve these goals within the framework. The result presented in Section 2 is an instrument with which the purposes and aims behind a framework can be characterised and compared. Section 3 presents the results of the application of the instrument to six modelling frameworks. Section 4 describes the main results of the purpose-driven comparison. The conclusions are presented in Section 5. The specific goals of the individual frameworks are described in the Appendices.

2 PURPOSES BEHIND MODELLING FRAMEWORKS

In (Revise, 1996) a purpose-driven comparison method for (formal) specification languages is proposed. During the analysis of specification languages it became clear that the purposes behind the modelling framework played an important role in the way in which a system is modelled and specified. A modelling framework for knowledge-intensive systems often
  1. supports a methodology for knowledge-intensive system design,
  2. supports more than one phase in the development of knowledge-intensive systems,
  3. supports more than one modelling language, and
  4. provides tools to support modelling and specification.
To design an instrument with which modelling frameworks can be compared, The instrument distinguishes five categories of elements. These five categories, as shown in Figure 1, define:
  1. the characteristics of the methodology behind the modelling framework including levels of specification,
  2. the modelling and specification languages,
  3. the support provided,
  4. the input required to model and specify a knowledge-intensive system, and
  5. the output of a modelling and specification exercise.
Each of these categories are discussed below in more detail.
Fig. 1. Purposes of a modelling framework organised in a hierarchical structure.

2.1 Modelling Approach

Four defining attributes of a modelling approach are distinguished:

2.2 Languages

Within a modelling framework several languages may be used; for example graphical, logical informal, natural languages. Different languages may be used within the same level of specification. For each language, purposes can be identified (based on the (Revise, 1996) purpose driven comparison of formal specification languages) that address:

2.3 Support

The amount of support, either automated or not, differs between different approaches. A number of relevant aspects are:

2.4 Input

A modelling framework captures phenomena: which phenomena are captured depends on the specific modelling framework. The types of input required for system development varies between modelling frameworks.

2.5 Output

Not only specifications of a system can be seen as the `output' of a modelling framework, but also documentation (i.e. description of a specification) and rationale (i.e. describing the modelling choices of a specification). Modelling frameworks differ with respect to the output they produce.

3 EVALUATION OF THE INSTRUMENT

In the previous section a list of purposes is proposed on the basis of which modelling frameworks can be compared. In this section an evaluation of the usability of this instrument is presented.

3.1 Usability of the Instrument

To determine the usability of the instrument three criteria were considered:
  1. the applicability of each purpose,
  2. missing purposes,
  3. the ease with which the purposes of a modelling framework can be expressed.
The usability of the instrument has been analysed on the basis of the application of the instrument to six modelling frameworks. The modelling frameworks chosen are all modelling frameworks originally designed for knowledge intensive domains, modelling frameworks still currently subject of research. The seven modelling frameworks: DESIRE, CommonKADS, PROTÉGÉ-II, MIKE, VITAL, TASK, and RDR are each briefly described below.

DESIRE. A modelling framework within which tasks can be modelled, specified and operationalised, is the DESIRE framework (DEsign and Specification of Interactive REasoning components), presented in Brazier, Treur, Wijngaards and Willems (1995, 1996) and Brazier, Dunin-Keplicz, Jennings and Treur (1995, 1997). An example of an elevator design task model can be found in Brazier, Langen, Treur, Wijngaards and Willems (1996), and an example of a multi-agent system can be found in (Brazier, Dunin-Keplicz, Jennings, and Treur, 1995, 1997).

CommonKADS. The CommonKADS approach is a comprehensive methodology for integrated knowledge-based system development (Wielinga, Schreiber, Breuker, 1992; Hoog, Martil, Wielinga, Taylor, Bright, Velde, 1994). Knowledge-based development is based on the construction of a number of separate models that capture the desired features of the system and its environment. An example of a CommonKADS description can be found in (Schreiber & Terpstra, 1996) in which an elevator configuration task is modelled.

PROTÉGÉ-II. The PROTÉGÉ-II environment is a knowledge-acquisition shell that permits the construction of problem-solving methods using mechanisms as building blocks, modelling application tasks in terms of the constructed methods, generation of knowledge editors based on those task models, and the acquisition of knowledge from such knowledge editors (Musen, 1990; Puerta, Egar, Tu & Musen, 1992; Gennari, Altman, Musen, 1994, Eriksson, Puerta, Gennari, Rothenfluh, Tu & Musen, 1995). In (Rothenfluh, Gennari, Eriksson, Puerta, Tu, and Musen, 1996) an example is given of the application of the PROTÉGÉ architecture to build a knowledge-based system that configures elevators.

MIKE. The MIKE (Model-based and Incremental Knowledge Engineering) approach for the development of knowledge-based systems integrates semiformal specification techniques, formal specification techniques, and prototyping into a coherent framework (Angele, Fensel, Studer, 1996). An example of an elevator design task model can be found in Poeck, Fensel, Landes and Angele (1996).

VITAL. The VITAL (Shadbolt, Motta, Rouge, 1993) approach to structured knowledge-based system development includes a knowledge engineering and a project management methodology. An example of an elevator design task model can be found in Motta, Stutt, Zdrahal, O'Hara, and Shadbolt (1996).

TASK. The TASK modelling framework is designed to support the development of knowledge-based systems from conceptual specification to operationalisation (Pierret-Golbreich, 1993, 1994;Talon and Pierret-Golbreich, 1996b, Pierret and Talon, 1997). An example of partial specifications of the VT task can be found in Talon and Pierret-Golbreich (1996a).

RDR. Ripple-down rules is an approach to building and maintaining knowledge-based systems. The approach is based on test-analysis eliminating the need for knowledge engineering expertise during knowledge acquisition.. RDR has been applied in domains of single- and multiple-classification tasks (Kang, Lee, Kim, Preston and Compton, 1998) and configuration / parametric design (Compton, Ramadan, Preston, Le-Gia, Chellen, Mulholland, Hibbert, Haddad and Kang, 1998). The RDR approach has not been applied to the Sisyphus VT task as the description of that task did not include test cases.

3.2 Results of Analysis of Usability

As an illustration of the obtained results, first the purposes `scope of modelling', `methodology' and the category `levels of specification' are summarized, after which the categories `languages', `support', `input' and `output' are summarised. Finally the application of the comparison instrument is evaluated.

Purpose: scope of modelling. As an example of the obtained results, the purpose `scope of modelling' is highlighted.
 

DESIRE: The problem solving behaviour and task knowledge, domain knowledge, and rationale situated in knowledge intensive domains.
CommonKADS: Knowledge-based systems and their environment.
PROTÉGÉ-II: Domain knowledge and problem solving method together with knowledge-acquisition tools.
MIKE: Reasoning behaviour of experts and the process of knowledge-based system design.
VITAL: Knowledge engineering and project management for application projects.
TASK: Flexible knowledge based systems: problem solving goals, problem solving processes and knowledge.
RDR: Knowledge based systems in specific domains in which expert users and test-cases are available.
As can be seen from this small example of a high level purpose, the modelling frameworks differ in the way in which the scope of modelling is expressed. The common element between the seven modelling frameworks is that all frameworks are designed to support the complete development process of knowledge intensive systems from knowledge acquisition to operationalisation.

Purpose: methodology. The purpose `methodology' is highlighted below:
 

DESIRE: Task model acquisition, specification and refinement, supported by availability of generic task models and partial specifications (at all levels of specification).
CommonKADS: Selection and refinement of available model templates via the CommonKADS Life Cycle Approach.
PROTÉGÉ-II: Construction of domain ontologies, domain independent methods and mapping relations. Generic building blocks exist for all three categories; reuse is an integral part of the methodology.
MIKE: A life cycle approach with the following phases: knowledge acquisition, design, implementation, and evaluation. The phase of design has the sub-phases requirement analysis, model construction and model evaluation. The phase knowledge acquisition has the sub-phases knowledge elicitation, interpretation and structuring, and formalisation.
VITAL: Within the project management the life cycle of an application project is modelled, by specific process products. The life cycle configuration provides a mapping between management phases and the components of the knowledge engineering methodology. Construction of the model of expertise is done by means of General Directive Models (GDM's) (Å rewrite grammar).
TASK: Focuses on modelling flexible knowledge-based systems: problem solving goals, processes and knowledge: a) flexible KBS modelling (dynamic choice or configuration of methods etc.), b) reflective KBS modelling (control vs. object system), c) modelling KBS with hybrid control ( hierarchical and opportunistic ).
RDR: A test-based approach to modelling with several phases: set-up of the system including initial modelling of input and output vocabularies, and maintenance and use of the system by evaluating a system against a test case and adding correction rules to the knowledge base if needed. 
 
Each modelling framework has a methodology, some are more extensive and include more phases than others.

Purpose: levels of specification. The purpose `levels of specification' is highlighted below:
 

DESIRE: Conceptual, detailed, operational and rationale.
CommonKADS: Conceptual, detailed and operational.
PROTÉGÉ-II: Domain independent and domain dependent. The domain dependent level of specification is further divided into specification of ontological knowledge, content knowledge and case data. 
MIKE: Raw, conceptual, detailed, and operational.
VITAL: Conceptual, detailed, operational.
TASK: Conceptual, formal and implementation.
RDR: Domain dependent knowledge. 
 
Most modelling frameworks distinguish several levels of specification, usually at least a conceptual level, more detailed / formal level, and an operational level. PROTÉGÉ-II and RDR differ from the rest, due to their focus on domain knowledge acquisition.

Purposes related to languages. To illustrate similarities and differences among the seven modelling frameworks, their realisations of the purposes related to languages of a modelling framework are abbreviated in Table 1, as shown below:
 

Languages DESIRE COMMONKADS PROTÉGÉ-II MIKE VITAL TASK RDR
Most general level of specification  rationale language  Raw text / video / audio 
Conceptual level of specification  conceptual specification language  CML Model graphical language / OMT  GDM TCML
Detailed / formal level of specification  detailed specification language  (ML)2 Model P-KARL, and L-KARL  Kbssf, OCML  TFL RDR description language 
Operational level of specification  operational language  any language  any language  DesignKarl and any language  any language  any language  any language 
Table 1. Realisations of purposes related to languages of a modelling framework.

All modelling frameworks include a language with which to formally describe a system in detail; the number of conceptual languages and the number of structure-preserving transitions from conceptual languages to detailed languages, varies. All modelling frameworks either have their own operational language, or employ other languages for that goal. Additional languages for other purposes are only provided by MIKE and DESIRE.

Purposes related to support. To illustrate similarities and differences among the seven modelling frameworks, their realisations of the purposes related to support for a modelling framework are abbreviated in Table 2, as shown below:
 

Support DESIRE COMMONKADS PROTÉGÉ-II MIKE VITAL TASK RDR
methodological support  for acquisition, specification and operationalisation, and transition between the above  for acquisition of domain knowledge and life cycle approach of model refinement  for construction of knowledge acquisition tools and PSMs and mapping relations  for entire life-cycle  For entire life-cycle  yes for maintenance of KBSs 
libraries of generic task models  of interpretation models & PSMs  of abstract domain ontologies, domain independent mechanisms and generic mapping relations  of PSMs  for OCML and GDM  current topic of research  not applicable. 
automated tools  editors, verification, prototyping  editors, acquisition, simulation, managing libraries  editors, tool generation, prototyping  editor, verification, prototyping  editors, 
verification, prototyping 		 editors interpreters
Table 2. Realisations of purposes related to support for a modelling framework.

The modelling frameworks do not differ greatly in the kind of methodological support they support. The availability of automated tools for a modelling framework varies more, as does the availability and need for libraries.

Purposes related to input. To illustrate similarities and differences among the seven modelling frameworks, their realisations of the purposes related to input to a modelling framework are abbreviated in Table 3, as shown below:
 

Input DESIRE COMMONKADS PROTÉGÉ-II MIKE VITAL TASK RDR
requirements informal informal n.a. to some extent  to some extent  as preconditions  to some extent 
    dynamic behaviour  yes, including strategies and interaction  yes n.a. yes none yes, including strategies  on possibility and criticality of supervision 
    static behaviour  yes yes n.a. yes yes yes yes
    levels of interaction  all three  object level  none none in specification  none levels: object and strategic preferences  objectlevel
    role delegation  multi-agent systems can be modelled  in agent model  not possible (yet)  no no to some extent  no
problem solving knowledge  modelled  modelled to select a PSM  modelled modelled modelled one underlying PSM 
domain knowledge  modelled modelled modelled modelled modelled modelled modelled
environment in design rationale  in organisation, task, agent, communication and co-operation models  to some extent (current research)  organisational environment is modelled  as organisational requirements  no test cases are modelled in design rationale 
Table 3. Realisations of purposes related to input to a modelling framework.

The following observations can be made regarding to Table 3:

Purposes related to output. To illustrate similarities and differences among the seven modelling frameworks, their realisations of the purposes related to output of a modelling framework are abbreviated in Table 4, as shown below:
 
Output DESIRE COMMONKADS PROTÉGÉ-II MIKE VITAL TASK RDR
Specification Yes - both.  Yes - both.  Yes - both.  Yes - both.  Yes - both.  Yes - both.  Yes - both. 
    requirements 
    specification 		 part of design rationale  only implementation specific  informal scenarios  informal yes yes yes
    systems specification  yes yes yes yes yes yes yes
operationalisation yes, fully executable  yes, partially executable  yes, fully executable  yes, partially executable  yes, fully executable  yes, partially executable  yes, fully executable 
documentation no standards yet  standard forms available  not automatically 
    descriptive not automatically  for all models  yes, to some extent  yes yes yes yes
    rationale current research  yes, to some extent  no yes, to some extent  yes, to some extent.  Current research  yes
Table 4. Realisations of purposes related to output of a modelling framework.

The following observations can be made regarding to Table 4:

Evaluation of usability of the instrument. On the basis of the analysis of the seven modelling frameworks the usability of the instrument can be evaluated on the basis of the three criteria. The following conclusions can be drawn:

4 PURPOSE DRIVEN COMPARISON

The purpose driven comparison method, advocated in this paper, is based on the analysis of the results of the application of the instrument. Analysis of the results for the seven modelling frameworks shows that although shared purposes exist (as could be expected), differences between modelling frameworks are made explicit.
In the table below a number of similarities and differences between the modelling frameworks are listed. An indication is given of how `well' a particular modelling framework supports an aspect, based on the description of their purposes. A "+" should be interpreted as: A "-" should be interpreted as: Note that a "-" does not mean that it is impossible to realise that particular aspect in a particular modelling framework. An example of this is modelling reflective reasoning in CommonKADS: it is possible to model reflective and strategic reasoning by using the REFLECT approach (Harmelen, Wielinga, Bredeweg, Schreiber, Karbach, Reinders, Vo§, Akkermans, Bartsch-Sp[sinvcircumflex]rl and Vinkhuyzen, 1992) which consists of combining KADS-models. However, it is not an intended construction of CommonKADS pur sang, and not often used by practitioners of CommonKADS.
 
Similarities & Differences  DESIRE CommonKADS PROTÉGÉ-II MIKE VITAL TASK RDR
Support for reuse of generic components  + + + + + + -
Based on KADS-I "philosophy"  - + - + + - -
Support for automatic knowledge acquisition  - - + - - - +
Support for representation of raw material  - - - + - - -
Support for project management  - - - - + - -
Support & tools for concurrent processes / agents  + - - - - - -
Tools for modelling environment  - + - + - - -
Reflection & strategic knowledge used in reasoning  + - - - - + -
Formal specification language with formal semantics  + + - + + + +
Hybrid control: reasoning & control  + - - - - + -
Automated prototyping  + - + + - - +
Design rationale  + + - + + + +
Supports multiple problem solving methods  + + + + + + -
Table 1. Similarities and differences according to the realizations of purposes of modelling frameworks.

The results of the comparison of modelling frameworks, based on the purposes for which the frameworks have been designed, can be used to support the selection of a modelling framework. For example, to design a diagnostic reasoning system in a medical domain, for which specific knowledge needs to be acquired for large numbers of physicians, the PROTÉGÉ-II modelling framework provides the most support. If, however, a system is to be designed in which the reasoning behaviour and strategies of two co-operating agents is to be explicitly modelled, the DESIRE framework provides the most support. If the environment of a system is of importance, the CommonKADS and MIKE modelling frameworks provide the most support. Strategical reasoning is supported by both TASK and DESIRE, reflective reasoning is most supported by DESIRE. If, however, many test cases (and expert users) are available the RDR modelling framework may be preferred. In the RDR framework expert users also play an important role in maintaining a knowledge base during run-time. All frameworks provide a form of prototyping, varying from automated prototype generation of the entire detailed specification language to hand-made partial prototyping of parts of the detailed specification language. The way and the extent to which the design rationale is included in the modelling frameworks differs. The support for multiple problem solving methods is common to all modelling frameworks except the RDR modelling framework.

5 CONCLUSIONS

In this paper an instrument for a purpose-driven comparison of modelling frameworks is proposed. This instrument, derived from analysis of existing literature in which languages and frameworks are compared, available hands-on experience, interviews, and input from designers of the different modelling frameworks, distinguishes five categories of purposes. These five categories define: the input required to model and specify a knowledge-intensive system, the output of a modelling and specification exercise, the modelling approach, the modelling and specification languages and the support provided. Within each of these five categories, more specific distinctions are made: The modelling frameworks used to evaluate this instrument (DESIRE, CommonKADS, PROTÉGÉ-II, MIKE, VITAL, TASK, RDR) are all frameworks designed to support the complete development process of knowledge intensive systems from knowledge acquisition to operationalisation. Application of the instrument has made a number of distinctive characteristics of the different approaches explicit, providing a basis for further comparison.

Other comparisons of modelling frameworks, problem-oriented or modelling primitive oriented, can benefit from this purpose-driven comparison. The interpretation of results obtained from other such comparisons (i.e. similarities and differences in e.g. solutions to a problem) can be more focussed if the purposes of the modelling frameworks are explicitly considered.

This instrument can also play a useful role in structuring the reuse and translation of parts of modelling frameworks, application specific models, libraries (e.g. see Motta, 1997), generic structures, etc.

The comparison of frameworks, based on the purposes for which the frameworks have been designed, can be used to support the selection of a modelling framework. The instrument provides a means to structure the comparison. The instrument can also be used as a `shopping list': a shopping list for the knowledge engineer in search of models, tools and methodologies. The knowledge engineer should be able to combine parts of various modelling frameworks into a `new' modelling framework which is most suited to the situation at hand. The instrument would benefit from consensus in the research community on terminology for the description of modelling frameworks - a goal that may one day be reached.

ACKNOWLEDGEMENTS

This research has been (partially) supported by the Dutch Foundation for Knowledge-based systems (SKBS), within the A3 project "An environment for modular knowledge-based systems (based on meta-knowledge) for design tasks" and NWO-SION within project 612-322-316: "Evolutionary design in knowledge-based systems".

Several people have contributed to the descriptions of the purposes behind the different modelling frameworks and on the paper as a whole. Jan Treur and Frank van Harmelen (Vrije Universiteit Amsterdam, DESIRE) commented on previous versions of this paper, Stefan Decker and Michael Erdmann (University of Karlsruhe, Mike) on the description of the MIKE modelling framework, Remco Straatman (University of Amsterdam, CommonKADS) on previous versions of this paper and the description of the CommonKADS modelling framework, Samson Tu (Stanford University, PROTÉGÉ-II) on the description of the PROTÉGÉ-II modelling framework, Enrico Motta (Open University, VITAL) on the decsription of the VITAL modelling framework, the identification of purposes of modelling frameworks and the papers as a whole, Christine Pierret-Golbreich (Universit de Paris-Sud, TASK) on the description of the TASK modelling framework, and Paul Compton and Tim Menzies (University of New South Wales, RDR) on the description of the RDR framework.
Anonymous reviewers provided comments on this paper which led to a number of improvements.

REFERENCES

ABEN, M. (1995). Formal Methods in Knowledge Engineering. PhD thesis, University of Amsterdam, Faculty of Psychology, February 1995, ISBN 90-5470-028-9.
ANGELE, J., DECKER, S., PERKUHN, R. and STUDER, R. (1996). Modelling Problem-Solving Methods in New KARL. In: GAINES, B.R., and MUSEN, M.A. (Eds.), Proceedings of the 10th Banff Knowledge Acquisition for Knowledge-based Systems workshop (KAW'96), Calgary: SRDG Publications, Department of Computer Science, University of Calgary, pages 1/1-1/18.
ANGELE, J., FENSEL, D., and STUDER, D. (1996). Domain and Task Modelling in MIKE. Proceedings of the IFIP WG 8.1/13.2 Joint Working Conference, Domain Knowledge for Interactive System Design. Geneva, Switzerland, May 8-10th, 1996.
ANJEWIERDEN, A., WIELEMAKER, J. and TOUSSAINT, C. (1992). Shelly - computer-aided knowledge engineering. Knowledge Engineering, 4, 1992, pp. 109-125.
BENJAMINS, V.R. (1993). Problem Solving Methods for Diagnosis. PhD thesis, University of Amsterdam.
BRAZIER, F. M. T., TREUR, J., and WIJNGAARDS, N. J. E. (1996b). Interaction with experts: the role of a shared task model. In: WAHLSTER, W. (ed.). Proceedings European Conference on AI (ECAI '96), pp. 241-245. Wiley and Sons, Chichester.
BRAZIER, F.M.T., DUNIN-KEPLICZ, B.M., JENNINGS, N.R. and TREUR, J. (1995) Formal Specification of Multi-Agent Systems: a Real World Case, In: LESSER, V. (Ed.), Proceedings First International Conference on Multi-Agent Systems, ICMAS'95, MIT Press, pp. 25-32.
BRAZIER, F.M.T., DUNIN-KEPLICZ, B.M., JENNINGS, N.R. and TREUR, J. (1997), DESIRE: modelling multi-agent systems in a compositional formal framework, In: HUHNS, M. and SINGH, M. (Eds.), International Journal of Cooperative Information Systems, IJCIS vol. 6 (1), special issue on Formal Methods in Cooperative Information Systems: Multi-Agent Systems, pp. 67-94.
BRAZIER, F.M.T., LANGEN, P.H.G. VAN, and TREUR, J. (1996). Logical theory of design. In: Advances in Formal Design Methods for CAD, J.S. Gero (Ed.), Chapmann & Hall, New York, 1996, pp. 243-266.
BRAZIER, F.M.T., LANGEN, P.H.G. VAN, TREUR, J., WIJNGAARDS, N.J.E. and WILLEMS, M. (1996). Modelling an elevator design task in DESIRE: the VT example. In: SCHREIBER, A.TH., and BIRMINGHAM, W.P. (Eds.), Special Issue on Sisyphus-VT. International Journal of Human-Computer Studies, 1996, 44, pp. 469-520.
BRAZIER, F.M.T., TREUR, J. and WIJNGAARDS, N.J.E. (1996a). The Elicitation of a Shared Task Mode. In: SHADBOLT, N., O'HARA, K., and SCHREIBER, A.TH. Advances in Knowledge Acquisition. 9th European Knowledge Acquisition Workshop, EKAW'96. Lecture Notes in Artificial Intelligence, 1076, pp. 278-289.
BRAZIER, F.M.T., TREUR, J., WIJNGAARDS, N.J.E. and WILLEMS, M. (1996). Temporal semantics and specification of complex tasks. In: GAINES, B.R., and MUSEN, M.A. (Eds.), Proceedings of the 10th Banff Knowledge Acquisition for Knowledge-based Systems workshop (KAW'96), Calgary: SRDG Publications, Department of Computer Science, University of Calgary, pages 15/1-15/17.
BRAZIER, F.M.T., TREUR, J., WIJNGAARDS, N.J.E., and WILLEMS, M. (1995). Formal specification of hierarchically (de)composed tasks. In B.R. Gaines and M.A. Musen (Eds.). Proceedings of the 9th Banff Knowledge Acquisition for Knowledge-Based Systems Workshop, KAW '95, 1995, 2, pp. 25/1-25/20. Calgary: SRDG Publications, Department of Computer Science, University of Calgary.
COMPTON, P., RAMADAN, Z., PRESTON, P., LE-GIA, T., CHELLEN, V., MULHOLLAND, M., HIBBERT, D.B., HADDAD, P.R. and KANG, B. (1998). From Multiple Classification RDR to Configuration RDR. In: KAW-98 proceedings, http://ksi.cpsc.ucalgary.ca/KAW98S/compton
DECKER, S., ERDMANN, M. and STUDER, R. (1996). A Unifying View on Business Process Modelling and Knowledge Engineering. In: GAINES, B.R., and MUSEN, M.A. (Eds.), Proceedings of the 10th Banff Knowledge Acquisition for Knowledge-based Systems workshop (KAW'96), Calgary: SRDG Publications, Department of Computer Science, University of Calgary, pages 34/1-34/16.
DOMINGUE, J., MOTTA, E., and WATT, S. (1993). The Emerging VITAL Workbench. In: AUSSENAC, N., BOY, G., GAINES, B., LINSTER, M., GANASCIA, J.-G., and KODRATOFF, Y. (Eds.) Knowledge Acquisition for Knowledge-Based Systems 7th European Workshop, EKAW'93. Toulouse and Caylus, France, September 1993, pp. 320-339, Springer Verlag.
ERIKSSON, H., PUERTA, A.R., GENNARI, J.H., ROTHENFLUH, T.E., TU, S.W., and MUSEN, M.A. (1995). Custom-Tailored Development Tools for Knowledge-Based Systems. In: GAINES, B.R. and Musen, M.A. (Eds.). Proceedings of the 9th Banff Knowledge Acquisition for Knowledge-Based Systems Workshop, SRDG Publications, Department of Computer Science, University of Calgary, 1995, pp. 26/1-26/19.
FENSEL, D. (1995). The Knowledge Acquisition and Representation Language KARL. Kluwer Academic Publisher, Boston, 1995.
FENSEL, D. and HARMELEN, F. VAN (1994). A comparison of languages which operationalise and formalise KADS models of expertise. The Knowledge Engineering Review, 9, pp. 105-146.
FENSEL, D., ANGELE, J., and STUDER, R. (1994): The Specification Language KARL and Its Declarative Semantics. Research report no. 307, Institut f[Yuml]r Angewandte Informatik und Formale Beschreibungsverfahren, Universit[Sinvcircumflex]t Karlsruhe, August 1994.
FRIDSMA, D.B., GENNARI, J.H., and MUSEN, M.A. (1996). Customizing Work Processes for Organization Models. Technical Report SMI-96-0645. Section on Medical informatics SMI, Department of Medicine, Stanford University School of Medicine. http://www-smi.stanford.edu/pubs/SMI_Abstracts/SMI-96-0645.html /* Published in Proceedings of the CSCW Workshop On Collaborative Modelling and Simulation, É */
GENNARI, J.H., ALTMAN, R.B., and MUSEN, M.A. (1994). Reuse with PROTÉGÉ-II: From Elevators to Ribosomes. Knowledge systems laboratory, KSL-94-71, Stanford University School of Medicine, 1994.
GREEF, H.P. DE, and BREUKER, A.J. (1992). Analysing system-user cooperation in KADS. Knowledge Acquisition, 4, 1992, pp. 89-108.
HARMELEN, F. VAN, and BALDER, J. (1992). (ML)2: A formal language for KADS models of expertise. Knowledge Acquisition, 4, 1992, pp. 127-161.
HARMELEN, F. VAN, LOPEZ DE M[daggerdbl]NTARAS, R., MALEC, J., and TREUR, J. (1993). Comparing Formal Specification Languages for Complex Reasoning Systems. In: (Treur & Wetter, 1993), pp. 257-282.
HARMELEN, F. VAN, WIELINGA, B., BREDEWEG, B., SCHREIBER, G., KARBACH, W., REINDERS, M., VO§, A., AKKERMANS, H., BARTSCH-SP[sinvcircumflex]RL, B., and VINKHUYZEN, E. (1992). Knowledge-Level Reflection. In: LE PAPE, B. and STEELS, L. (Eds.)Enhancing the Knowledge Engineering Process -- Contributions from ESPRIT. Elsevier Science, Amsterdam, The Netherlands, pp. 175-204.
HOOG, R. DE, MARTIL, R., WIELINGA, B.J., TAYLOR, R., BRIGHT, C., AND VELDE, W. VAN DE (1994). The CommonKADS model set. Technical Report KADS-II/M1/DM1.1b/UvA/018/6.0/FINAL, SWI, University of Amsterdam, 1994.
KANG, B.H., LEE, K., KIM, W., PRESTON, P. and COMPTON, P. (1998). Evaluation of Multiple Classification Ripple Down Rules. In: KAW-98 proceedings, http://ksi.cpsc.ucalgary.ca/KAW98S/kang
LANDES, D. (1994): DesignKARL - A Language for the Design of Knowledge-Based Systems. In: Proceedings of the 6th International Conference on Software Engineering and Knowledge Engineering SEKE'94 (Jurmala, Latvia, June 20-23), 1994, 78-85. Also available as research report no. 296, Institut f[Yuml]r Angewandte Informatik und Formale Beschreibungsverfahren, Universit[Sinvcircumflex]t Karlsruhe, April 1994.
LINSTER, M. (1991). Sisyphus'91 part 2: Models of problem solving. Statement of the sample problem. In: SMEED, D., LINSTER, M., BOOSE, J.H., and GAINES, B.R. (Eds.). Proceedings of the EKAW'91, Glasgow, University of Strathclyde.
LINSTER, M. (1994). Sisyphus '91/92: Models of problem solving. International Journal of Human-Computer Studies, 40, 1994, pp. 189-192.
MARCUS, S. and MCDERMOTT, J. (1989). SALT: A knowledge acquisition language for propose-and-revise systems. Artificial Intelligence, 39, 1-37.
MARCUS, S., STOUT, J., and MCDERMOTT, J. (1988). VT: an expert elevator designer that uses knowledge-directed backtracking. AI Magazine, 9, 95-112.
MAZZA, C., FAIRCLOUGH, J., MELTON, B., PABLO, D. DE, SCHEFFER, A., and STEVENS, R. (1994). Software Engineering Standards. Prentice Hall.
MENZIES, J.T. and MAHIDADIA, A. (1997). Ripple-down rationality: a framework for maintaining PSMs. In: Workshop on problem-solving methods for knowledge-based systems, IJCAJ'97.
MOTTA, E. (1995). KBS modelling in OCML. Proceedings on the Workshop on Modelling Languages for KBS. Vrije Universiteit Amsterdam, The Netherlands, January.
MOTTA, E. (1997). A comparative analysis of modelling frameworks. Working paper. Knowledge Media Institute, The Open University.
MOTTA, E., STUTT, A., ZDRAHAL, Z., O'HARA, K. and SHADBOLT, N. (1996). Solving VT in VITAL: a study in model construction and knowledge reuse. In: SCHREIBER, A.TH., and BIRMINGHAM, W.P. (Eds.), Special Issue on Sisyphus-VT. International Journal of Human-Computer Studies, 1996, 44, pp. 333-371.
MUSEN, M.A. (1990). An editor for the conceptual models of interactive knowledge-acquisition tools. In: BOOSE, J.H. and GAINES, B.R. (Eds.). The Foundations of Knowledge Acquisition. Knowledge-Based Systems, Academic Press Limited, 4, 1990, pp. 135-160.
PIERRET-GOLBREICH, C. (1993). Task Model Perspective of Knowledge Engineering, 7th European Knowledge Acquisition Workshop, EKAW'93, Springer-Verlag.
PIERRET-GOLBREICH, C. (1994). Task Model, a framework for the design of Models of Expertise and their operationalization. In B.R. Gaines and M.A. Musen (Eds.). Proceedings of the 8th Banff Knowledge Acquisition for Knowledge-Based Systems Workshop, KAW '95, 1994, 2, pp. 37/1-37/22. Calgary: SRDG Publications, Department of Computer Science, University of Calgary.
PIERRET-GOLBREICH, C., and TALON, X. (1996). TFL, an algebraic language to specify the dynamic behaviour of knowledge-based systems. The Knowledge Engineering Review, Vol. 11: 3, Cambridge Press, pp. 253-280.
PIERRET-GOLBREICH, C., and TALON, X. (1997). Specification of Flexible Knowledge-Based Systems. In: PLAZA, E. and BENJAMINS, R. (Eds.). Knowledge acuiqisiton, modeling and management, Proceedings of the 10th European Workshop, EKAW'97, Springer Berlin, pp. 190-204.
PIERRET-GOLBREICH, C., HUGONNARD, E., and TONG, X. (1993). KAM: Knowledge Acquisition Modelling. Machine Learning and Knowledge Acquisition Workshop of 13 th International Joint Conference on Artificial Intelligence IJCAI'93, TECUCI , G., KEDAR S., KODRATOFF Y. (Eds.), Chambery.
POECK, K., FENSEL, D., LANDES, D. and ANGELE, J. (1996). Combining KARL and CRLM for designing vertical transportation systems. In: SCHREIBER, A.TH., and BIRMINGHAM, W.P. (Eds.), Special Issue on Sisyphus-VT. International Journal of Human-Computer Studies, 1996, 44, pp. 435-467.
PUERTA, A.R., EGAR, J.W., TU, S.W., and MUSEN, M.A. (1992). A multiple-method knowledge-acquisition shell for the automatic generation of knowledge-acquisition tools. Knowledge Acquisition, 1992, 4, pp. 171-196.
REVISE (project) (1996). A Purpose Driven Method for Language Comparison. In: SHADBOLT, N., O'HARA, K., and SCHREIBER, A.TH. Advances in Knowledge Acquisition. 9th European Knowledge Acquisition Workshop, EKAW'96. Lecture Notes in Artificial Intelligence, 1076, pp. 66 - 81.
RICHARDS, D., and COMPTON, P. (1997). Knowledge acquisition first, knowledge modelling later. In: PLAZA E. and BENJAMINS, R. (Eds.). Proceedings of the Knowledge Acquisition, Modelling and Management workshop EKAW'97, Berlin, Springer-Verlag, pp. 237-252.
ROTHENFLUH, T.E., GENNARI, J.H., ERIKSSON, H., PUERTA, A.R., TU, S.W. and MUSEN, M.A. (1996). Reusable ontologies, knowledge-acquisition tool, and performance systems: PROTÉGÉ-II solutions to Sisyphus-2. In: SCHREIBER, A.TH., and BIRMINGHAM, W.P. (Eds.), Special Issue on Sisyphus-VT. International Journal of Human-Computer Studies, 1996, 44, pp. 303-332.
SAGE, A.P. and PALMER, J.D. (1990). Software Systems Engineering. John Wiley and Sons.
SCHREIBER, A.TH., and BIRMINGHAM, W.P. (1996). Editorial: the Sisyphus-VT initiative. International Journal of Human-Computer Studies, 44, 1996, pp. 275-280.
SCHREIBER, A.TH., and TERPSTRA, P. (1996). Sisyphus-VT: A CommonKADS solution. In: SCHREIBER, A.TH., and BIRMINGHAM, W.P. (Eds.), Special Issue on Sisyphus-VT. International Journal of Human-Computer Studies, 1996, 44, pp. 303-332.
SCHREIBER, A.TH., WIELINGA, B.J., AKKERMANS, H., VELDE, W. VAN DE, and ANJEWIERDEN, A. (1994). CML: The CommonKADS Conceptual Modelling Language. In: STEELS, L., SCHREIBER, A.TH, and VELDE, W. VAN DE (Eds.), "A future for knowledge acquisition," Proceedings of the 8th European Knowledge Acquisition Workshop, EKAW '94. Springer-Verlag, Lecture Notes in Artificial Intelligence 867, pp. 283-300.
SCHREIBER, A.TH., WIELINGA, B.J., AKKERMANS, J.M., VELDE, W. VAN DE, and HOOG, R. de (1994). CommonKADS: A comprehensive methodology for KBS development. IEEE Expert, 9(6), December 1994.
SHADBOLT, N., MOTTA, E., and ROUGE, A. (1993). Constructing Knowledge-Based Systems. IEEE Software, November, pp. 34-38.
SISYPHUS_III (1996). In: "http://ksi.cpsc.ucalgary.cs/KAW"
TALON, X. and PIERRET-GOLBREICH, C. (1996a). TASK, a framework for the different steps of a KBS construction. 6th European Workshop on Knowledge Engineering Methods and Languages, KEML'96, Gif sur Yvette.
TALON, X. and PIERRET-GOLBREICH, C. (1996b). TASK: from the specification to the implementation. 8th IEEE International Conference on Tools with Artificial Intelligence, pp. 80-88, IEEE Computer Society Press.
TALON, X., and PIERRET-GOLBREICH, C. (1997). A language to specify strategies for flexible problem-solving, 7th Knowledge Engineering Methods and Languages Workshop, KEML'97, England.
TREUR, J. and WETTER, TH (Eds.) (1993). Formal Specification of Complex Reasoning Systems. Ellis Horwood.
WIELINGA, B.J., SCHREIBER, A.TH., and BREUKER, J.A. (1992). KADS: a modelling approach to knowledge engineering. Knowledge Acquisition, 4, 1992, pp. 5-53.
YOST, G.R. AND ROTHENFLUH, T.R. (1996). Configuring elevator systems. In: SCHREIBER, A.TH., AND BIRMINGHAM, W.P. (Eds.), Special Issue on Sisyphus-VT. International Journal of Human-Computer Studies, 1996, 44, pp. 521-568.

APPENDICES

The appendices can be found on the web pages of this paper in the proceedings of the KAW'98 conference. This includes a description of the realisations of the purposes of the following modelling frameworks:

APPENDICES

In this these appendices a number of modelling frameworks are described. For each of these modelling frameworks their realizations of the purposes are described.

A MODELLING FRAMEWORK Desire

A modelling framework within which tasks can be modelled, specified and operationalised, is the DESIRE framework (DEsign and Specification of Interactive REasoning components), presented in Brazier, Treur, Wijngaards and Willems (1995, 1996) and Brazier, Dunin-Keplicz, Jennings and Treur (1995, 1997). An example of an elevator design task model can be found in Brazier, Langen, Treur, Wijngaards and Willems (1996), an example of a multi-agent system can be found in (Brazier, Dunin-Keplicz, Jennings, and Treur, 1995, 1997). The purposes described in the previous chapter are presented in the next sections for the DESIRE framework.

A.1 Modelling Approach

The purposes related to the modelling approach within the DESIRE modelling framework are described in the tables below.
 
scope of modelling  The problem solving behaviour and task knowledge, domain knowledge, and rationale situated in knowledge intensive domains. 
methodology Task model acquisition, specification and refinement, supported by availability of generic task models and partial specifications (at all levels of specification). 
levels of specification  Conceptual, detailed, operational and rationale: 
 
 
Level of specification  Conceptual
types of knowledge  Five types: task composition, information exchange, task sequencing, identification knowledge structures, role delegation. 
major structuring concepts  Task and knowledge composition, object/meta/É distinctions. 
relation to other levels of specification  This is the highest level of specification; has a structure preserving relation with the detailed level of specification. 
relation to languages  A graphical conceptual specification language is used to specify conceptual task models. 
semantics Semi-formal semantics: temporal semantics for tasks, partial order-sorted predicate logic for information states and knowledge bases. 
 
 
Level of specification  Detailed
types of knowledge  Five types: task composition, information exchange, task sequencing, identification knowledge structures, role delegation. 
major structuring concepts  Task and knowledge composition, object/meta/É distinctions. 
relation to other levels of specification  Structure preserving refinement of the conceptual level of specification. 
relation to languages  A detailed specification language is used to specify models at this level of specification. 
semantics Temporal semantics for tasks, partial order-sorted predicate logic for information states and knowledge bases. 
 
 
Level of specification  Operational
types of knowledge  Detailed level of specification. 
major structuring concepts  Task and knowledge composition. 
relation to other levels of specification  A structure preserving operationalisation of the detailed level of specification. 
relation to languages  In the current environment, Prolog and C are used to operationalise (and execute) a detailed specification. 
semantics
 
 
Level of specification  Rationale 
(This level of specification is currently under development.) 
types of knowledge  Requirements, assumptions, environment, modelling strategies, É 
major structuring concepts  Task and knowledge composition. 
relation to other levels of specification  Design decisions taken in, or between, the conceptual, detailed and operational level of specification are captured in this level of specification. 
relation to languages  A rationale specification language is used to specify the design rationale. 
semantics A rationale is given for the conceptual and detailed specification. 

A.2 Languages

Within the DESIRE modelling framework several languages are used. The purposes related to these languages are described in the tables below.
 
Language Conceptual specification language 
scope of specification  Conceptual reflective (knowledge-based) compositional architecture. 
paradigm Graphical and textual representation of task structures and knowledge structures. 
structuring principles  Task and knowledge composition, information hiding, interactivity, reusability. 
types of knowledge  Five types: task composition, information exchange, task sequencing, knowledge structures, role delegation. 
dynamics Functional and behavioural properties are both specified, interactivity at all three levels of interaction: object-level interaction, interaction at the level of strategic preferences and interaction at the level of task modification (see Brazier, Treur, Wijngaards, 1996a, 1996b). 
semantics Semi-formal semantics, temporal semantics for tasks, partial valued order sorted predicate logic for information states and knowledge bases. 
reusability Entire and partial conceptual task models, generic specifications (with respect to domain and task). 
executability Yes (by means of detailed specification language). 
 
 
Language Detailed specification language 
scope of specification  Reflective (knowledge-based) compositional architecture. 
paradigm Declarative compositional representation of task structures and knowledge structures. 
structuring principles  Task and knowledge composition, information hiding, interactivity, reusability. 
types of knowledge  Five types: task composition, information exchange, task sequencing, knowledge structures, role delegation. 
dynamics Functional and behavioural properties are both specified. 
semantics Temporal semantics for tasks, partial valued order sorted predicate logic for information states and knowledge bases. 
reusability Entire and partial specifications, generic specifications (with respect to domain and task). 
executability Yes.
 
 
Language Operationalisation language 
scope of specification  Formal specifications. 
paradigm Logic programming and procedural. 
structuring principles  Task and knowledge composition. 
types of knowledge  Formal specification. 
dynamics As defined by the temporal semantics for tasks. 
semantics The semantics of Prolog and C. 
reusability None.
executability Yes.
 
 
Language Rationale language  
(The language for rationale specification is currently being developed.) 
scope of specification  Design rationale behind task models in conceptual and detailed level of specification; rationale for both process description of design and resulting (conceptual) task models. 
paradigm Both task- and knowledge-composition oriented, and (design) process oriented. 
structuring principles  Conceptual and detailed task model, task and knowledge composition, object/meta/É distinctions. 
types of knowledge  Requirements, (generic) task models, assumptions, É 
dynamics For the current task models a rationale is provided, as well as a description of the design process (which arrived at the current rationale description). 
semantics As prescribed by the logical theory of design (Brazier, van Langen & Treur, 1996 ). 
reusability Currently not. 
executability Within the context of (re)design, the rationale is `executable'. 

A.3 Support

The DESIRE modelling framework provides support in various areas. The purposes related to support are described in the table below.
 
methodological support  Methodological support is available for the acquisition, specification and operationalisation of task models. Transitions between levels of specification are precisely described and can be made automatically. 
libraries Library of generic task models. 
automated tools  Graphical (task model) editor, automatic verification, automatic prototype generation & execution. 

A.4 Input

Within the DESIRE framework various types of information are used to design task models. The purposes related to input to the modelling framework are described in the table below.
 
requirements (In informal notation.) 
dynamic behaviour  Requirements can be formulated in terms of the behaviour of the systems; with respect to dynamics of information in the system and with respect to interactivity of the system. 
static behaviour  Requirements can be formulated in terms of the functionality of the systems. 
levels of interaction  Requirements can be formulated in terms of all three levels of interaction. 
role delegation  Requirements can be formulated in terms of agents and their capabilities. 
problem solving knowledge  Plays an integral part of the design of task models. 
domain knowledge  Plays an integral part of the design of task models. 
environment Parts of the environment are modelled when needed in the design rationale. 

A.5 Output

The purposes related to the output of the DESIRE modelling framework are described in the table below.
 
specification (Both kinds of specification are produced.) 
requirements specification  The informal specification of the current requirements is part of the design rationale, which is produced as well. 
systems specification  Specification of reflective (knowledge-based) compositional architecture (multi-agent or single-agent). 
operationalisation Yes (automatically generated), fully executable (for both sequential and parallel control). 
documentation
descriptive No automatic documentation is generated yet; no standards have been defined. 
rationale Currently under development, a description of the current specification plus a description of the design process. 

B MODELLING FRAMEWORK COMMONKads

The CommonKADS approach is a comprehensive methodology for integrated knowledge-based system development (Wielinga, Schreiber, Breuker, 1992; Hoog, Martil, Wielinga, Taylor, Bright, Velde, 1994). Knowledge-based development is envisioned a the construction of a number of separate models that capture salient features of the system and its environment. System-user cooperation has been analysed in (Greef & Breuker, 1992) resulting in the cooperation model.
An example of a CommonKADS description can be found in (Schreiber & Terpstra, 1996) where an elevator configuration task is modelled. The purposes described in chapter 2 are presented in the next sections for the CommonKADS framework.

B.1 Modelling Approach

The purposes concerned with the modelling approach within the CommonKADS modelling framework are described below.
 
scope of modelling  Knowledge-based systems and their environment (also known as the CommonKADS product). 
methodology Selection and filling of available model templates via the CommonKADS Life Cycle Approach. 
levels of specification  Conceptual, detailed and operational. 
 
 
Level of specification  Conceptual
types of knowledge  Expertise model: domain models, inferences, problem solving methods. 
major structuring concepts  Domain, inference and task layer. 
relation to other levels of specification  Structured informal representation of the expertise of an agent. 
relation to languages  Conceptual Modelling Language (CML). 
semantics Structured informal description of the problem-solving method of an agent. 
 
 
Level of specification  Detailed
types of knowledge  Expertise model: domain models, inferences, problem solving methods, and explicit mapping between domain and inference layer. 
major structuring concepts  Domain, inference and task layer. 
relation to other levels of specification  Formal description of the expertise of an agent (from the agent model), refers to and preserves structures defined at the conceptual level of specification. 
relation to languages  The formal specification language[1] 
 
(ML)2. 
semantics Formal description of the problem-solving method of an agent. 
 
 
Level of specification  Operational
types of knowledge  Design model: application design model, architecture design model and platform design model. 
major structuring concepts  Specifications and models. 
relation to other levels of specification  Operationalisation of detailed level of specification. 
relation to languages  Program definition language, i.e. any programming language can be used. 
semantics The specified knowledge-based system, together with design decisions, is operationalised on a particular platform. 

B.2 Languages

Within the CommonKADS modelling framework several languages are used, e.g. CML (Schreiber, Wielinga, Akkermans, Velde, Anjewierden, 1994) and (ML)2 (Harmelen & Balder, 1992). The purposes related to these languages are described below.
 
Language Conceptual modelling language (CML) 
scope of specification  Expertise models and ontologies. 
paradigm Graphical and textual representation, Object Modelling Technique, procedural. 
structuring principles  Domain / inference / task knowledge. Within the domain knowledge: ontologies, ontology mappings and domain models. Within the inference knowledge: inferences and roles. Within the task knowledge: task composition. 
types of knowledge  Ontologies, ontology mappings, domain models, roles, inferences, task composition. 
dynamics Functional and behavioural properties are informally specified. 
semantics Structured informal (static and dynamic) semantics of problem solving method within expertise models; structured informal semantics of concepts and relations among concepts. 
reusability Yes: generic ontologies, inference structures and problem solving methods exist. 
executability A CML simulator exists, which executes expertise models when Prolog clauses are defined in bodies of inference structures. 
 
 
Language Formal specification language (ML)2 
scope of specification  Domain layer, inference layer and task layer and mapping between them. 
paradigm Three-layer description. 
structuring principles  Domain layer, inference layer, and task layer; inference composition and task composition. 
types of knowledge  Domain knowledge, inference steps, tasks and methods. 
dynamics Order-sorted logic layer, meta-logic layer, and dynamic-logic layer. 
semantics Dynamic logic (regular programs). 
reusability No support for generic structures. 
executability A sublanguage of (ML)2 is executable. 

B.3 Support

The CommonKADS modelling framework provides support in various areas. The purposes related to support are described below.
 
methodological support  Methodological support is available for the acquisition of domain knowledge and life cycle approach of model refinement (Schreiber, Wielinga, Akkermans, Velde, and Hoog, 1994). 
libraries A library of interpretation models is available as well a libraries of problem solving methods (e.g. Benjamins, 1993) and ontologies. 
automated tools  The Shelly workbench supports activities in the KBS life cycle (Anjewierden, Wielemaker, and Toussaint, 1992), and an interactive tool is available for specification and simulation of both CML and (ML)2: Si(ML)2 (Aben, 1995). VOID is an interactive environment for browsing, editing and managing (libraries of) ontologies. 

B.4 Input

Within the CommonKADS framework various types of information are used to design task models. The purposes related to input to the modelling framework are described below.
 
requirements (In informal notation described in the organisation, task, agent, communication and cooperation models.) 
dynamic behaviour  Is also partly described in the design model. 
static behaviour  Is also partly described in the design model. 
levels of interaction  System-user cooperation is modelled within the cooperation model. No interaction at the level of strategic preferences or task modification. 
role delegation  Agents are modelled in the agent model. 
problem solving knowledge  Plays an integral part in the design of the inference and task layer in the expertise model. 
domain knowledge  Plays an integral part in the design of the domain layer in the expertise model. 
environment Is extensively modelled by means of organisation, task, agent, communication, and cooperation models. 

B.5 Output

The purposes related to the output of the CommonKADS modelling framework are described below.
 
specification (Both kinds of specification are produced.) 
requirements specification  Only implementation specific requirements are incorporated in the design model. 
systems specification  These aspects are incorporated in the design model. 
operationalisation The formal specification is not entirely executable, the resulting implementation is executable. 
documentation Standard documentation forms are prescribed with which the various models are described. 
descriptive Standard documentation forms are used to describe all models in detail. 
rationale Design decisions are documented in the design model and in the first phase of the life cycle (e.g. risk analysis). 

C MODELLING FRAMEWORK PROTÉGÉ-II

The PROTÉGÉ-II environment is based on the PROTÉGÉ environment, developed in the late eighties. The PROTÉGÉ-II environment is a knowledge-acquisition shell that provides a task-modelling environment for knowledge engineers and a knowledge-editing environment for application experts. The shell is independent of methods, tasks and domains (in contrast to the first version). PROTÉGÉ-II allows the definition of knowledge roles at the knowledge level for both domain-dependent and domain-independent knowledge. This shell permits the construction of problem-solving methods using mechanisms as building blocks, the modelling of application tasks in terms of the constructed methods, the generation of knowledge editors based on those task models, and the acquisition of knowledge from such knowledge editors (Musen, 1990; Puerta, Egar, Tu & Musen, 1992; Gennari, Altman, Musen, 1994, Eriksson, Puerta, Gennari, Rothenfluh, Tu & Musen, 1995).
In (Rothenfluh, Gennari, Eriksson, Puerta, Tu, and Musen, 1996) an example is given of the application of the PROTÉGÉ architecture to build a knowledge-based system that configures elevators. The purposes described in chapter 2 are presented in the next sections for the PROTÉGÉ-II framework.

C.1 Modelling Approach

The purposes concerned with the modelling approach within the PROTÉGÉ-II modelling framework are described below.
 
scope of modelling  Domain knowledge and problem solving method together with knowledge-acquisition tools. 
methodology Theories exist on how to build domain ontologies, domain independent methods and mapping relations. Generic building blocks exist for all three categories; reuse is an integral part of the methodology. 
levels of specification  Domain independent and domain dependent. The domain dependent level of specification can be further structured into specification of ontological knowledge, content knowledge and case data. 
 
 
Level of specification  Domain independent 
types of knowledge  Method ontology and (reusable) problem solving methods. 
major structuring concepts  Tasks, methods, and mechanisms. 
relation to other levels of specification  Via mapping relations a connection is made with domain dependent knowledge. 
relation to languages  Currently MODEL is used, although a proposal is made to save ontologies and content knowledge in terms of Peter Karp's Generic Frame Protocol[2] 
 
.
semantics No formal semantics for PSMs. MODEL can be seen as a restricted subset of Ontolingua (classes are seen sets of individuals). 
 
 
Level of specification  Domain dependent ontological knowledge 
types of knowledge  Detailed models of concepts in application domains (e.g., clinical protocols) and terminological knowledge. 
major structuring concepts  Is-a, part-of hierarchies, terms, relations, constraints. 
relation to other levels of specification  Via mapping relations a connection is made to a (domain independent) problem solving method. 
relation to languages  MODEL as the ontology specification language. 
semantics Ontological knowledge on concepts and terminological knowledge in the domain. 
 
 
Level of specification  Domain dependent content knowledge 
types of knowledge  Detailed knowledge about the domain. 
major structuring concepts  Is-a, part-of hierarchies, terms, relations, constraints. 
relation to other levels of specification  Instances of ontological knowledge, acquired through knowledge acquisition tools based on ontological knowledge. Mapped to method ontology in problem-solving process. 
relation to languages  MODEL instances. 
semantics Universe of discourse is described in general terms / knowledge so that it remains potentially applicable to problem-solving goals. 
 
 
Level of specification  Domain dependent case data 
types of knowledge  Contingent facts about particular problem-solving situations. 
major structuring concepts  Is-a, part-of hierarchies, terms, relations, constraints. 
relation to other levels of specification  Instances of ontological knowledge. Acquired externally, e.g., through databases. 
relation to languages  MODEL instances. 
semantics A particular problem-solving situation is described. 

C.2 Languages

Within the PROTÉGÉ-II modelling framework several languages are used. Individual applications adopt different extensions of the language MODEL. The purposes related to the language MODEL are described below.
 
Language MODEL
scope of specification  Ontologies.
paradigm Frame-like representation language that uses is-a hierarchies and is derived from the CLIPS object language COOL (similar to object-oriented modelling). MODEL has both extensions and restrictions of COOL. 
structuring principles  Class hierarchies. 
types of knowledge  Classes, slots, and slot properties. 
dynamics No interactivity. 
semantics MODEL is a subset of ONTOLINGUA. 
reusability Reusability is a key concept; libraries of ontologies are used. 
executability Directly executable in CLIPS. 

C.3 Support

The PROTÉGÉ-II modelling framework provides support in various areas. The purposes related to support are described below.
 
methodological support  Methodological support is available for the construction of tools for Domain knowledge acquisition; construction of problem solving methods, and mapping relations. 
libraries Libraries of abstract domain ontologies, domain-independent mechanisms, and generic mapping relations. 
automated tools  A set of development tools; emphasis on generation of tools for knowledge acquisition. The tools are integrated into the PROTÉGÉ-II system: "Ontology Editor" (domain and application ontology editor), "Layout Editor" (domain-specific knowledge-acquisition tool specification generator), "Layout Interpreter" (generates functional knowledge-acquisition tool), MARBLE (support for defining mapping relations), and a CLIPS run-time system. 

C.4 Input

Within the PROTÉGÉ-II framework various types of information are used to design task models. The purposes related to input to the modelling framework are described below.
 
requirements (No real support in PROTÉGÉ-II[3] 
 
.)
dynamic behaviour  Unknown.
static behaviour  Unknown.
levels of interaction  None.
role delegation  Only one system is specified, no interactivity is possible (yet). 
problem solving knowledge  Plays a role in the selection of a problem solving method. 
domain knowledge  Plays an integral part in the design of the domain ontology and KA-tools. 
environment A new direction in PROTÉGÉ-II is explicit modelling of organisations' work processes and adaptation of content knowledge to the local characteristics of sites where an application is to be deployed [Fridsma, Gennari, and Musen, 1996]. 

C.5 Output

The realisations of the purposes related to the output of the PROTÉGÉ-II modelling framework are described below.
 
specification (Both kinds of specification are produced.) 
requirements specification  Informal scenarios are generated. 
systems specification  Specification of an application is produced (in CLIPS code). 
operationalisation Yes.
documentation (No documentation is automatically generated.) 
descriptive The domain-specific KA tool can be seen as a documentation viewer. In this sense, the specification is the documentation. 
rationale No.

D MODELLING FRAMEWORK Mike

The MIKE (Model-based and Incremental Knowledge Engineering) approach for the development of knowledge-based systems integrates semiformal specification techniques, formal specification techniques, and prototyping into a coherent framework (Angele, Fensel, Studer, 1996). An example of an elevator design task model can be found in Poeck, Fensel, Landes and Angele (1996). The purposes described in chapter 2 are presented in the next sections for the MIKE framework.

D.1 Modelling Approach

The purposes concerned with the modelling approach within the MIKE modelling framework are described below.
 
scope of modelling  Modelling of reasoning behaviour of experts and the process of knowledge-based system design. 
methodology A life cycle approach is taken with the following phases: knowledge acquisition, design, implementation, and evaluation. The phase of design has the subphases requirement analysis, model construction and model evaluation. The phase knowledge acquisition has the subphases knowledge elicitation, interpretation and structuring, and formalisation. 
levels of specification  Raw, conceptual, detailed, and operational. 
 
 
Level of specification  Raw
types of knowledge  The elicitation model involves protocols and hypermedia representations of (raw) knowledge elicited from experts. 
major structuring concepts  Protocol nodes and protocol order links, and protocol refinement links. 
relation to other levels of specification  This is the highest level of specification; it is interpreted to arrive at the structure model (see below). 
relation to languages  Pure text, raw media, É 
semantics Informal semantics, is related to the knowledge and expertise of experts. 
 
 
Level of specification  Conceptual
types of knowledge  The structure model (including the documentation model), which includes dynamic and static knowledge (ontology, problem solving method). 
major structuring concepts  For static knowledge: concepts, links (e.g. is-a links, part-of links, causes-links). For dynamic knowledge: task decomposition, data-flow (inference structure), control flow. 
relation to other levels of specification  The structure model provides a semiformal description of the knowledge in the elicitation model. 
relation to languages  A graphical representation language is used: OMT in the near future. 
semantics Semi-formal semantics of problem solving method. 
 
 
Level of specification  Detailed
types of knowledge  The model of expertise (which includes ontologies, rules, task decomposition, control knowledge, mappings). 
major structuring concepts  Domain layer, task layer, inference layer. 
relation to other levels of specification  The structure of the conceptual level is preserved. 
relation to languages  For the task layer P(rocedural)-KARL is used, for the domain and inference layer L(ogical)-KARL is used. 
semantics Formal semantics (dependent on the language) of statics and dynamics of knowledge based systems and expertise. 
 
 
Level of specification  Operational
types of knowledge  This includes the design model and implementation. 
major structuring concepts  Data types, algorithms and modules. 
relation to other levels of specification  The design model maintains a structure preserving description of the detailed level of specification. The implementation may differ, as documented in the design model. 
relation to languages  DesignKARL and an operationalisation language. 
semantics The static and dynamic functionality of the model of expertise is operationalised. 

D.2 Languages

Within the MIKE modelling framework several languages are used. The Knowledge Acquisition and Representation Language NewKARL (Angele, Decker, Perkuhn, and Studer, 1996), successor of KARL (Fensel, Angele, Studer, 1994; Fensel, 1995), and a specific language for the design of knowledge-based systems[4] is described by Landes (1994) are examples of this. The purposes related to these languages are described below.
 
Language Graphical representation language 
scope of specification  Common Basis for Expert and Knowledge Engineer, first structuring of the problem domain. 
paradigm OMT with one extension: processes are taken as objects. 
structuring principles  Subclasses, aggregation, events, dataflow. 
types of knowledge  Static and dynamic (control and data flow). 
dynamics Yes.
semantics The formal semantics of OMT. 
reusability Not mentioned in available literature. 
executability No.
 
 
Language NewKARL 
(The successor of the executable formal specification language KARL.) 
scope of specification  Model of expertise: domain layer, inference layer and task layer. 
paradigm Three-layer description (Logical-KARL for domain and inference layer, Procedural-KARL for task layer). 
structuring principles  In L-KARL: class hierarchies, conditions, roles, inferences, mappings. In P-KARL: `control' modelling primitives and inference actions. 
types of knowledge  In L-KARL: Domain knowledge, inferences, mappings; in P-KARL task knowledge. 
dynamics L-KARL: first-order Horn logic with stratified negation. P-KARL: dynamic-logic. 
semantics A combination of the semantics of L-KARL and P-KARL (Fensel, 1995). L-KARL has model-theoretical semantics. P-KARL has also a model-theoretic semantics, based on dynamic logic. 
reusability Yes, a library of problem solving methods exists. 
executability Yes (by means of constructive semantics and an optimised evaluation strategy). 
 
 
Language DesignKARL
scope of specification  Design model and implementation, design decisions and underlying rationale. 
paradigm Both model-of-expertise oriented, (design) process oriented, and implementation oriented. 
structuring principles  In addition to KARL, symbol level and knowledge level distinctions. 
types of knowledge  In addition to KARL, data types, algorithms, modules, and design rationale / process. 
dynamics The transition from a formal (and executable) specification of the reasoning behaviour to its implementation. 
semantics Same as formal semantics of NewKARL, no formal semantics for design artefacts. 
reusability Not explicitly supported. 
executability Yes, by reduction to NewKARL. 

D.3 Support

The MIKE modelling framework provides support in various areas. The purposes related to support are described below.
 
methodological support  The entire knowledge engineering life cycle of a KBS is supported, from elicitation towards implementation. 
libraries There is a library of problem-solving methods. 
automated tools  The graphical MIKE tool provides support for building structure model from the elicitation model, and the transition from the structure model to the model of expertise. For the operationalisation of expertise model there is an interpreter for NewKARL and the model of expertise is animated in the graphical MIKE tool. An evaluation tool is available, the so called evaluator, which evaluates the structure model by stepping through the tasks and subtasks. 

D.4 Input

Within the MIKE framework various types of information are used to build the various models. The purposes related to input to the modelling framework are described below.
 
requirements (Within the structure model and the design model.) 
dynamic behaviour  In the design model requirements can be formulated in terms of the behaviour of the KBS. 
static behaviour  Requirements can be formulated in terms of the functionality of the systems. 
levels of interaction  None, it is `hardwired' into the implementation. 
role delegation  None.
problem solving knowledge  Is part of the protocols in the elicitation model. 
domain knowledge  Plays an integral part in the design of the domain layer in the expertise model. 
environment The organisational environment of the KBS may be modelled by several views (Decker, Erdmann, Studer, 1996). 

D.5 Output

The realisations of the purposes related to the output of the MIKE modelling framework are described below.
 
specification (Both kinds of specification are produced.) 
requirements specification  The informal specification of the current requirements is part of the design rationale, which is produced as well. 
systems specification  Specification of knowledge-based system. 
operationalisation Yes, although some inference actions are modelled within the MIKE-tool as pure text, so not automatically generated executables. 
documentation
descriptive The documentation model contains nodes explaining any other nodes of the elicitation-, structure-, or expertise model. 
rationale A part of the rationale is provided by the design model. 

E MODELLING FRAMEWORK Vital

The VITAL (Shadbolt, Motta, Rouge, 1993) approach to structured knowledge-based system development includes a knowledge engineering and a project management methodology. An example of an elevator design task model can be found in Motta, Stutt, Zdrahal, O'Hara, and Shadbolt (1996). The purposes described in chapter 2 are presented in the next sections for the VITAL framework.

E.1 Modelling Approach

The purposes concerned with the modelling approach within the VITAL modelling framework are described below.
 
scope of modelling  Knowledge engineering and project management for application projects. 
methodology Within the project management the life cycle of an application project is modelled, by specific process products. The life cycle configuration provides a mapping between management phases and the components of the knowledge engineering methodology. Construction of the model of expertise is done by means of General Directive Models (GDM's) (Å rewrite grammar). 
levels of specification  Conceptual, detailed, operational. 
 
 
Level of specification  Conceptual
types of knowledge  Domain and problem solving characterisation (Å Model of Expertise without control). 
major structuring concepts  Roles, inference steps. 
relation to other levels of specification  This is the most general level of specification. 
relation to languages  GDM supports a simple rewrite-rule type notation. Moreover, GDM models can be populated by using either a simple frame-based representation or first-order logic. 
semantics Informal semantics of problem solving method and domain knowledge. 
 
 
Level of specification  Detailed
types of knowledge  The model of expertise, including control knowledge. 
major structuring concepts  Domain layer, task layer, inference layer. 
relation to other levels of specification  The structure of the conceptual level is preserved. 
relation to languages  KbsSF (only formalisation) or OCML (formalisation and operationalisation). 
semantics Formal semantics (dependent on the language) of statics and dynamics of knowledge based system. 
 
 
Level of specification  Operational 
The work on technical design was never really completed in the VITAL project, there is an internal report which has never become an external VITAL deliverable. 
types of knowledge  Functional design model (FDM), and technical design model (TDM). 
major structuring concepts  This is not clear from available literature. 
relation to other levels of specification  Operational description of detailed specification. Whether this is structure preserving or not is not clear from available literature. 
relation to languages  It is not clear from available literature which languages are used for FDM and TDM, and any implementation language. 
semantics Implementation independent and dependent description of the target KBS. 

E.2 Languages

Within the VITAL modelling framework several languages are used. The purposes related to these languages are described below. The language OCML (Motta, 1995) is described below.
 
Language OCML 
(The successor of the informal language CML.) 
scope of specification  Model of expertise: domain layer, inference layer and task layer; and ontologies. 
paradigm Graphical and textual representation, procedural. 
structuring principles  Ontologies, tasks (and inferences), roles, functions, relations, rules, classes, instances. 
types of knowledge  Inferences, static roles, dynamic roles, data-flow, control-flow; ontology mappings, ontologies; mapping between domain and problem solving model. 
dynamics Functional and behavioural properties are specified. 
semantics Operational: there are three interpreters: Prolog-based theorem prover, function interpreter, and control interpreter. The function interpreter and the theorem prover are integrated (i.e. functional can be called from within proofs and proofs can be invoked from functions). inheritance system is also integrated with the Prolog-based theorem prover. 
Formal: there is no formal semantics for control language. The semantics of functions, relations, rules, classes, and instances is given in terms of the corresponding ontolingua constructs. 
reusability There is a library of reusable components. These are divided into five categories: basic, tasks, method, domain, and application. Basic is the base ontology (lists, numbers, strings, etc.). Domain are domain models (e.g. Sisyphus I). Methods are PSMs (e.g. propose & revise). Tasks are generic tasks (e.g. parametric design). Applications combine task/ methods/ domain mapping and application-specific knowledge. 
executability Yes.

E.3 Support

The VITAL modelling framework provides support in various areas. The purposes related to support are described below.
 
methodological support  The entire knowledge engineering life cycle of a KBS is supported, from requirements specification to implementation. 
libraries There are OCML libraries and GDM libraries. 
automated tools  The VITAL workbench (Domingue, Motta, and Watt, 1993) comprises several tools The tool management tool VITAL tower enables the usage of tools in VITAL, such as requirements specification assistant, design assistant, analysis assistant, and implementation assistant. Also a visualisation-based approach is available for validation and verification of models. 

E.4 Input

Within the VITAL framework various types of information are used to build the various models. The purposes related to input to the modelling framework are described below.
 
requirements (The requirement specification stuff was essentially traditional software engineering.) 
dynamic behaviour  None.
static behaviour  Requirements can be formulated in terms of the functionality of the systems. 
levels of interaction  It is unclear from available literature whether interaction can be modelled at all, and which levels of interaction are modelled. 
role delegation  Not treated in any depth. 
problem solving knowledge  Is captured in the conceptual and detailed specification. 
domain knowledge  Plays an integral part in the design of the domain layer in the conceptual and detailed level of specification. 
environment The organisational requirements capture the environment of the KBS (it is not clear from available literature whether the organisational requirements are related to the process of developing the KBS). 

E.5 Output

The realisations of the purposes related to the output of the VITAL modelling framework are described below.
 
specification
requirements specification  Is produced as part of the requirements specification document. 
systems specification  Is produced as part of the design models and executable code documents. 
operationalisation Yes if OCML is used (of course is the executable code document executable). 
documentation
descriptive The conceptual model and design models documents. 
rationale A part of the rationale is provided by the requirements specification and the technical design model (part of the design models document). 

F MODELLING FRAMEWORK Task

The TASK modelling framework is designed to support the development of knowledge-based systems from conceptual specification to operationalisation (Pierret-Golbreich, 1993, 1994; Pierret-Golbreich, Hugonnard, and Tong, 1993; Pierret-Golbreich, and Talon, 1996, Talon and Pierret-Golbreich, 1996b, Talon and Pierret-Golbreich, 1997). An example of partial specifications of the VT task can be found in (Talon and Pierret-Golbreich, 1996a).The purposes described in chapter 2 are presented in the next sections for the Task framework.

F.1 Modelling Approach

The purposes concerned with the modelling approach within the TASK modelling framework are described below.
 
scope of modelling  flexible knowledge-based systems: problem solving goals, processes and knowledge: 
- flexible KBS modelling (dynamic choice or configuration of methods etc.). 
- reflective KBS modelling (control vs. object system) 
- modelling KBS with hybrid control ( hierarchical and opportunistic ) 
methodology Task model oriented modelling, task centered representation (computational architecture), knowledge oriented acquisition method 
levels of specification  Conceptual, formal and implementation 
 
 
Level of specification  Conceptual
types of knowledge  domain knowledge, assertional knowledge; problem solving; strategical knowledge 
major structuring concepts  modularisation, distinction control vs. object system 
relation to other levels of specification  first stage in modelling 
relation to languages  TCML supported by a semi-graphic tool 
semantics n.a.
 
 
Level of specification  Formal
types of knowledge  domain knowledge, inferences, composed-processes, tasks & strategies, control knowledge 
major structuring concepts  modularisation, object encapsulation 
relation to other levels of specification  second stage in modelling, structure preserving translation of conceptual design 
relation to languages  TFL
semantics denotational semantics based on PLUSS algebraic specification language ADT 
 
 
Level of specification  Implementation
types of knowledge  object classes for each modelling primitive e.g.; problem, process, inference, task-module, strategy, focus, (information, domain-model, rule for the domain) etc. 
major structuring concepts  modularisation, distinction control vs. object system 
relation to other levels of specification  third stage in modelling, structure preserving translation of formal design 
relation to languages  partial translation of PLUSS specifications is possible 
semantics

F.2 Languages

Within the Task modelling framework several languages are used. The purposes related to these languages are described below.
 
Language TCML
scope of specification  informal specification of model of expertise at knowledge level 
paradigm semi-graphical and textual representation of knowledge 
structuring principles  functional view, categorisation of interrelated knowledge, modularisation, hybrid control 
types of knowledge  Domain knowledge, assertional knowledge, problem-solving knowledge, strategic knowledge 
dynamics Strategic knowledge 
semantics syntactical definition only 
reusability Modelling primitives (knowledge structures), primitive and composed processes, task modules 
executability none
 
 
Language TFL
scope of specification  static and dynamic behaviour of knowledge based systems 
paradigm formal algebraic language 
structuring principles  functional view, categorisation of interrelated knowledge, modularisation, hybrid control 
types of knowledge  domain knowledge, inferences, composed processes, tasks and strategies, control knowledge 
dynamics Strategic and control knowledge 
semantics denotational semantics based on PLUSS algebraic specification language for each process: static semantics and dynamic semantics 
reusability Process modules 
executability partial translation of PLUSS specifications is possible 

F.3 Support

The TASK modelling framework provides support in various areas. The purposes related to support are described below.
 
methodological support  Methodological support is available, translation between levels of specification are structure preserving and well-defined 
libraries current topic of research 
automated tools  Graphical support for conceptualisation, Editors, KAM 

F.4 Input

Within the TASK framework various types of information are used to build the various models. The purposes related to input to the modelling framework are described below.
 
requirements preconditions
dynamic behaviour  problem solving knowledge and problem solving strategies 
static behaviour  preconditions can be imposed on domain knowledge, and problem solving knowledge and problem solving strategies 
levels of interaction  object and strategical preferences 
role delegation  Agents (task modules) are designed to perform specific tasks 
problem solving knowledge  plays an integral part in design of models 
domain knowledge  plays an integral part in design of models 
environment n.a.

F.5 Output

The realisations of the purposes related to the output of the TASK modelling framework are described below.
 
specification both requirement and systems specifications are available 
requirements specification  formal description of requirements 
systems specification  formal description of object system and control 
operationalisation semi automatically 
documentation
descriptive formal specifications 
rationale current focus of research (assumptions) 

G MODELLING FRAMEWORK RDR

Ripple-down rules is an approach to building and maintaining knowledge-based systems. The approach is based on test-analysis eliminating the need for knowledge engineering expertise during knowledge acquisition. Expert users maintain the knowledge within a knowledge-base themselves. RDR has been applied in domains of single- and multiple-classification tasks (Kang, Lee, Kim, Preston and Compton, 1998), configuration / parametric design (Compton, Ramadan, Preston, Le-Gia, Chellen, Mulholland, Hibbert, Haddad and Kang, 1998), and other domains. One interesting application is described in (Richards and Compton, 1997) to employ RDR to acquire and present knowledge while utilising appropriate PSMs to use the knowledge. Another use of RDR for maintaining PSMs is described by (Menzies and Mahidadia, 1997).
Basic characteristics of the RDR approach are (1) a mapping is constructed between input and output, without any iterations within the mapping, and (2) knowledge is never revised, but only extended upon. The RDR approach has not been applied to the Sisyphus VT task as the description of that task did not include test cases.
The purposes described in chapter 2 are presented in the next sections for the RDR framework.

G.1 Modelling Approach

The purposes concerned with the modelling approach within the RDR modelling framework are described below.
 
scope of modelling  Knowledge based systems in specific domains in which expert users and test-cases, are available. 
methodology Several phases are distinguished: set-up of the system including initial modelling of input and output vocabularies, and maintenance and use of the system by evaluating a system against a test case and adding correction rules to the knowledge base if needed. 
levels of specification  domain dependent knowledge: direct analysis of of attributes found in concrete examples 
 
 
Level of specification  domain dependent knowledge 
types of knowledge  domain knowledge. 
major structuring concepts  rules and tree-structures (of rules) 
relation to other levels of specification  not applicable. 
relation to languages  RDR description language 
semantics decision lists: formal semantics of domain knowledge and rationale of construction of that domain knowledge. 

G.2 Languages

Within the RDR modelling framework one language is used. The purposes related to this language are described below. The RDR description language is described below.
 
Language RDR description language 
scope of specification  knowledge-based systems which map input to output via non-iterative rule sets. 
paradigm logical description of domain knowledge and relationships between knowledge rules. 
structuring principles  rules and cases. 
types of knowledge  domain knowledge. 
dynamics functional relationship between input and output is specified. 
semantics labelled logics 
reusability Yes within a domain of application (i.e. extending a KBS), not across domains of applications. 
executability Yes.

G.3 Support

The RDR modelling framework provides support in various areas. The purposes related to support are described below.
 
Methodological support  Methodological support is available for maintenance of KBSs. 
Libraries not needed. 
automated tools  Interpreters are available. 

G.4 Input

Within the RDR framework various types of information are used to build the various models. The purposes related to input to the modelling framework are described below.
 
requirements To some extent. 
dynamic behaviour  Performance requirements can be specified (concerning possibility and criticality of supervision) 
static behaviour  Requirements on input and output can be specified. 
levels of interaction  object level interaction. 
role delegation  no.
problem solving knowledge  The underlying problem solving method is currently being researched. 
domain knowledge  Extensively included, mainly added by expert users themselves. 
environment Supports exception-driven patching of rules. 

G.5 Output

The realisations of the purposes related to the output of the RDR modelling framework are described below.
 
specification Both are produced. 
requirements specification  yes.
systems specification  Yes.
operationalisation Yes.
documentation
descriptive Yes.
rationale Rationale of maintenance to the knowledge base is constructed during maintenance. 
[*]

 This title is not entirely original: it is based on the paper "A Purpose Driven Method for Language Comparison" (REVISE, 1996), in which a method for the comparison of formal specification languages was proposed. A shorter version of this paper is published in the Proceedings of the 10 European Workshop on Knowledge Acquisition Modelling and Management (EKAW'97) published by Springer Verlag in the Lecture Notes of Artificial Intelligence, Volume 1319.

[**] Current address: Knowledge Science Institute, Department of Computer Science, University of Calgary, 2500 University Drive NW, Calgary, Alberta, T2N 1N4 Canada, E-mail: niek@cpsc.ucalgary.ca

[1] Other languages include: MOMO, KARL, OCML (Fensel and Harmelen, 1994). (ML)2, however, is developed by the same group that developed CommonKADS and is explained in the next section.

[2] See http://www.ai.sri.com/~gfp/ for more information on the Generic Frame Protocol.

[3] According to Samson Tu, in the PROTÉGÉ lab, there is a tradition of generating requirements through the construction of scenarios.

[4] NewKARL is already partial executable, but it is a specification language. To further refine NewKARL-code to the needs of an implementation environment the language DesignKARL was developed.
 

Page generated by Niek Wijngaards, February 28th, 1998.