- Email: [email protected]
AN INTELLIGENT TUTORING SYSTEM BASED ON A DOMAIN ONTOLOGY FOR THE DESIGN OF LEAD-LAG CONTROLLERS
AN INTELLIGENT TUTORING SYSTEM BASED ON A DOMAIN ONTOLOGY FOR THE DESIGN OF LEAD-LAG CONTROLLERS Isaías García1, Carmen Benavides1, José R. Villar2, Francisco Rodríguez1, Héctor Aláiz1 and Ángel Alonso1 1
[isaias.garcia, carmen.benavides, diefrs, hmoreton, dieaaa]@unileon.es Systems Engineering and Control Group Dept. of Electrical and Electronic Engineering, University of León Edificio Tecnológico, Campus de Vegazana s/n, 24071 León (SPAIN) 2 [[email protected]] Computer Science and Artificial Intelligence Group Dept. of Computer Science Edificio departamental 1, Campus de Viesques s/n, 33204 Gijón, Asturias (SPAIN)
Abstract: The modeling of domains is today a technique with growing acceptance into the software community. Domain models allow the information to be represented in the computer at higher abstraction levels than in the usual applications, so improving the human to machine and machine to machine interactions. This paper deals with the application of such modeling paradigm to the control engineering education field, showing how the knowledge of this domain can be represented in a conceptual structure called ontology which is used as the base for building an Intelligent Tutoring System, a software tool used in the emerging field of e-learning. Keywords: Intelligent Tutoring Systems, ontologies, conceptual modeling, control engineering education.
1.
INTRODUCTION
Computers have been used for training and education since their very invention. Several properties of the computer have been exploited with this aim: the capacity of performing very fast numerical calculus, the ability of representing multimedia data, its high level of availability and during the last years, because of the advent of the Internet, the possibility of ubiquitous access to huge amounts of information, the possibility of building and using remote laboratories and applications, the use of collaborative spaces for distance learning, and the plethora of different technologies that help doing so. All these characteristics have given raise to the growing field of research known as e-learning. Today, e-learning is concerned about applying the Information Technologies to the whole learning
process, and so it is worried about how computers may be applied to the methods, processes and objects present in this field. One of the key issues is to find ways in which the software applications may capture the knowledge involved in the definition and implementation of the tasks and activities that are present in learning and tutoring, including the resources and the agents participating in these processes. The common solution to build the kind of applications previously mentioned founds in the modeling paradigm for software design and development that is maturing in the Software Engineering and in the Knowledge Engineering fields (Miller and Mukerji, 2003). Ontologies (Gruber, 1993) are the conceptual artifacts that have shown to be the right ones in order to capture, store and reuse the model of the knowledge of a domain
(the so-called conceptual model, conceptual structure or, simply, the conceptualization of the domain). Stating the knowledge of a domain in a conceptual structure such as an ontology allows for the semantics of the domain to be captured into a software application and transmitted to the human, improving the machine to human interaction. As a paradigmatic example from the control education field, one can realize that the significance of the techniques for manually sketching the root locus has been diminished by the use of computers and applications like Matlab, that can draw accurate plots very fast. While this is with no doubt an advance, there is also a side effect: the disconnection of the student using Matlab from the concepts underlying the root locus plot. This is not an isolated fact, it also occurs in the industry, where the more and more complex software used in automation isolates the human from the plant or process, being this a potential source of problems and also of discouraging for plant operators. These problems occur because the software applications being used generate a semantic gap between the user and the meaning of the data, that is, the meaning of what is happening inside the software. To fill this semantic gap applications should incorporate data represented at a higher abstraction level and this can be accomplished by using the mentioned conceptual models of the domain. The more knowledge the computer is able to manage, the better the human-computer and computer-computer interaction. This paper tries to apply these modeling techniques to the field of control engineering education by building a domain model of the subject matter to be taught and representing it in an ontology. This model is then used to build an Intelligent Tutoring System, a software application coming from the Artificial Intelligence field that plays a central role in elearning. While a complete Intelligent Tutoring System usually has some other models on it (see section 3), the work presented here is only concerned about the conceptual model of the subject matter being learned (that is, a given subdomain of control engineering). The paper is organized as follows: in section 2 a brief review of ontologies compared to other modeling techniques is done, section 3 introduces the field of Artificial Intelligence for Education and the use of ontologies in Intelligent Tutoring Systems, in section 4 an outline of the ontology is presented in order to show how a conceptual model for a design task in control engineering may be built and used, next, in section 5 the application developed (the ITS) is briefly described and last, in section 6, some conclusions are given.
2.
MODELING DOMAINS BY MEANS OF ONTOLOGIES
An ontology can be defined as a specification of a knowledge model that can be reused in different applications where the described knowledge applies (Gruber, 1993). Some authors stress the need for the ontology of having a community that commits to the representation it stores but, purely speaking, one can build a knowledge model without consensus, being a different issue its later degree of usability and success. Ontologies were born in the Artificial Intelligence and Knowledge Engineering field but are being adopted in the more traditional Software Engineering area because it offers advantages over the usual modeling paradigms found there like, for example, the Unified Modeling Language (UML) tools and techniques. In particular, the model found in an ontology differs from the knowledge found in an UML model in the fact that the ontology model is built to be used in the application as a crucial part of the software while the models built with UML are used in design time for representing the problem and the software project itself. Further, an ontology is able of representing much richer knowledge structures than UML tools are. Ontologies are being used in several fields of application (see (Lancieri et. al., 2005) or (DARPA, 2006)) for a detailed list) and are seen now as a key data structure for the knowledge management in the organizations, just like databases have been during many years (and still are). Figure 1 represents the ontology field and some of its related concepts and applications (taken from Mizoguchi, 2006). As can be seen, education is one of the most important and direct applications of ontologies.
Knowledge-level Communication Education
KM
Theory Of Ontology
Knowledge Systematization
Semantic Web
HCI
Figure 1. Ontology-Related Concepts and Applications Building an ontology is a modeling process, a knowledge modeling process. This field is not so mature as to have well defined, standard methodologies (though (Poli, 2002) and (Pinto and Martins, 2004) can be cited as some approaches that have been proposed) and so only good practices and partial methodologies adopted in part from the Software Engineering field are available. In general,
an ontology is built upon two main structures (for a deeper discussion of these structures see (Musen., 1998)): • The static structure, comprising the concepts found in the domain and the relations among these concepts. • The dynamic structure, comprising the tasks used in the domain to solve the problems.
3.
INTELLIGENT TUTORING SYSTEMS
The field of research on Intelligent Tutoring Systems (ITS) or, in a broader sense, the so-called Artificial Intelligence for Education (AIED) field (Wenger, 1987) has some years of experience on the study of computers applied to educational software. The studies have evolved along the time, trying to find the best ways to describe the learning process from every point of view: from the one of the student, the tutor, the subject matter being learned and also the learning process itself. Today ITS are built from different knowledge models that represent those points of view, and also the agents and processes found in the field. These domain models are more and more usually stored in ontologies (Kasai et. al., 2005), (Psyché et. al., 2005). It is remarkable to realize that the tendencies today about ITS are building the better models as possible for the knowledge implied in the learning process while the emphasis some years ago was more focused on the study of the form of the learning process rather than in the content itself (Breuker et. al., 1999).
4.
OUTLINE OF THE ONTOLOGY
First, a subdomain within control engineering has been chosen to be modeled. This subdomain is the lead-lag compensator design with techniques from the classical control theory (mostly with the root locus techniques). There are several reasons to choose this domain: First, this domain has huge amounts of semantics in its core (much more than is found in the modern control theory, for example); second, the methods used to get a design involve several and different reasoning types (this poses a challenge when trying to build the model but the more complex a domain is, the more benefits are obtained later from this model); and third, it is a wellknown field with lots of bibliographical data describing the processes. This section deals with the conceptualization of the knowledge found in the subdomain, describing the ways in which the knowledge model has been built and giving some examples of the structures that form the ontology. The in-depth description and discussion of the ontology would need much more space and is out of the scope of this paper. Only simplified
examples are presented as a way of seeing how the model is built and used. The section has been divided into two parts, resembling the static and dynamic structure that constitutes an ontology.
4.1 The static structure of the ontology The static structure, as introduced in section 2, is comprised of the concepts and relations of the domain. It has been built by using bibliographic data, interviews with experts in the field and also by introspection (because the authors can also be seen as experts in the domain). As an example, concepts used in this field may be signal flux graph, point, polynomial, root, pole, percent overshoot, etc. All these concepts have been arranged into different hierarchies in order to show the relations that hold among them. Relations may vary from the wellknown “is-a” inheritance relation to more complex ones like parthood, composition, connection, causality, etc. This way, several hierarchies of concepts could be obtained by just changing the focus on the relationship to be inspected. The concepts along with the relations among them form a complex networked structure of knowledge that build up the static structure of the ontology. In figure 2 the concept PolynomialRoot appears in two different networks where the links mean different relations. In figure 2a the traditional is-a relation is shown with the meaning “PolynomialRoot is a MathematicalConcept that is a Concept that (eventually) is a Thing” (Thing represents here the topmost concept in the is-a hierarchy). Figure 2b also has the same PolynomialRoot concept but appearing in a different relation network that could have a kind of “parthood”, “has associated” or “is composed of” meaning; this way, the branch could read “A TransferFunctionSystemModel has an associated PolynomialQuotient that has associated a (denominator)Polynomial that has associated a RootsAndGainDescription description that has associated a collection of Root that has associated a PolynomialRoot”. TransferFunctionSystemModel
Thing PolynomialQuotient
Concept (Denominator)Polynomial
MathematicalConcept
SystemCharacteristic
GraphicalRepresentation
(Numerator)Polynomial RootsAndGainDescription
PolynomialRoot (Collection of) Root
Gain
PolynomialRoot
Fig 2a
Fig 2b
Figure 2. Two Networks of Relations The static structure of the ontolgy is crucial to the system in order to being able of answering basic
questions of the type “what is this?” and also more complicated ones like “why (has something happened in the application)?” using causal relations, or to infer new knowledge using the existing one. As well as building this network of concepts and relations an ontology also contains the representation of rules or logic clauses by means of which new knowledge may be inferred from existing one. For example, the next rule states that when any pole of a system is located on the right half-plane the system is unstable: If A Pole isLocated on RighHalfPlane Then The System (representedBy the TransferFunctionSystemModel that has associated the PolynomialQuotient that has associated the (Denominator)Polynomial that has associated the RootsAndGainDescription that has associated the collectionOfRoots that has associated the PolynomialRoot that stands for the Pole) is unstable
This rule has been written in almost natural language and in a simplified manner in order to show the basic structure and also how the network of concepts shown in figure 2b is used to relate the pole (the root of a polynomial) to the system that is represented with a denominator having this root. All this representation, that seems so straight for humans, needs to be explicitly stated in the ontology in order the application can give explanations about what is occurring at runtime. Note that the assigning of instability to the system is very loosely stated in the rule. This has been intentionally done in order to put the attention to the rule as a whole. Stability is in fact one of the characteristics that may be represented to describe a system’s behaviour and has its place in the corresponding networks that describe quantitative and qualitative characteristics, the functions that may be used to calculate their values, the relations among them, etc. It must also be pointed out that the previous rule is one that express well-known knowledge for a well-defined fact but there are also heuristic knowledge in the domain as is for example the case of the reasoning about the position in the real axis that the zero of a lead controller should have. This previous example also serves as a way of showing how some kind of simple explanation may be obtained. Say that some design decision has lead to the whole system to present instability and this fact has been notified by putting some red flag somewhere in the user’s graphical interface. The user will see something like “the system is unstable with this design”. Then she could ask “why?” and an explanation would be generated based on the structure of the rule (or set of rules if the reasoning used is more complex). For example, the first answer to the mentioned question could be simply “because
there are poles of the system in the right-half plane”, then the user could ask for further information, for example, the system could show which pole/s is/are in the right-half plane, but could even tell the user what a pole is or how the roots of a polynomial are calculated. This kind of interactivity is what make ontology-based Intelligent Tutoring Systems so attractive for the learning of concepts in a complex domain. In fact, the system could also give explanations not only about why some design decisions must be taken but also about why other must not.
4.2. The dynamic structure of the ontology. Modeling the design task The dynamic structure of the knowledge in the ontology represents the tasks used to solve the problems pertaining to that domain. In this case it is clear that the main task could be named as “design”. So making the dynamic conceptual structure of the ontology is making the modeling of the design task in control engineering. In order to give explanations the system must have a complete and explicit representation of this task and all the subtasks that are involved on it. It is worth noting that this model of the task can be used (and is used indeed) not only to being able to explain the design process but also to automate the execution of the task in the computer. For this purpose, the so-called Generic Task or Problem Solving Methods (Musen, 1998) field of research is an active area devoted to find and develop general and reusable libraries of code that can implement the tasks models captured in the ontologies. In order to find the model for the design process as is carried out in control engineering, attention must be paid to similar approaches made and applied to different domains because the task itself is the same across domains if we abstract the details. Several studies have been devoted to the conceptual study of the task of design, and to identify the kind of domain knowledge needed before and during the problem resolution (Ahmed and Wallace, 2006). From all the studies that have been done, the socalled parametric design problem solving (Motta and Zdrahal, 1996), (Wielinga et. al., 1995), (Teije et. al., 2004) are the ones that most resemble the design of controllers in control engineering. Parametric design is assumed to be the correct model for a given task when the solution to a configuration design problem may be modeled as an artifact with a series of parameters whose values are to be found according to the given requirements, constraints and optimization criterions. This way, the lead-lag controller design task may be approximated and so modeled by means of the parametric design approach because the elements described may be easily mapped to the ones that appear in this control engineering task: The
artifact to be built is the controller, the parameters to be found may well be the pole and zero positions and the gain values, the requirements are the performance requirements for the controlled system (both transient and steady state), the constraints can be thought of as the physical limitations to build the designed controller (say values of resistances, capacitors, etc, for an electronic network realization of the controller design) and finally optimization criterion may be mapped to cost constraints, for example. Based on the studies about parametric design problem solving, a model of the task of design of controllers has been built. In this model, some additions have been introduced in order to represent some facts that are solely found in some engineering areas like the one of control engineering. As an example, one of these additions is based on the need of representing the kind of mathematical model by means of which the design is carried out and also the process of validation of this design on more realistic models of the system. This is because control engineering design with the classical control theory uses algebraic models of the systems that are further simplified in order to be able to ease the reasoning process and permit some kind of analytical studies, but this has the disadvantage that the designed solution must be tested in the models that don’t present simplifications, thus probably making the design process an iterative one. 4.3 Outline of the obtained model of the design Parametric design problem solving is basically a matter of finding the optimal solution within a given solution space that can be generated. In order to reduce the number of possible solutions some kind of heuristic knowledge is usually applied for narrowing this space. In the domain of controller design, one example would be the possible values for the real axis coordinate of the zero in a lead controller. While this parameter may take an infinity number of values some heuristics may be applied based on physical limitations, the position of the open-loop poles and zeros, the shape of the root locus, the design requirements, etc. Usually these heuristics may be expressed by means of a rule just like the one presented in the previous section and so this rule structure has been adopted as the basic decision structure for the modeling of the design task. The flexibility for the expressivity to be implemented in the rule’s general expression is found by seeing how the heuristics use to be stated. One of the most difficult issues faced in this step was the need of modeling different kinds of graphical reasoning and representing the qualitative concepts used when talking about the relative position of the different elements in a root locus.
5.
OUTLINE OF THE APPLICATION
Once the static and the dynamic models were constructed, the ITS application was built. This application also serves to validate the knowledge models obtained because the best way of validating the knowledge in the system is letting it interact with the user giving explanations of the design process and answering questions that the user poses, this way exposing the underlying knowledge. The flow of the execution of the program is as follows: First, the data about the problem is introduced, then it is turn to introduce the performance requirements (by means of the required characteristics in the transient and steady state portions of the time response of the system). Finally, a series of constraints for the controller are also introduced (in this first version only the type of controller can be introduced but in future versions also cost constraints are planned). Once the initial data are introduced, the system finds the better (with all the limitations that the system may present) solution to the problem and exposes to the user a graphical interface where she can see all the design steps and pose questions about any intermediate design achieved. As was seen when talking about the design task modeling, the design process in this application is carried out by the computer and not by the user. The user is able to ask for any of the design steps or any of the intermediate reasonings produced because all the steps are stored in the ontology using the concepts in the model. This may be seen as an odd behaviour for a tutoring system but it was done this way because one of the key issues when trying to explain a process is finding a model of it and this is what was pursued. In a future development the intervention of the user at any point of the design will be permitted and so the application could offer explanations about the user’s activities as well as giving advise about the proper design step to be accomplished if the user prefers let the system to perform it. The applications is written in Java and the ontology has been built with the tool Protégé, an open-source, flexible ontology editor tool that provides a complete Java API to access the structure and the data in the ontology. The dynamic structure of the ontology is putted into work by means of an ad-oc Java parser, while a translation of these structures into jess rules is also being studied in order to use the built-in jess rule engine (Friedman-Hill, 2006). 5.1 Verification and validation of the results Results obtained so far are being tested and studied by the creators of the software. No “general user“ experiences are available at the moment. Training cases are being introduced and used to test the
performance of the system. These training cases must be carefully selected as to expose all the reasoning and modeling characteristics that the system possesses. No techniques are mature today to test the validity or completeness of an ontological structure. The approaches used are based on the so-called “competence questions”, that is, a set of test queries posed to the system in order to compare the answers obtained to what would be the correct ones, covering all the expected functionalities. Results are being obtained as text output at the moment, though a graphical interface is being developed that will allow a much richer interaction with the system. 6.
CONCLUSIONS AND FUTURE WORK
An application has been built that shows the use of knowledge modeling techniques to build computer applications used for training and education in the control engineering field. In this paper it has been pointed out the possibility for a computer system with an explicit knowledge representation of being able of giving explanations to the user about the application’s internal processes and reasonings. Results so far are promising and may be a good experience in face of the “semantic revolution” that is spreading over many application areas in the software community. Future work will be directed both to find patterns for using and parsing ontologies and to extend the control engineering domain studied to cover the frequency domain techniques, PID controller design methods, etc. REFERENCES Ahmed, S. and Wallace, K. (2006) Reusing Design Knowledge. Advances in Design. H. A. ElMaraghy and W. ElMaraghy, SpringerVerlag Breuker, J., Muntjewerff, A., and Bredewej, B. (1999). Ontological modelling for designing Educational systems. In Proceedings of the AIED 99 Workshop on Ontologies for Educational Systems, Le Mans, France. IOS Press DARPA (Defense Advanced Research Projects Agency) (2006), DAML ontology repository, Available online (link checked on Jan, 26, 2006) [http://www.daml.org/ontologies/] Friedman-Hill E. (2006) "Jess: the Java Expert System Shell", Sandia National Laboratories, (link checked on 12th, May, 2006) [http://herzberg.ca.sandia.gov/jess/] Gruber, T. (1993) A translation approach to portable ontology specifications. Knowledge Adquisition, 5, pp. 199-220 Kasai, T.; Yamaguchi, H.; Nagano, K.; Mizoguchi, R. (2005) Goal Transition Model and Its
Application for Supporting Teachers based on Ontologies in Proc. of the 12th Artificial Intelligence in Education (AIED2005), pp. 330-337, Amsterdam, The Netherlands Lancieri, L. (coordinator); Maynard, D.; Gandon, F. (2005) Success Stories and Best Practices, Knowledgeweb deliverable 1.4.2, Available online (link checked on Jan, 26, 2006) [http://www.knowledgeweb.semanticweb.org/s emanticportal/home.jsp?_origin=%2Fhome.js p&instance=D1.4.2%3A+Success+Stories+a nd+Best+Practices&ontology=Documentatio n+Ontology&content=instance.jsp&instance_ set=kweb&var_name=instance] Miller, J.; Mukerji, J. (eds.) (2003) OMG Driven Architecture (MDA) guide. Available online (link checked on Jan, 26, 2006) [http://www.omg.org/docs/omg/03-06-01.pdf] Mizoguchi, R. (2006) ; Website of Mizoguchi Lab; Available online (link checked on Jan, 26, 2006) [http://www.ei.sanken.osakau.ac.jp/main/index-en.html] Motta, E.; Zdrahal, Z. (1996) Parametric Design Problem Solving, In Proceedings of the 10th Banff Knowledge Acquisition for KnowledgeBased System Workshop. Musen, M. A. (1998) Modern Architectures for Intelligent Systems: Reusable Ontologies and Problem-Solving Methods. In C.G. Chute, Ed., AMIA Annual Symposium, Orlando, FL, pp. 46-52. Pinto, H. S. and Martins, J. P. (2004) Ontologies: How can They be Built?, Knowledge and Information Systems, 6(4), pp. 441-464, Springer Verlag Poli, R. (2002). Ontological methodology. International Jounal on Human-Computer Studies 56(6), pp. 639-664 Psyché, V., Mizoguchi, R. et Bourdeau, J. (2003). Ontology development at the conceptual level for Theory-Aware ITS Authoring Systems, In Proceedings of the 2003 AIED Conference, Sydney Teije, A.; Harmelen, F.; Wielinga, B. (2004) Configuration of Web Services as Parametric Design. Lecture Notes in Artificial Intelligence, in Proceedings of the Proceedings of the 14 thInternational Conference on Knowledge Engineering and Knowledge Management EKAW'04, SpringerVerlag Wenger, E. (1987). Artificial Intelligence and Tutoring Systems: Computational and Cognitive approaches to the communication of knowledge. Morgan Kaufman Ed. Wielinga, B. J.; Akkermans, J. M. and Schreiber, A. Th. (1995) A Formal Analysis of Parametric Design Problem Solving. In Proceedings of the 9th Banff Knowledge Acquisition Workshop KAW95, Banff, Canada, pp. 37-1 37- 15
[isaias.garcia, carmen.benavides, diefrs, hmoreton, dieaaa]@unileon.es Systems Engineering and Control Group Dept. of Electrical and Electronic Engineering, University of León Edificio Tecnológico, Campus de Vegazana s/n, 24071 León (SPAIN) 2 [[email protected]] Computer Science and Artificial Intelligence Group Dept. of Computer Science Edificio departamental 1, Campus de Viesques s/n, 33204 Gijón, Asturias (SPAIN)
Abstract: The modeling of domains is today a technique with growing acceptance into the software community. Domain models allow the information to be represented in the computer at higher abstraction levels than in the usual applications, so improving the human to machine and machine to machine interactions. This paper deals with the application of such modeling paradigm to the control engineering education field, showing how the knowledge of this domain can be represented in a conceptual structure called ontology which is used as the base for building an Intelligent Tutoring System, a software tool used in the emerging field of e-learning. Keywords: Intelligent Tutoring Systems, ontologies, conceptual modeling, control engineering education.
1.
INTRODUCTION
Computers have been used for training and education since their very invention. Several properties of the computer have been exploited with this aim: the capacity of performing very fast numerical calculus, the ability of representing multimedia data, its high level of availability and during the last years, because of the advent of the Internet, the possibility of ubiquitous access to huge amounts of information, the possibility of building and using remote laboratories and applications, the use of collaborative spaces for distance learning, and the plethora of different technologies that help doing so. All these characteristics have given raise to the growing field of research known as e-learning. Today, e-learning is concerned about applying the Information Technologies to the whole learning
process, and so it is worried about how computers may be applied to the methods, processes and objects present in this field. One of the key issues is to find ways in which the software applications may capture the knowledge involved in the definition and implementation of the tasks and activities that are present in learning and tutoring, including the resources and the agents participating in these processes. The common solution to build the kind of applications previously mentioned founds in the modeling paradigm for software design and development that is maturing in the Software Engineering and in the Knowledge Engineering fields (Miller and Mukerji, 2003). Ontologies (Gruber, 1993) are the conceptual artifacts that have shown to be the right ones in order to capture, store and reuse the model of the knowledge of a domain
(the so-called conceptual model, conceptual structure or, simply, the conceptualization of the domain). Stating the knowledge of a domain in a conceptual structure such as an ontology allows for the semantics of the domain to be captured into a software application and transmitted to the human, improving the machine to human interaction. As a paradigmatic example from the control education field, one can realize that the significance of the techniques for manually sketching the root locus has been diminished by the use of computers and applications like Matlab, that can draw accurate plots very fast. While this is with no doubt an advance, there is also a side effect: the disconnection of the student using Matlab from the concepts underlying the root locus plot. This is not an isolated fact, it also occurs in the industry, where the more and more complex software used in automation isolates the human from the plant or process, being this a potential source of problems and also of discouraging for plant operators. These problems occur because the software applications being used generate a semantic gap between the user and the meaning of the data, that is, the meaning of what is happening inside the software. To fill this semantic gap applications should incorporate data represented at a higher abstraction level and this can be accomplished by using the mentioned conceptual models of the domain. The more knowledge the computer is able to manage, the better the human-computer and computer-computer interaction. This paper tries to apply these modeling techniques to the field of control engineering education by building a domain model of the subject matter to be taught and representing it in an ontology. This model is then used to build an Intelligent Tutoring System, a software application coming from the Artificial Intelligence field that plays a central role in elearning. While a complete Intelligent Tutoring System usually has some other models on it (see section 3), the work presented here is only concerned about the conceptual model of the subject matter being learned (that is, a given subdomain of control engineering). The paper is organized as follows: in section 2 a brief review of ontologies compared to other modeling techniques is done, section 3 introduces the field of Artificial Intelligence for Education and the use of ontologies in Intelligent Tutoring Systems, in section 4 an outline of the ontology is presented in order to show how a conceptual model for a design task in control engineering may be built and used, next, in section 5 the application developed (the ITS) is briefly described and last, in section 6, some conclusions are given.
2.
MODELING DOMAINS BY MEANS OF ONTOLOGIES
An ontology can be defined as a specification of a knowledge model that can be reused in different applications where the described knowledge applies (Gruber, 1993). Some authors stress the need for the ontology of having a community that commits to the representation it stores but, purely speaking, one can build a knowledge model without consensus, being a different issue its later degree of usability and success. Ontologies were born in the Artificial Intelligence and Knowledge Engineering field but are being adopted in the more traditional Software Engineering area because it offers advantages over the usual modeling paradigms found there like, for example, the Unified Modeling Language (UML) tools and techniques. In particular, the model found in an ontology differs from the knowledge found in an UML model in the fact that the ontology model is built to be used in the application as a crucial part of the software while the models built with UML are used in design time for representing the problem and the software project itself. Further, an ontology is able of representing much richer knowledge structures than UML tools are. Ontologies are being used in several fields of application (see (Lancieri et. al., 2005) or (DARPA, 2006)) for a detailed list) and are seen now as a key data structure for the knowledge management in the organizations, just like databases have been during many years (and still are). Figure 1 represents the ontology field and some of its related concepts and applications (taken from Mizoguchi, 2006). As can be seen, education is one of the most important and direct applications of ontologies.
Knowledge-level Communication Education
KM
Theory Of Ontology
Knowledge Systematization
Semantic Web
HCI
Figure 1. Ontology-Related Concepts and Applications Building an ontology is a modeling process, a knowledge modeling process. This field is not so mature as to have well defined, standard methodologies (though (Poli, 2002) and (Pinto and Martins, 2004) can be cited as some approaches that have been proposed) and so only good practices and partial methodologies adopted in part from the Software Engineering field are available. In general,
an ontology is built upon two main structures (for a deeper discussion of these structures see (Musen., 1998)): • The static structure, comprising the concepts found in the domain and the relations among these concepts. • The dynamic structure, comprising the tasks used in the domain to solve the problems.
3.
INTELLIGENT TUTORING SYSTEMS
The field of research on Intelligent Tutoring Systems (ITS) or, in a broader sense, the so-called Artificial Intelligence for Education (AIED) field (Wenger, 1987) has some years of experience on the study of computers applied to educational software. The studies have evolved along the time, trying to find the best ways to describe the learning process from every point of view: from the one of the student, the tutor, the subject matter being learned and also the learning process itself. Today ITS are built from different knowledge models that represent those points of view, and also the agents and processes found in the field. These domain models are more and more usually stored in ontologies (Kasai et. al., 2005), (Psyché et. al., 2005). It is remarkable to realize that the tendencies today about ITS are building the better models as possible for the knowledge implied in the learning process while the emphasis some years ago was more focused on the study of the form of the learning process rather than in the content itself (Breuker et. al., 1999).
4.
OUTLINE OF THE ONTOLOGY
First, a subdomain within control engineering has been chosen to be modeled. This subdomain is the lead-lag compensator design with techniques from the classical control theory (mostly with the root locus techniques). There are several reasons to choose this domain: First, this domain has huge amounts of semantics in its core (much more than is found in the modern control theory, for example); second, the methods used to get a design involve several and different reasoning types (this poses a challenge when trying to build the model but the more complex a domain is, the more benefits are obtained later from this model); and third, it is a wellknown field with lots of bibliographical data describing the processes. This section deals with the conceptualization of the knowledge found in the subdomain, describing the ways in which the knowledge model has been built and giving some examples of the structures that form the ontology. The in-depth description and discussion of the ontology would need much more space and is out of the scope of this paper. Only simplified
examples are presented as a way of seeing how the model is built and used. The section has been divided into two parts, resembling the static and dynamic structure that constitutes an ontology.
4.1 The static structure of the ontology The static structure, as introduced in section 2, is comprised of the concepts and relations of the domain. It has been built by using bibliographic data, interviews with experts in the field and also by introspection (because the authors can also be seen as experts in the domain). As an example, concepts used in this field may be signal flux graph, point, polynomial, root, pole, percent overshoot, etc. All these concepts have been arranged into different hierarchies in order to show the relations that hold among them. Relations may vary from the wellknown “is-a” inheritance relation to more complex ones like parthood, composition, connection, causality, etc. This way, several hierarchies of concepts could be obtained by just changing the focus on the relationship to be inspected. The concepts along with the relations among them form a complex networked structure of knowledge that build up the static structure of the ontology. In figure 2 the concept PolynomialRoot appears in two different networks where the links mean different relations. In figure 2a the traditional is-a relation is shown with the meaning “PolynomialRoot is a MathematicalConcept that is a Concept that (eventually) is a Thing” (Thing represents here the topmost concept in the is-a hierarchy). Figure 2b also has the same PolynomialRoot concept but appearing in a different relation network that could have a kind of “parthood”, “has associated” or “is composed of” meaning; this way, the branch could read “A TransferFunctionSystemModel has an associated PolynomialQuotient that has associated a (denominator)Polynomial that has associated a RootsAndGainDescription description that has associated a collection of Root that has associated a PolynomialRoot”. TransferFunctionSystemModel
Thing PolynomialQuotient
Concept (Denominator)Polynomial
MathematicalConcept
SystemCharacteristic
GraphicalRepresentation
(Numerator)Polynomial RootsAndGainDescription
PolynomialRoot (Collection of) Root
Gain
PolynomialRoot
Fig 2a
Fig 2b
Figure 2. Two Networks of Relations The static structure of the ontolgy is crucial to the system in order to being able of answering basic
questions of the type “what is this?” and also more complicated ones like “why (has something happened in the application)?” using causal relations, or to infer new knowledge using the existing one. As well as building this network of concepts and relations an ontology also contains the representation of rules or logic clauses by means of which new knowledge may be inferred from existing one. For example, the next rule states that when any pole of a system is located on the right half-plane the system is unstable: If A Pole isLocated on RighHalfPlane Then The System (representedBy the TransferFunctionSystemModel that has associated the PolynomialQuotient that has associated the (Denominator)Polynomial that has associated the RootsAndGainDescription that has associated the collectionOfRoots that has associated the PolynomialRoot that stands for the Pole) is unstable
This rule has been written in almost natural language and in a simplified manner in order to show the basic structure and also how the network of concepts shown in figure 2b is used to relate the pole (the root of a polynomial) to the system that is represented with a denominator having this root. All this representation, that seems so straight for humans, needs to be explicitly stated in the ontology in order the application can give explanations about what is occurring at runtime. Note that the assigning of instability to the system is very loosely stated in the rule. This has been intentionally done in order to put the attention to the rule as a whole. Stability is in fact one of the characteristics that may be represented to describe a system’s behaviour and has its place in the corresponding networks that describe quantitative and qualitative characteristics, the functions that may be used to calculate their values, the relations among them, etc. It must also be pointed out that the previous rule is one that express well-known knowledge for a well-defined fact but there are also heuristic knowledge in the domain as is for example the case of the reasoning about the position in the real axis that the zero of a lead controller should have. This previous example also serves as a way of showing how some kind of simple explanation may be obtained. Say that some design decision has lead to the whole system to present instability and this fact has been notified by putting some red flag somewhere in the user’s graphical interface. The user will see something like “the system is unstable with this design”. Then she could ask “why?” and an explanation would be generated based on the structure of the rule (or set of rules if the reasoning used is more complex). For example, the first answer to the mentioned question could be simply “because
there are poles of the system in the right-half plane”, then the user could ask for further information, for example, the system could show which pole/s is/are in the right-half plane, but could even tell the user what a pole is or how the roots of a polynomial are calculated. This kind of interactivity is what make ontology-based Intelligent Tutoring Systems so attractive for the learning of concepts in a complex domain. In fact, the system could also give explanations not only about why some design decisions must be taken but also about why other must not.
4.2. The dynamic structure of the ontology. Modeling the design task The dynamic structure of the knowledge in the ontology represents the tasks used to solve the problems pertaining to that domain. In this case it is clear that the main task could be named as “design”. So making the dynamic conceptual structure of the ontology is making the modeling of the design task in control engineering. In order to give explanations the system must have a complete and explicit representation of this task and all the subtasks that are involved on it. It is worth noting that this model of the task can be used (and is used indeed) not only to being able to explain the design process but also to automate the execution of the task in the computer. For this purpose, the so-called Generic Task or Problem Solving Methods (Musen, 1998) field of research is an active area devoted to find and develop general and reusable libraries of code that can implement the tasks models captured in the ontologies. In order to find the model for the design process as is carried out in control engineering, attention must be paid to similar approaches made and applied to different domains because the task itself is the same across domains if we abstract the details. Several studies have been devoted to the conceptual study of the task of design, and to identify the kind of domain knowledge needed before and during the problem resolution (Ahmed and Wallace, 2006). From all the studies that have been done, the socalled parametric design problem solving (Motta and Zdrahal, 1996), (Wielinga et. al., 1995), (Teije et. al., 2004) are the ones that most resemble the design of controllers in control engineering. Parametric design is assumed to be the correct model for a given task when the solution to a configuration design problem may be modeled as an artifact with a series of parameters whose values are to be found according to the given requirements, constraints and optimization criterions. This way, the lead-lag controller design task may be approximated and so modeled by means of the parametric design approach because the elements described may be easily mapped to the ones that appear in this control engineering task: The
artifact to be built is the controller, the parameters to be found may well be the pole and zero positions and the gain values, the requirements are the performance requirements for the controlled system (both transient and steady state), the constraints can be thought of as the physical limitations to build the designed controller (say values of resistances, capacitors, etc, for an electronic network realization of the controller design) and finally optimization criterion may be mapped to cost constraints, for example. Based on the studies about parametric design problem solving, a model of the task of design of controllers has been built. In this model, some additions have been introduced in order to represent some facts that are solely found in some engineering areas like the one of control engineering. As an example, one of these additions is based on the need of representing the kind of mathematical model by means of which the design is carried out and also the process of validation of this design on more realistic models of the system. This is because control engineering design with the classical control theory uses algebraic models of the systems that are further simplified in order to be able to ease the reasoning process and permit some kind of analytical studies, but this has the disadvantage that the designed solution must be tested in the models that don’t present simplifications, thus probably making the design process an iterative one. 4.3 Outline of the obtained model of the design Parametric design problem solving is basically a matter of finding the optimal solution within a given solution space that can be generated. In order to reduce the number of possible solutions some kind of heuristic knowledge is usually applied for narrowing this space. In the domain of controller design, one example would be the possible values for the real axis coordinate of the zero in a lead controller. While this parameter may take an infinity number of values some heuristics may be applied based on physical limitations, the position of the open-loop poles and zeros, the shape of the root locus, the design requirements, etc. Usually these heuristics may be expressed by means of a rule just like the one presented in the previous section and so this rule structure has been adopted as the basic decision structure for the modeling of the design task. The flexibility for the expressivity to be implemented in the rule’s general expression is found by seeing how the heuristics use to be stated. One of the most difficult issues faced in this step was the need of modeling different kinds of graphical reasoning and representing the qualitative concepts used when talking about the relative position of the different elements in a root locus.
5.
OUTLINE OF THE APPLICATION
Once the static and the dynamic models were constructed, the ITS application was built. This application also serves to validate the knowledge models obtained because the best way of validating the knowledge in the system is letting it interact with the user giving explanations of the design process and answering questions that the user poses, this way exposing the underlying knowledge. The flow of the execution of the program is as follows: First, the data about the problem is introduced, then it is turn to introduce the performance requirements (by means of the required characteristics in the transient and steady state portions of the time response of the system). Finally, a series of constraints for the controller are also introduced (in this first version only the type of controller can be introduced but in future versions also cost constraints are planned). Once the initial data are introduced, the system finds the better (with all the limitations that the system may present) solution to the problem and exposes to the user a graphical interface where she can see all the design steps and pose questions about any intermediate design achieved. As was seen when talking about the design task modeling, the design process in this application is carried out by the computer and not by the user. The user is able to ask for any of the design steps or any of the intermediate reasonings produced because all the steps are stored in the ontology using the concepts in the model. This may be seen as an odd behaviour for a tutoring system but it was done this way because one of the key issues when trying to explain a process is finding a model of it and this is what was pursued. In a future development the intervention of the user at any point of the design will be permitted and so the application could offer explanations about the user’s activities as well as giving advise about the proper design step to be accomplished if the user prefers let the system to perform it. The applications is written in Java and the ontology has been built with the tool Protégé, an open-source, flexible ontology editor tool that provides a complete Java API to access the structure and the data in the ontology. The dynamic structure of the ontology is putted into work by means of an ad-oc Java parser, while a translation of these structures into jess rules is also being studied in order to use the built-in jess rule engine (Friedman-Hill, 2006). 5.1 Verification and validation of the results Results obtained so far are being tested and studied by the creators of the software. No “general user“ experiences are available at the moment. Training cases are being introduced and used to test the
performance of the system. These training cases must be carefully selected as to expose all the reasoning and modeling characteristics that the system possesses. No techniques are mature today to test the validity or completeness of an ontological structure. The approaches used are based on the so-called “competence questions”, that is, a set of test queries posed to the system in order to compare the answers obtained to what would be the correct ones, covering all the expected functionalities. Results are being obtained as text output at the moment, though a graphical interface is being developed that will allow a much richer interaction with the system. 6.
CONCLUSIONS AND FUTURE WORK
An application has been built that shows the use of knowledge modeling techniques to build computer applications used for training and education in the control engineering field. In this paper it has been pointed out the possibility for a computer system with an explicit knowledge representation of being able of giving explanations to the user about the application’s internal processes and reasonings. Results so far are promising and may be a good experience in face of the “semantic revolution” that is spreading over many application areas in the software community. Future work will be directed both to find patterns for using and parsing ontologies and to extend the control engineering domain studied to cover the frequency domain techniques, PID controller design methods, etc. REFERENCES Ahmed, S. and Wallace, K. (2006) Reusing Design Knowledge. Advances in Design. H. A. ElMaraghy and W. ElMaraghy, SpringerVerlag Breuker, J., Muntjewerff, A., and Bredewej, B. (1999). Ontological modelling for designing Educational systems. In Proceedings of the AIED 99 Workshop on Ontologies for Educational Systems, Le Mans, France. IOS Press DARPA (Defense Advanced Research Projects Agency) (2006), DAML ontology repository, Available online (link checked on Jan, 26, 2006) [http://www.daml.org/ontologies/] Friedman-Hill E. (2006) "Jess: the Java Expert System Shell", Sandia National Laboratories, (link checked on 12th, May, 2006) [http://herzberg.ca.sandia.gov/jess/] Gruber, T. (1993) A translation approach to portable ontology specifications. Knowledge Adquisition, 5, pp. 199-220 Kasai, T.; Yamaguchi, H.; Nagano, K.; Mizoguchi, R. (2005) Goal Transition Model and Its
Application for Supporting Teachers based on Ontologies in Proc. of the 12th Artificial Intelligence in Education (AIED2005), pp. 330-337, Amsterdam, The Netherlands Lancieri, L. (coordinator); Maynard, D.; Gandon, F. (2005) Success Stories and Best Practices, Knowledgeweb deliverable 1.4.2, Available online (link checked on Jan, 26, 2006) [http://www.knowledgeweb.semanticweb.org/s emanticportal/home.jsp?_origin=%2Fhome.js p&instance=D1.4.2%3A+Success+Stories+a nd+Best+Practices&ontology=Documentatio n+Ontology&content=instance.jsp&instance_ set=kweb&var_name=instance] Miller, J.; Mukerji, J. (eds.) (2003) OMG Driven Architecture (MDA) guide. Available online (link checked on Jan, 26, 2006) [http://www.omg.org/docs/omg/03-06-01.pdf] Mizoguchi, R. (2006) ; Website of Mizoguchi Lab; Available online (link checked on Jan, 26, 2006) [http://www.ei.sanken.osakau.ac.jp/main/index-en.html] Motta, E.; Zdrahal, Z. (1996) Parametric Design Problem Solving, In Proceedings of the 10th Banff Knowledge Acquisition for KnowledgeBased System Workshop. Musen, M. A. (1998) Modern Architectures for Intelligent Systems: Reusable Ontologies and Problem-Solving Methods. In C.G. Chute, Ed., AMIA Annual Symposium, Orlando, FL, pp. 46-52. Pinto, H. S. and Martins, J. P. (2004) Ontologies: How can They be Built?, Knowledge and Information Systems, 6(4), pp. 441-464, Springer Verlag Poli, R. (2002). Ontological methodology. International Jounal on Human-Computer Studies 56(6), pp. 639-664 Psyché, V., Mizoguchi, R. et Bourdeau, J. (2003). Ontology development at the conceptual level for Theory-Aware ITS Authoring Systems, In Proceedings of the 2003 AIED Conference, Sydney Teije, A.; Harmelen, F.; Wielinga, B. (2004) Configuration of Web Services as Parametric Design. Lecture Notes in Artificial Intelligence, in Proceedings of the Proceedings of the 14 thInternational Conference on Knowledge Engineering and Knowledge Management EKAW'04, SpringerVerlag Wenger, E. (1987). Artificial Intelligence and Tutoring Systems: Computational and Cognitive approaches to the communication of knowledge. Morgan Kaufman Ed. Wielinga, B. J.; Akkermans, J. M. and Schreiber, A. Th. (1995) A Formal Analysis of Parametric Design Problem Solving. In Proceedings of the 9th Banff Knowledge Acquisition Workshop KAW95, Banff, Canada, pp. 37-1 37- 15