- Email: [email protected]
A new language for electromagnetic knowledge specification
Journal of Materials Processing Technology 181 (2007) 249–253
A new language for electromagnetic knowledge specification S.R.H. Hoole a,∗ , A. Mascrenghe b,1 , K. Navukkarasu b a
b
University of Jaffna, Sri Lanka Department of Computer Sciences, University of Peradeniya, Sri Lanka
Abstract Knowledge specification languages are used in the design of electromagnetic and other products. But these, traditionally used to represent knowledge, do not exploit the full features of object-oriented programming and lack back-tracking. This paper provides the description of the prototype of a new knowledge specification language that we developed, to overcome these short-comings. The specific focus is on electromagnetic product design, vis-`a-vis the selection of motors from user specifications. We show that a full integration of object-oriented programming and logic programming is possible. © 2006 Elsevier B.V. All rights reserved. Keywords: Knowledge specification language; Finite element analysis; Optimisation; Interpreter; Motor design
1. Introduction Finite element analysis now has reached a sophisticated stage. For a given engineering purpose such as motor design, given a configuration consisting of a motor type with a defined number of poles and slots, steel types, we know how to analyse it and get accurate answers. But this entire process presupposes that we know what motor to use, what the number of poles is, what material is to be used and so on. In fact this latter determination is the initial basic stage of design. The analysis and optimization are subsequent phases of fine tuning of the basic design. In this initial stage we manipulate with a knowledge base to reach these primary design decisions on what motor, what material, etc., to use [1]. Knowledge representation and inference from knowledge bases are essential parts of any intelligent system [2]. These rules are encoded in manuals [3] which is transcribed into a rules base and used here. Many systems have been developed to represent different domains of knowledge, but they all use traditional languages like Prolog and LISP. Be it noted that there have been advances in programming languages. New concepts like object-oriented programming (OOP) are now famous for their advantages and are very useful for knowledge representation but are not exploited by these languages. When we were in the process of developing a system to automate the design process of electromagnetic devices, at one stage ∗ 1
Corresponding author. E-mail address: [email protected] (S.R.H. Hoole). Present address: Informatics, Colombo, Sri Lanka.
0924-0136/$ – see front matter © 2006 Elsevier B.V. All rights reserved. doi:10.1016/j.jmatprotec.2006.03.031
we had to represent the heuristic and experiential knowledge of experts of the field. We decided to choose a knowledge specification language which offers OOP features. When we surveyed the available languages, it was found that Visual Prolog 5.2 comes closest to our expectation. However, even Visual Prolog lacks certain important features in its provision of OOP facilities. 1.1. The drawback and the idea for a new language The main drawback with Visual Prolog 5.2 is that it lacks some of the features like backtracking which other declarative but non-object-oriented languages have. That is it has lost this essential feature when OOP features were implemented. It is at this point that the idea for a new language was conceived in our minds. We wanted to develop a prototype for a language to demonstrate that a very good integration of OOP features and logic programming is indeed possible for representing electromagnetic knowledge. Hence the development of this prototype for a new knowledge specification language, which we named, OI-KSL – Object Inference-Knowledge Specification Language. What we have created is just a prototype and no attempt has been made to make this into a commercial programming language. For instance, this is highly specialized – it caters only to the inference and determination of electromagnetic devices. Further, this prototype does not support certain normal language features such as arithmetic operations which may be trivially added. A language had to be selected to implement this interpreter. The ready candidate for such a process is C. The power of C
250
S.R.H. Hoole et al. / Journal of Materials Processing Technology 181 (2007) 249–253
is unparalleled. And it has a wide variety of data structures, which is essential in creating a language. Turbo C was selected because of its wide availability and simplicity. And this program was created in a DOS based environment. 2. Program design The program created through this language has two components. The object module and the question module.
Heuristic knowledge must be used by the knowledge engineer to encode the rules as well as make up these questions. These questions actually ask the value of the attributes. The answers of the user are compared with the value of the attributes in each object. And the objects that satisfy the conditions are listed as candidate answers. Each question defined by the user has a keyword. This keyword must be an attribute defined inside an object. 2.3. How it works
2.1. The object module The object module is where the objects are defined. A program obviously can have several objects. And inside each object attributes, methods and rules are defined. Attributes are made of slot and filler type structures. Methods contain the operations. They usually return the value of an attribute. This has been done so as to implement the OOP feature in such a way that data is accessed through the object’s own methods and not accessed directly. By defining the rules inside the objects themselves we are integrating OOP with production system architectures. Production systems contain a knowledge base that consists of rules. But in OI-KSL the knowledge base is not centralised in one place. It is distributed among various objects. If the name of the class comes in the ‘then clause’ then it has to be inside that class. For example assume a rule like ‘If size = small Then the motor should be a permanent magnet motor’. This rule will be inside the permanent magnet class since the ‘then clause’ refers to the permanent magnet. The consequent (the ‘then clause’ of the rule) is usually a method, which returns the identity of the class. (It has to be kept in mind that this language was specifically created for the purpose of this project and it can only be used for determining the generic type of the device (motor) to be used for a particular application.) Consider the following rule: IF size = “small” THEN get identity. This rule is placed inside the object called the permanent magnet dc motor. So the method get identity returns the name of the object, i.e. permanent magnet dc motor. It is essential that the word that follows the ‘IF’ be an attribute of that object. If not the interpeter will give an error message. The inference engine will check whether the value of the attribute that is given in the rule (which corresponds to the attribute value) is equal to the value the user has entered (see the question module below). By having the rules inside the objects we have created highly reusable objects. When another expert system is created these objects can be adopted with their rules – knowledge base – into the expert system.
The questions put in the program are fired and after each answer is given by the user, OI-KSL’s inference engine checks whether a solution could be given based on the knowledge base contained in the various objects to meet the user’s requirement. For example, assume that the question module contains the following question: what is the “speed“—variable/constant? Assume further that the user’s answer to the above question is ‘constant’ and that the knowledge base of the object ‘AC Motors’ contains a rule like the following: If speed = “constant” Then get identity.’ Then after asking the question the inference engine would search the object’s knowledge base and since the user’s input satisfies the above rule the identity of the object – say, synchronous motor – will be given as the answer. 2.4. Comparison with other languages The main phases of a compiler are lexical analysis, syntax analysis, interpretation, machine independent optimization, storage assignment, code generation and assembly and output [4]. However, for our purposes, the first three phases were sufficient. Upon their completion, the code will be passed as input to the inference engine that uses the intermediate structures created and populated by the first three phases, to arrive at conclusions (Fig. 1). The object-oriented implementation in Visual Prolog 5.2 is artificial and the integration between logic programming and OOP features is not very sound. But OI-KSL has integrated the best of both worlds together in a natural and sound way. Knowledge bases can be retained inside the objects in the form of rules in OI-KSL, whereas they had to be kept in the form of predicates in Visual Prolog 5.2. Rules are the natural, traditional way of representing knowledge. Putting them as predicates as Visual Prolog does is to really limit the expressiveness of the system. Further, instead of using a common knowledge base, OI-KSL uses an object dependent knowledge base, which contributes to
2.2. Question module The question module is made up of questions that should be answered by the user. The questions should be designed in such a way as to compare the user entered values with the attributes for which the rules are designed. For example let there be an attribute called speed. There will be a rule relating to the value of that attribute. For example “IF speed = “constant” THEN. . .”. So the question should be something like “What is the type of speed required – variable/constant?”
Fig. 1. The OI-KSL Language: Prototype Architecture.
S.R.H. Hoole et al. / Journal of Materials Processing Technology 181 (2007) 249–253
the reuse and sharing of knowledge bases, which has been the central theme of knowledge engineering since the 1990s [5]. In addition the availability of backtracking makes the interpreting process faster. Here rules from the NEMA Manual [3] can refer to the attributes such as variable or constant speed of a motor product; and from an attribute such as variable speed we can track all the motor products in the Manual that are associated with that attribute. This makes processing with the interpreter much faster.
251
of the rule is satisfied and the consequent of the rule is calling up a method in the object. 3.6. Question table This table will be used by the inference engine to get the input from the user. The questions that are already fired will be marked. 3.7. Unified symbol table
3. Intermediate structures used In all these intermediate structures the source code is not broken down to basic units, i.e. as in a typical compiler these are not broken down as literals, variables, etc. The breaking of the source code into such units did not serve any purpose as far as this project is concerned. It was simpler to keep the intermediate structures like this and then process them as and when necessary. The entries in the Terminal Table will be the same for any program. But the entries in other tables differ depending on the program. 3.1. Terminal table This table contains the keywords (reserved words) of the language. This table is used by the lexical phase to find the break character and when methods, rules, objects, attributes are defined, the names should not be the same as the symbol in the terminal table. 3.2. Object table This is where the list of objects is maintained. All the objects in the source program will be enlisted here. Examples of objects could be ac motor, dc motor, permanent magnet motor, etc. All the other tables that have the object actually have the index of this table. 3.3. Attributes table This table contains the attribute names and their values. Almost all the tables contain the object name in them. Since the same attribute can be there in several objects, keeping the object in this table is essential. Each row in this table is in the form of an object-attribute-value triplet. This table is used extensively to make up the difference table and process the rules. 3.4. Rules table This table has all the rules contained in all the objects. This table is used by the semantic analysis stage to create the difference table. 3.5. Methods table This table has all the methods in all the objects. These methods are used when the answer has been found; i.e. the antecedent
This is populated when lexical analyses break the code into tokens. It is very similar to the Unified Symbol Table of classical compiler theory. But the classes it will point to are different. Those classes will be objects, attributes, etc., i.e. the tables explained above. 3.8. Difference table The semantic analysis phase of the interpreter creates a structure called the difference table. This is somewhat similar to the difference table used in a Means-Ends Analysis. In the OI-KSL compiler the difference table is used to index the rules and to make the search faster. The attribute table is scanned along with the rules in the objects. And the result set is listed. If any rule references a particular attribute then that block is marked. This is possible as the OI-KSL allows rules to be in terms of attributes. If a rule refers to an attribute then that attribute is marked against that rule. So this can be used to find out what the rules are that refer to a given attribute and also what attributes are referred to by a particular rule. If the antecedent of the rule does not contain any attribute then it will be marked as a syntax error. By having this constraint IOKSL enforces an OOP implementation of rules, i.e. rules are always in terms of objects. This difference table is actually a statistical Meta structure. It is a Meta structure – as it is a piece of useful information about the existing rules. But it is also a statistical structure – as the Meta information is not a domain specific information, but rather statistical information gathered through scanning the existing rules. 4. Stages of the OI-KSL compiler The phases of the OI-KSL compiler do not do what the standard phases are supposed to do. Since the OI-KSL compiler does not produce machine code it only performs the first three phases of the standard compiler and then passes the information to the Inference Engine. 4.1. Lexical analysis The source code is broken down into tokens. But for the question module the break character is not space but the question mark. The inference engine scans the questions to find the attribute about which the question has been put. However the program does not break and separate the code
252
S.R.H. Hoole et al. / Journal of Materials Processing Technology 181 (2007) 249–253
into identifiers, literals, etc. Rather it breaks them down into objects, attributes, methods, rules, and questions. The uniform symbol table and the question table are populated at this stage. 4.2. Syntax analysis In this phase proper syntactical constructions that will be used by the OI-KSL compiler are recognised. Tables like the object table and attribute table are populated; i.e. the constructs are recognised as objects, attributes, etc. The interpreter scans the program for questions, objects and their attributes, methods and rules and stores them in the question table, object table, attribute table, method table and rules table, respectively. To do this it checks for the syntax as well—for example the value of an attribute must be enclosed in brackets, and the name of a method must follow the THEN statement of the rule.
Fig. 2. The tables being used.
4.3. Semantic analysis The difference table is created and populated in this stage to be used by the inference engine. Its being populated at this stage is appropriate; it helps the interpreter to understand the program and produces an index of rules and attributes. This phase points indirectly to the action that must be taken by creating this table. 4.4. The inference process The inference engine takes over after the semantic analysis. This process is largely dependent on the difference table, which minimises searching. The questions are put to the user and are marked as fired. The answer given by the user is stored and the question fired is analysed for the attribute. The attribute in the question is compared with the attributes in the attribute table and the index of the matching entry is marked. That index will be used to locate the attribute in the difference table. That will be the column number of the difference table. In the difference table a search is made for any rule that refers to the attribute. If found then the index of the row, i.e. the rule, is marked. That index is the index of the rule in the rules table. So the inference engine refers the rules table and finds the particular rule for processing. If the user’s input and the rule values match then the consequent part of the rule, i.e. the method, is carried out. This process is repeated for all the rules that refer to the particular attribute. Consider the following example (Fig. 2). Let there be a question and a rule about the speed: QUESTION: ‘What type of speed is required variable/constant?’; RULE: IF speed = “variable” THEN get identity. First the question is fired at the user. After the user answers the question by saying he wants variable speed, the attribute table is scanned for the attribute ‘speed’ (since that was the attribute referred to in the question). Using the index of that attribute in the attribute table, the difference table is scanned for
any rows that are marked against that attribute (attribute table index will correspond to the columns in the difference table). The indexes of such rules are marked. In this case the index will be 1, as the first rule refers to the attribute speed. Then the rule table is referred to, to find out the real rule and the object to which it belongs. Then that rule in that object is processed to find out whether the value that the user input to the question ‘What type of speed is required?’ matches with the ‘If’ part (the specified value, “variable” in this case) of the rule. If so then the consequent part of the rule is carried out. Consequent part of the rule is usually a method (‘get identity’ in this case). So the methods table is scanned for the method. Since the method refers to the attribute ‘identity’, attribute table is scanned for that attribute and the value is returned as the answer. In all the above searches the fact that attributes, methods and rules belong to different objects is taken into consideration as all the table rows indicate which object they belong to by having the object in each row. 5. Comparison of Visual Prolog and OI-KSL The object-oriented implementation in Visual Prolog is artificial and the integration between OOP and logic programming is not very sound. But OI-KSL integrated the best of both worlds together in a natural and sound way. Knowledge bases can be retained inside the objects in the form of rules, whereas in Visual Prolog rules had to be kept in the form of predicates. Rules are the natural, traditional way of representing heuristic knowledge. Putting them as ‘predicates’ as Visual Prolog does, is really to limit the expressiveness of the system. OI-KSL uses object based, distributed knowledge bases. Instead of a common knowledge base OI-KSL uses an object dependent knowledge base. This contributes to the reuse and sharing of knowledge bases, the central theme of knowledge engineering [5]. Visual Prolog loses backtracking in implementing OOP. But OI-KSL integrates both naturally. Consider the following Visual Prolog code:
S.R.H. Hoole et al. / Journal of Materials Processing Technology 181 (2007) 249–253 IMPLEMENT AC Motor CLAUSES speed(“constant”). ENDCLASS IMPLEMENT Permanent Poly synchronous CLAUSES speed(“constant”). ENDCLASS GOAL New Obj1 = AC Motor::new, New Obj1:speed(What), New Obj1:delete. New Obj2 = Permanent Poly synchronous::new, New Obj2:speed(What), New Obj2:delete.
In the above code although the objects AC Motor, Permanent Poly synchronous have the predicate speed in them, it has to be called explicitly in the goals section: New Obj1 = speed(What), .. . New Obj2 = speed(What),
But OI-KSL searches all the objects recursively for the answers naturally: naturally in the sense it is built right into the compiler. OBJECT: AC Motor .. . ATTRIBUTES: speed(constant); identity(AC Motor); .. . ATTRIBUTEEND METHODS: METHOD get identity RETURN identity; .. . ENDMETHOD METHODEND: RULES: RULE IF speed = “constant” THEN get identity. ENDRULE .. . RULEEND: OBJECT: Permanent Poly synchronous .. . ATTRIBUTES: speed(constant); identity(Permanent Poly synchronous); .. . ATTRIBUTEEND METHODS: METHOD get identity RETURN identity; .. . ENDMETHOD METHODEND: RULES: RULE
253
IF speed = “constant” THEN get identity. ENDRULE .. . RULEEND:
This code contains two objects: AC Motors and Permanent Poly Synchronous. So when the user wants a constant speed machine OI-KSL produces both these objects as answers. The OI-KSL compiler is doing this without any explicit coding from the OI-KSL programmer. 6. Features of OI-KSL and conclusions (1) OI-KSL is an object-based language developed for the primary design of motor products using the NEMA Manual (an industry standard [3]) to create a knowledge base. The main entities in a program created by the OI-KSL language are ‘objects’ which are the magnetic product design choices. OI-KSL supports attributes, methods inside these objects. (OI-KSL was not intended to be a fully fledged objectoriented language. It does not support certain features which other object-oriented languages have, features such as Interfaces, Automatic Garbage Collection, etc.) (2) It is a Knowledge Specification Language—engineering domain Knowledge from [3] is specified easily in terms of if-then rules in normal English. (3) Object Knowledge Bases—This is one of the important concepts that were developed. The knowledge bases from [3] are distributed among different objects. This creates highly reusable and independent objects. (4) Integrating classes and backtracking—again a key concept that was developed. Visual Prolog – the language that was used to create the Engineering Assistant – had sacrificed backtracking in the process of implementing object-oriented features. But OI-KSL brings the best of both worlds together to create an integrated environment with backtracking. Acknowledgements Thanks to the National Science Foundation (Sri Lanka) for support under Award No. RSP/2001/UOP/E/03 and Grant Nos. RG/2001/E/04 and RG/00/BG/12. References [1] S.R.H. Hoole, A. Mascrenghe, K. Navukkarasu, K. Sivasubramaniam, An expert design environment for electrical devices and its engineering assistant, IEEE Trans. Magn. 39 (3) (2003) 1693–1696. [2] C.L. Dym, S.R.H. Hoole, D. Kurumbalapitiya, Defining and representing knowledge in electromagnetic field computation, IEEE Trans. Magn. 29 (2) (1993) 1935–1938. [3] NEMA, Motors and Generators, NEMA Standards Publications No. MG 1–1998, Revision 1, 2000. [4] J.J. Donovan, Systems Programming, TATA McGraw-Hill, New Delhi, 1991. [5] A. Waterson, A. Preece, Verifying ontological commitment in knowledgebased systems, Knowledge Based Syst. 12 (1999) 45–54.
A new language for electromagnetic knowledge specification S.R.H. Hoole a,∗ , A. Mascrenghe b,1 , K. Navukkarasu b a
b
University of Jaffna, Sri Lanka Department of Computer Sciences, University of Peradeniya, Sri Lanka
Abstract Knowledge specification languages are used in the design of electromagnetic and other products. But these, traditionally used to represent knowledge, do not exploit the full features of object-oriented programming and lack back-tracking. This paper provides the description of the prototype of a new knowledge specification language that we developed, to overcome these short-comings. The specific focus is on electromagnetic product design, vis-`a-vis the selection of motors from user specifications. We show that a full integration of object-oriented programming and logic programming is possible. © 2006 Elsevier B.V. All rights reserved. Keywords: Knowledge specification language; Finite element analysis; Optimisation; Interpreter; Motor design
1. Introduction Finite element analysis now has reached a sophisticated stage. For a given engineering purpose such as motor design, given a configuration consisting of a motor type with a defined number of poles and slots, steel types, we know how to analyse it and get accurate answers. But this entire process presupposes that we know what motor to use, what the number of poles is, what material is to be used and so on. In fact this latter determination is the initial basic stage of design. The analysis and optimization are subsequent phases of fine tuning of the basic design. In this initial stage we manipulate with a knowledge base to reach these primary design decisions on what motor, what material, etc., to use [1]. Knowledge representation and inference from knowledge bases are essential parts of any intelligent system [2]. These rules are encoded in manuals [3] which is transcribed into a rules base and used here. Many systems have been developed to represent different domains of knowledge, but they all use traditional languages like Prolog and LISP. Be it noted that there have been advances in programming languages. New concepts like object-oriented programming (OOP) are now famous for their advantages and are very useful for knowledge representation but are not exploited by these languages. When we were in the process of developing a system to automate the design process of electromagnetic devices, at one stage ∗ 1
Corresponding author. E-mail address: [email protected] (S.R.H. Hoole). Present address: Informatics, Colombo, Sri Lanka.
0924-0136/$ – see front matter © 2006 Elsevier B.V. All rights reserved. doi:10.1016/j.jmatprotec.2006.03.031
we had to represent the heuristic and experiential knowledge of experts of the field. We decided to choose a knowledge specification language which offers OOP features. When we surveyed the available languages, it was found that Visual Prolog 5.2 comes closest to our expectation. However, even Visual Prolog lacks certain important features in its provision of OOP facilities. 1.1. The drawback and the idea for a new language The main drawback with Visual Prolog 5.2 is that it lacks some of the features like backtracking which other declarative but non-object-oriented languages have. That is it has lost this essential feature when OOP features were implemented. It is at this point that the idea for a new language was conceived in our minds. We wanted to develop a prototype for a language to demonstrate that a very good integration of OOP features and logic programming is indeed possible for representing electromagnetic knowledge. Hence the development of this prototype for a new knowledge specification language, which we named, OI-KSL – Object Inference-Knowledge Specification Language. What we have created is just a prototype and no attempt has been made to make this into a commercial programming language. For instance, this is highly specialized – it caters only to the inference and determination of electromagnetic devices. Further, this prototype does not support certain normal language features such as arithmetic operations which may be trivially added. A language had to be selected to implement this interpreter. The ready candidate for such a process is C. The power of C
250
S.R.H. Hoole et al. / Journal of Materials Processing Technology 181 (2007) 249–253
is unparalleled. And it has a wide variety of data structures, which is essential in creating a language. Turbo C was selected because of its wide availability and simplicity. And this program was created in a DOS based environment. 2. Program design The program created through this language has two components. The object module and the question module.
Heuristic knowledge must be used by the knowledge engineer to encode the rules as well as make up these questions. These questions actually ask the value of the attributes. The answers of the user are compared with the value of the attributes in each object. And the objects that satisfy the conditions are listed as candidate answers. Each question defined by the user has a keyword. This keyword must be an attribute defined inside an object. 2.3. How it works
2.1. The object module The object module is where the objects are defined. A program obviously can have several objects. And inside each object attributes, methods and rules are defined. Attributes are made of slot and filler type structures. Methods contain the operations. They usually return the value of an attribute. This has been done so as to implement the OOP feature in such a way that data is accessed through the object’s own methods and not accessed directly. By defining the rules inside the objects themselves we are integrating OOP with production system architectures. Production systems contain a knowledge base that consists of rules. But in OI-KSL the knowledge base is not centralised in one place. It is distributed among various objects. If the name of the class comes in the ‘then clause’ then it has to be inside that class. For example assume a rule like ‘If size = small Then the motor should be a permanent magnet motor’. This rule will be inside the permanent magnet class since the ‘then clause’ refers to the permanent magnet. The consequent (the ‘then clause’ of the rule) is usually a method, which returns the identity of the class. (It has to be kept in mind that this language was specifically created for the purpose of this project and it can only be used for determining the generic type of the device (motor) to be used for a particular application.) Consider the following rule: IF size = “small” THEN get identity. This rule is placed inside the object called the permanent magnet dc motor. So the method get identity returns the name of the object, i.e. permanent magnet dc motor. It is essential that the word that follows the ‘IF’ be an attribute of that object. If not the interpeter will give an error message. The inference engine will check whether the value of the attribute that is given in the rule (which corresponds to the attribute value) is equal to the value the user has entered (see the question module below). By having the rules inside the objects we have created highly reusable objects. When another expert system is created these objects can be adopted with their rules – knowledge base – into the expert system.
The questions put in the program are fired and after each answer is given by the user, OI-KSL’s inference engine checks whether a solution could be given based on the knowledge base contained in the various objects to meet the user’s requirement. For example, assume that the question module contains the following question: what is the “speed“—variable/constant? Assume further that the user’s answer to the above question is ‘constant’ and that the knowledge base of the object ‘AC Motors’ contains a rule like the following: If speed = “constant” Then get identity.’ Then after asking the question the inference engine would search the object’s knowledge base and since the user’s input satisfies the above rule the identity of the object – say, synchronous motor – will be given as the answer. 2.4. Comparison with other languages The main phases of a compiler are lexical analysis, syntax analysis, interpretation, machine independent optimization, storage assignment, code generation and assembly and output [4]. However, for our purposes, the first three phases were sufficient. Upon their completion, the code will be passed as input to the inference engine that uses the intermediate structures created and populated by the first three phases, to arrive at conclusions (Fig. 1). The object-oriented implementation in Visual Prolog 5.2 is artificial and the integration between logic programming and OOP features is not very sound. But OI-KSL has integrated the best of both worlds together in a natural and sound way. Knowledge bases can be retained inside the objects in the form of rules in OI-KSL, whereas they had to be kept in the form of predicates in Visual Prolog 5.2. Rules are the natural, traditional way of representing knowledge. Putting them as predicates as Visual Prolog does is to really limit the expressiveness of the system. Further, instead of using a common knowledge base, OI-KSL uses an object dependent knowledge base, which contributes to
2.2. Question module The question module is made up of questions that should be answered by the user. The questions should be designed in such a way as to compare the user entered values with the attributes for which the rules are designed. For example let there be an attribute called speed. There will be a rule relating to the value of that attribute. For example “IF speed = “constant” THEN. . .”. So the question should be something like “What is the type of speed required – variable/constant?”
Fig. 1. The OI-KSL Language: Prototype Architecture.
S.R.H. Hoole et al. / Journal of Materials Processing Technology 181 (2007) 249–253
the reuse and sharing of knowledge bases, which has been the central theme of knowledge engineering since the 1990s [5]. In addition the availability of backtracking makes the interpreting process faster. Here rules from the NEMA Manual [3] can refer to the attributes such as variable or constant speed of a motor product; and from an attribute such as variable speed we can track all the motor products in the Manual that are associated with that attribute. This makes processing with the interpreter much faster.
251
of the rule is satisfied and the consequent of the rule is calling up a method in the object. 3.6. Question table This table will be used by the inference engine to get the input from the user. The questions that are already fired will be marked. 3.7. Unified symbol table
3. Intermediate structures used In all these intermediate structures the source code is not broken down to basic units, i.e. as in a typical compiler these are not broken down as literals, variables, etc. The breaking of the source code into such units did not serve any purpose as far as this project is concerned. It was simpler to keep the intermediate structures like this and then process them as and when necessary. The entries in the Terminal Table will be the same for any program. But the entries in other tables differ depending on the program. 3.1. Terminal table This table contains the keywords (reserved words) of the language. This table is used by the lexical phase to find the break character and when methods, rules, objects, attributes are defined, the names should not be the same as the symbol in the terminal table. 3.2. Object table This is where the list of objects is maintained. All the objects in the source program will be enlisted here. Examples of objects could be ac motor, dc motor, permanent magnet motor, etc. All the other tables that have the object actually have the index of this table. 3.3. Attributes table This table contains the attribute names and their values. Almost all the tables contain the object name in them. Since the same attribute can be there in several objects, keeping the object in this table is essential. Each row in this table is in the form of an object-attribute-value triplet. This table is used extensively to make up the difference table and process the rules. 3.4. Rules table This table has all the rules contained in all the objects. This table is used by the semantic analysis stage to create the difference table. 3.5. Methods table This table has all the methods in all the objects. These methods are used when the answer has been found; i.e. the antecedent
This is populated when lexical analyses break the code into tokens. It is very similar to the Unified Symbol Table of classical compiler theory. But the classes it will point to are different. Those classes will be objects, attributes, etc., i.e. the tables explained above. 3.8. Difference table The semantic analysis phase of the interpreter creates a structure called the difference table. This is somewhat similar to the difference table used in a Means-Ends Analysis. In the OI-KSL compiler the difference table is used to index the rules and to make the search faster. The attribute table is scanned along with the rules in the objects. And the result set is listed. If any rule references a particular attribute then that block is marked. This is possible as the OI-KSL allows rules to be in terms of attributes. If a rule refers to an attribute then that attribute is marked against that rule. So this can be used to find out what the rules are that refer to a given attribute and also what attributes are referred to by a particular rule. If the antecedent of the rule does not contain any attribute then it will be marked as a syntax error. By having this constraint IOKSL enforces an OOP implementation of rules, i.e. rules are always in terms of objects. This difference table is actually a statistical Meta structure. It is a Meta structure – as it is a piece of useful information about the existing rules. But it is also a statistical structure – as the Meta information is not a domain specific information, but rather statistical information gathered through scanning the existing rules. 4. Stages of the OI-KSL compiler The phases of the OI-KSL compiler do not do what the standard phases are supposed to do. Since the OI-KSL compiler does not produce machine code it only performs the first three phases of the standard compiler and then passes the information to the Inference Engine. 4.1. Lexical analysis The source code is broken down into tokens. But for the question module the break character is not space but the question mark. The inference engine scans the questions to find the attribute about which the question has been put. However the program does not break and separate the code
252
S.R.H. Hoole et al. / Journal of Materials Processing Technology 181 (2007) 249–253
into identifiers, literals, etc. Rather it breaks them down into objects, attributes, methods, rules, and questions. The uniform symbol table and the question table are populated at this stage. 4.2. Syntax analysis In this phase proper syntactical constructions that will be used by the OI-KSL compiler are recognised. Tables like the object table and attribute table are populated; i.e. the constructs are recognised as objects, attributes, etc. The interpreter scans the program for questions, objects and their attributes, methods and rules and stores them in the question table, object table, attribute table, method table and rules table, respectively. To do this it checks for the syntax as well—for example the value of an attribute must be enclosed in brackets, and the name of a method must follow the THEN statement of the rule.
Fig. 2. The tables being used.
4.3. Semantic analysis The difference table is created and populated in this stage to be used by the inference engine. Its being populated at this stage is appropriate; it helps the interpreter to understand the program and produces an index of rules and attributes. This phase points indirectly to the action that must be taken by creating this table. 4.4. The inference process The inference engine takes over after the semantic analysis. This process is largely dependent on the difference table, which minimises searching. The questions are put to the user and are marked as fired. The answer given by the user is stored and the question fired is analysed for the attribute. The attribute in the question is compared with the attributes in the attribute table and the index of the matching entry is marked. That index will be used to locate the attribute in the difference table. That will be the column number of the difference table. In the difference table a search is made for any rule that refers to the attribute. If found then the index of the row, i.e. the rule, is marked. That index is the index of the rule in the rules table. So the inference engine refers the rules table and finds the particular rule for processing. If the user’s input and the rule values match then the consequent part of the rule, i.e. the method, is carried out. This process is repeated for all the rules that refer to the particular attribute. Consider the following example (Fig. 2). Let there be a question and a rule about the speed: QUESTION: ‘What type of speed is required variable/constant?’; RULE: IF speed = “variable” THEN get identity. First the question is fired at the user. After the user answers the question by saying he wants variable speed, the attribute table is scanned for the attribute ‘speed’ (since that was the attribute referred to in the question). Using the index of that attribute in the attribute table, the difference table is scanned for
any rows that are marked against that attribute (attribute table index will correspond to the columns in the difference table). The indexes of such rules are marked. In this case the index will be 1, as the first rule refers to the attribute speed. Then the rule table is referred to, to find out the real rule and the object to which it belongs. Then that rule in that object is processed to find out whether the value that the user input to the question ‘What type of speed is required?’ matches with the ‘If’ part (the specified value, “variable” in this case) of the rule. If so then the consequent part of the rule is carried out. Consequent part of the rule is usually a method (‘get identity’ in this case). So the methods table is scanned for the method. Since the method refers to the attribute ‘identity’, attribute table is scanned for that attribute and the value is returned as the answer. In all the above searches the fact that attributes, methods and rules belong to different objects is taken into consideration as all the table rows indicate which object they belong to by having the object in each row. 5. Comparison of Visual Prolog and OI-KSL The object-oriented implementation in Visual Prolog is artificial and the integration between OOP and logic programming is not very sound. But OI-KSL integrated the best of both worlds together in a natural and sound way. Knowledge bases can be retained inside the objects in the form of rules, whereas in Visual Prolog rules had to be kept in the form of predicates. Rules are the natural, traditional way of representing heuristic knowledge. Putting them as ‘predicates’ as Visual Prolog does, is really to limit the expressiveness of the system. OI-KSL uses object based, distributed knowledge bases. Instead of a common knowledge base OI-KSL uses an object dependent knowledge base. This contributes to the reuse and sharing of knowledge bases, the central theme of knowledge engineering [5]. Visual Prolog loses backtracking in implementing OOP. But OI-KSL integrates both naturally. Consider the following Visual Prolog code:
S.R.H. Hoole et al. / Journal of Materials Processing Technology 181 (2007) 249–253 IMPLEMENT AC Motor CLAUSES speed(“constant”). ENDCLASS IMPLEMENT Permanent Poly synchronous CLAUSES speed(“constant”). ENDCLASS GOAL New Obj1 = AC Motor::new, New Obj1:speed(What), New Obj1:delete. New Obj2 = Permanent Poly synchronous::new, New Obj2:speed(What), New Obj2:delete.
In the above code although the objects AC Motor, Permanent Poly synchronous have the predicate speed in them, it has to be called explicitly in the goals section: New Obj1 = speed(What), .. . New Obj2 = speed(What),
But OI-KSL searches all the objects recursively for the answers naturally: naturally in the sense it is built right into the compiler. OBJECT: AC Motor .. . ATTRIBUTES: speed(constant); identity(AC Motor); .. . ATTRIBUTEEND METHODS: METHOD get identity RETURN identity; .. . ENDMETHOD METHODEND: RULES: RULE IF speed = “constant” THEN get identity. ENDRULE .. . RULEEND: OBJECT: Permanent Poly synchronous .. . ATTRIBUTES: speed(constant); identity(Permanent Poly synchronous); .. . ATTRIBUTEEND METHODS: METHOD get identity RETURN identity; .. . ENDMETHOD METHODEND: RULES: RULE
253
IF speed = “constant” THEN get identity. ENDRULE .. . RULEEND:
This code contains two objects: AC Motors and Permanent Poly Synchronous. So when the user wants a constant speed machine OI-KSL produces both these objects as answers. The OI-KSL compiler is doing this without any explicit coding from the OI-KSL programmer. 6. Features of OI-KSL and conclusions (1) OI-KSL is an object-based language developed for the primary design of motor products using the NEMA Manual (an industry standard [3]) to create a knowledge base. The main entities in a program created by the OI-KSL language are ‘objects’ which are the magnetic product design choices. OI-KSL supports attributes, methods inside these objects. (OI-KSL was not intended to be a fully fledged objectoriented language. It does not support certain features which other object-oriented languages have, features such as Interfaces, Automatic Garbage Collection, etc.) (2) It is a Knowledge Specification Language—engineering domain Knowledge from [3] is specified easily in terms of if-then rules in normal English. (3) Object Knowledge Bases—This is one of the important concepts that were developed. The knowledge bases from [3] are distributed among different objects. This creates highly reusable and independent objects. (4) Integrating classes and backtracking—again a key concept that was developed. Visual Prolog – the language that was used to create the Engineering Assistant – had sacrificed backtracking in the process of implementing object-oriented features. But OI-KSL brings the best of both worlds together to create an integrated environment with backtracking. Acknowledgements Thanks to the National Science Foundation (Sri Lanka) for support under Award No. RSP/2001/UOP/E/03 and Grant Nos. RG/2001/E/04 and RG/00/BG/12. References [1] S.R.H. Hoole, A. Mascrenghe, K. Navukkarasu, K. Sivasubramaniam, An expert design environment for electrical devices and its engineering assistant, IEEE Trans. Magn. 39 (3) (2003) 1693–1696. [2] C.L. Dym, S.R.H. Hoole, D. Kurumbalapitiya, Defining and representing knowledge in electromagnetic field computation, IEEE Trans. Magn. 29 (2) (1993) 1935–1938. [3] NEMA, Motors and Generators, NEMA Standards Publications No. MG 1–1998, Revision 1, 2000. [4] J.J. Donovan, Systems Programming, TATA McGraw-Hill, New Delhi, 1991. [5] A. Waterson, A. Preece, Verifying ontological commitment in knowledgebased systems, Knowledge Based Syst. 12 (1999) 45–54.