Following are the examples of IF ... THEN Rule
Example 1
Rule : Red_Light IF the light is red THEN stop
Rule : Yellow_Light IF the light is yellow
THEN look
Rule : Green_Light IF the light is green THEN go
Example 2
A typical rule used by the MYCIN expert system is :-
IF the stain of the organism is gram negative
AND the morphology of the organism is rod AND the aerobicity of the organism is anaerobic
THEN there is strongly suggestive evidence ( 0.8 ) that the class of the organism is ENTEROBACTERIACEAE MYCIN Format IF (AND (SAME CNTEXT GRAM GRAMNEG) (SAME CNTEXT MORPH ROD) (SAME CNTEXT AIR AEROBIC) THEN (COCLUDE CNTEXT CLASS ENTEROBACTERIACEAE TALLY .8))
Two alternative strategies are available for inferencing which are namely Forward chaining and Backward chaining. A particular inference engine may adopt either or both. Forward chaining (data driven) and Backward chaining (hypothesis driven) techniques represent the fundamental reasoning approaches implemented in rule-based expert systems. In forward chaining, the expert system is given data and chains forward to reach a conclusion. Forward chaining systems are data-driven. In order to execute a rule-based expert system using the method of forward chaining we merely need to fire (or execute) actions whenever they appear on the action list of a rule whose conditions are true. This involves assigning values to attributes, evaluating conditions, and checking to see if all of the conditions in a rule are satisfied.
A general algorithm for this might be :
While values for attributes remain to be input read value and assign to attribute. v Evaluate conditions v Fire rules whose conditions are satisfied
Several points about this require consideration. First, some conflict resolution strategy needs to be employed in order to decide which rules are fired first. Our method is to fire the rule which the system designer defined first. Also, we wish to cut down on computational time. To do this we must not do anything which does not absolutely need to be done. This means that conditions are only evaluated at the time they might change and that rules are checked (to see if all of their conditions are satisfied) only when they might be ready to be fired, not before. We shall do this, as attributes are assigned values and shall only consider rules and conditions affected by the new attribute assignment.
In backward chaining, the expert system is given a hypothesis and backtracks to check if it is valid. Backward chaining systems are generally goal-driven or 'goal-orientated' in the sense that it tries to prove a goal or rule conclusions by confirming the truth of all it's premises. Backward chaining starts with a list of goals (or hypothesis) and works backwards to see if there are data available that will support any of these goals. An inference engine using backward chaining would search the inference rules until it finds one which has a Then clause that matches a desired goal. If the If clause of that inference rule is not known to be true, then it is added to the list of goals (in order for your goal to be confirmed you must also provide data that confirms this new rule).
5.6 Building Expert System
Developing an Expert System
There are following ten basic steps in developing any expert system
1. Identify the problem and need : Like many computer programs, expert systems are, in a sense a solution looking for a problem.To justify the creation of an expert systems, there must be a real problem to solve or need to meet. For that reason, your first step in developing an expert system should be to examine your situation and clearly decide what the problem is or why such a system may be helpful. In attempting to achieve results, we often run into problems : time problems, productivity problems, or people problems. 2. Determine the suitability of the problem : Once the problem is clearly identified, you can then examine it in more detail to see if it is right for an expert system solution. 3. Consider the alternatives : Although your problem may fit the criterion for an expert system, don't overlook what might be simpler or equally as satisfactory alternative solutions. For example, certain kinds of employee performance problems might be corrected by training. Another solution is providing all employees with the information they need in a written manual or job aid. A non-computers solution may be not only the best solution, but also the simplest and least expensive. Consider other software alternatives. A database management system (DBMS) software package might better fit the problem than an expert system, by letting you store a significant amount of information and access it conveniently. The ability of the computer to reason may not be necessary. Finally, don't overlook a conventional software solution. A straightforward algorithmic solution might be better than a symbolic or AI solution. Having now looked at the alternatives, you can make your final decision. If an expert system is your choice, then you can begin the next steps. 4. Compute the return-on-investment : If your choice is an expert system, your next step is to determine whether or not it is economically feasible. You must compute the Return On your Investment (ROI) by performing a cost/benefit analysis. Developing an expert system is not a simple job. It is going to cost a considerable amount not only in the purchase of software but in the hours it will take to create the system. Personnel must be available to do the work, and even the simplest of expert systems will take months to develop and cost a lot of money. Can the time and expense be justified?, is the problem to be solved, bad enough or important enough to make the investment. 5. Select a development tool : An expert system development tool is a software package that allows you to enter an expert's knowledge into the computer without having to program. Most expert system development tools are rule based. Some tools permit the implementation of frames and semantic networks, but they are usually more expensive
and generally operate on larger computer.
6. Perform the knowledge engineering : At this point in the development process, you are finally ready to do some real creative work. Development of an expert system begins with knowledge engineering : that is, acquiring the knowledge. As you know, knowledge comes in many forms. It can be standard textbook knowledge that you can dig out of books, articles, and other references quickly and easily. This knowledge is important, but it is usually not the best kind of knowledge for an expert system. The real knowledge will come from individuals who are experts in the subject. 7. Design the System : Using the knowledge you have acquired and the tool you selected, you can now begin the design of the expert system. First, you will need to have create an outline, a hierarchical flow chart, a matrix, decision table, or other format that will help you organize and understand the knowledge. Using these aids, you will convert the knowledge in to IF-THEN rules. It is best to follow the specific procedures recommended by the software tool you are using. Once the basic design is complete, you can begin using the tool to create a prototype of one segment of the system. Translate a portion of the knowledge into rules and test the newly created segment. Your job here is to test the concept before going ahead with the entire program. 8. Complete the development : Once you have satisfied yourself that the system is going to work satisfactorily you can begin to expand the prototype into the final system. The best way to go about this is to expand the prototype one segment at a time. 9. Test and debug the system : After the expert system has been developed, you will need to spend sometime to testing and debugging it. No expert system will be perfect the first time, and a considerable amount of work will be required to validate it. User feedback will show you where to make final changes, corrections, and additions to achieve the desired performance. 10. Maintain the system : An important part of expert system development is ongoing, maintenance, updating the system with new knowledge, removing knowledge is no longer applicable, and otherwise fine tune the system to keep it fully current and applicable to the problem.
Early Expert System
Pioneer work
Logic Theorist : Proved Herbert Simon, Allen 1955 Carnegie Mellon theorems using Newell propositional logic
MIT Marvin Minsky John 1960 McCarthy Claude Dartmouth LISP Shannon Bell Labs
Feigenbaum & Identify chemical 1960 DENDRAL Buchanan (Stanford) constituents
Diagnosis of infectious 1970 MYCIN Stanford diseases
1970 MACSYMA MIT Math expert system
| 1970 | HEARSAY | Carnegie Mellon | Speech recognition | |||
|---|---|---|---|---|---|---|
| Stanford | Research | |||||
| 1977 | PROSPECTOR | Inst Barnett | Duda, Hart, | Mineral diagnosis | ||
| 1978 | XCON (Earlier R1) | called McDermott | Automated Diagnoses | configuration system fault | computer in the | |
| 1981 | DART | Bennett Hollander | and | hardware system | of | computer |
Table. 5.1 Early Expert System.
5.7 Expert System Case Study
5.7.1 MYCIN Case Study
MYCIN is one of the earliest expert systems, and its design has strongly influenced the design of commercial expert systems and expert system shells. Mycin was an expert system developed at Stanford in the 1970s. Its job was to diagnose and recommend treatment for certain blood infections. To do the diagnosis "properly" involves growing cultures of the infecting organism. Unfortunately this takes around 48 hours, and if doctors waited until this was complete their patient might be dead! So, doctors have to come up with quick guesses about likely problems from the available data, and use these guesses to provide a "covering" treatment where drugs are given which should deal with any possible problem.
MYCIN was developed partly in order to explore how human experts make these rough (but important) guesses based on partial information. However, the problem is also a potentially importance in practical terms-there are lots, if junior or non-specialized doctors, who sometimes have to make such a rough diagnoses and if there is an expert tool available to help them then this might allow more effective treatment to be given. In fact, MYCIN was never actually used in practice. This wasn't because of any weakness in its performance-in tests it outperformed members of the Stanford medical school. It was as much because of ethical and legal issues related to the use of computers in medicine-if it gives the wrong diagnosis, who do you sue ?
MYCIN represented its knowledge as a set of IF-THEN rules with certainty factors. The following is an English version of one of MYCIN'S rules :
IF the infection is pimary-bacteremia AND the site of the culture is one of the sterile sites AND the suspected portal of entry is the gastrointestinal tract THEN there is suggestive evidence (0.7) that infection is bacteroid. The 0.7 is roughly the certainly that the conclusion will be true given the evidence. If the evidence is uncertain the certainties of the bits of evidence will be combined with the certainty of the rule to give the certainty of the conclusion.
MYCIN was written in Lisp, and its rules are formally represented as Lisp expressions. The action part of the rule could just be a conclusion an out the problem being solved, or it could be an arbitary lisp expression. This allowed great flexibility, but removed some of the modularity and clarity of rule-based systems, so using this fascility had to be used with care.
MYCIN is a (primarily) goal-directed system, using the basic backward chaining reasoning strategy that we described above. However, MYCIN used various heuristics to control the search for a solution (or proof of some hypothesis). These were needed both to make the reasoning efficient and to prevent the user being asked too many unnecessary questions.
The other strategies relate to the way in which rules are invoked. The first one is simple : given a possible rule to use, MYCIN first checks all the premises of the rule to
see if any known to be false. If so there's not much point using the rule. The other strategies relate more to the certainty factors. MYCIN will first look at rules that have more certain conclusions, and will abandon a search once the certainties get below 0.2.
There were many other developments from the MYCIN project. For example, EMYCIN was really the first expert shell developed from MYCIN. A new expert system called PUFF was developed using EMYCIN in the new domain of heart disorders. And system called NEOMYCIN was developed for training doctors, which would take them through various example cases, checking their conclusions and explaining where they went wrong.
5.7.2 Prospector
PROSPECTOR aids geologists in their search for ore deposits. Given the field data about a geological region, it can determine the probability of discovering a range of ore deposits, including sandstone uranium, massive sulfide, carbonate lead/zinc etc.
Prospector is a consultation system to assists geologists working in mineral exploration. It is being developed by Hart and Duda of SRI international. This system attempts to represents to the knowledge and reasoning processes of experts in the geological domain. The user of this system is an exploration geologist in early stages of investigating a possible drilling site. Its expertise is based on geological rules which form models of ore deposits, and a database of known rocks and minerals. In 1980, PROSPECTOR analyzed geological data from a site near Mount Tolman in eastern Washington and predicted the existence of molybdenum (an ore) in a particular location. Subsequent drilling by a mining company confirmed PROSPECTOR's prediction.
Working of Prospector
a) First, the geologists working on the prospector provide certain conclusions based on their study consisting of information like geologists setting structural controls, and kinds of rocks minerals and alteration products present or suspected. b) PROSPECTOR compares observations with stored models of core deposits. c) It then notes the similarities, differences and missing information. d) Prospector then assesses the potential of the prospect.
Features of Prospector
1. This ES talks to the geological expert in terms which are familiar to him. 2. It allows the user to see the information of the region at any given point of time during the consultation. 3. It chooses the hypothesis depending on core deposits and then asks the user relevant questions. Depending on the answer given by the user it can also change the hypothesis.
4. It checks for the inconsistencies in the answer and allows the user to change the answer if required. 5. It represents its conclusion and summary, explaining how it had reached the conclusion.
5.7.3 XCON / R1
The XCON system The R1 (internally called XCON, for eXpert CONfigurer) program was a production-rule-based system written in OPS5 by John P. McDermott of CMU in 1978 to assist in the ordering of DEC's VAX computer systems by automatically selecting the computer system components based on the customer's requirements.
It is one of the most cited expert systems. It was developed by DEC (Digital Equipment Corporation) and was a system that ensured the customer was supplied with all the components and software that was required to make up the specified computer system that they had ordered.
Need of XCON
DEC, Digital Equipment Corporation is a large computer manufacturer, started in
- Its catalogue has 40,000 different parts. Buyer (with Sales representatives) sends order, typically 100 parts in one order or so. v The delivery and assembly was done by DEC personnel. Too often, the part collection does not allow installation and it was also found that installed computer does not meet requirements. v The solution was to have a completely assembled and test system in factory. There was need of automated configuration system but early attempts with procedural languages were unsuccessful. v XS approach started around 1980. Significance Building a bespoke computer system means that every system is different and, as such, needs different components and software. For example, if a customer orders a disc drive then DEC has to ensure that the customer also receives the disc controller and the relevant cables. As a single system can be built from thousands of separate components, it was not easy for a human to ensure that the customer had everything he/she needed to build the system. XCON/R1 was an expert system that did this job automatically. It saved DEC's millions of dollars every year by speeding the assembly process and increasing customer satisfaction. It raised the profile of expert system to a level that had not been seen before.
The data Of XCON
XCON has five data bases,
- Components: Holds 30k parts, 25 to 125 attributes
- Container : Extra data on backplanes and cabinets, size and slots.
- Diagrams : 1200 ASCII arts for use in output diagrams
- Questions : Motivate and ask data from user, eg. Do you already have ...?
- Configuration : Consultation data like input and diagrams
R1's Evolution
In a period of less than a year, Rl went from an idea, to a demonstration system that had most of the basic knowledge required in the domain but lacked the ability to deal with complex orders, to a system that possesses true expertise. Its development was done in parallels, in many respects, in terms of the development of the several domain-specific systems engineered by Stanford University's Heuristic Programming Project. Rl's implementation history divides basically into two stages. During the first stage, which began in December of 1978 and lasted for about four months, much of the time was spent in, read and reread the manuals that describe many of the VAX configuration constraints.
The second stage, which lasted for another four months, was spent in asking people who were expert in the VAX configuration task to examine Rl's output, point out Rl's mistakes, and indicate what knowledge Rl was lacking. RI was sufficiently ignorant that finding mistakes was no problem. Given a criticism of some aspect of the configuration by an expert, all that was necessary in order to refine Rl's knowledge was to find the offending rule, ask the expert to point out the problem with the condition elements in the rule, and then either modify the rule or split it into two rules that would discriminate between two previously undifferentiated states. During this stage, Rl's domain knowledge got almost tripled.
5.7.4 DART
DART (Dynamic Analysis and Replanning Tool)
1. DART assists a technician in finding the faults in a computer system. (hardware and software). 2. DART is a joint project of the Stanford University and IBM that explores the application of artificial intelligence techniques to the diagnosis of computer faults. 3. DART uses a device-independent language for describing devices and device-independent inference procedure for diagnosis. 4. The primary goal of the DART Project is to develop programs that capture the special design knowledge and diagnostic abilities of these experts and to make them available to field engineers. 5. The practical goal of DART is the construction of an automated diagnostician capable of pinpointing the functional units responsible for observed malfunctions in arbitrary system configurations.
3. Personal Digital Assistant Expert System (PDAMUM)
It is a system that help people to manage their devices as per need. v PDA provides descriptive explanation that guide the user to recognize their PDA's problem and then provide a appropriate solution based on the accurate diagnosis. v PDAMUM help to recognize the synchronization problem with the devices. v PDAMUM uses several short questions and with the answers it reaches to conclusion with reasoning. v PDAMUM responds fast to user input and generates a reliable diagnosis report. v PDAMUM performs knowledge acquisition process in a cyclic manner. v PDAMUM uses rule technique to code the knowledge in the knowledgebase. A rule is an IF/THEN structure that logically relates information contained in the IF part to other information contained in the THEN part. v Following are the rules used in PDAMUM. Rule 1
IF Cradle connects with power supply AND Electrical source available THEN Cradle is activated
Rule 2
IF PDA's battery power available THEN PDA is working
Rule 3
IF PDA is working THEN PDA's PIM activates
Rule 4
IF USB connector connects with PC THEN PDA link with PC
Rule 5
IF Install Companion CD THEN Active Sync available
Rule 6
IF Partnership Mode Menu available AND Partnership Menu select THEN Partnership Mode define
Rule 7
IF Partnership Mode define _ THEN Partnership Mode activate
Rule 8
IF Install synchronization driver THEN PDA communicates with PC
Rule 9
IF Cradle is activates AND PDA's PIM activates AND Active Sync available AND PDA link with PC AND PDA communicates with PC AND Partnership Mode activate THEN Active Sync performs synchronization PDAMUM is more consistent than human. It may generate erreneous report but better as compare to human.
Expert system for travel recommendation and discuss its role
¨ Role of Travel recommendation expert system
1. The application of expert systems in tourism industry is no exception and they play a vital role in accumulation, synthesis and dissemination of knowledge. 2. Expert systems are knowledge-based system to embody expertise in a particular domain. The process of building a knowledge base in a particular domain helps to relieve man power and experts from answering routine questions which a computer based expert system can easily handle. 3. Expert systems are the most prominent product of Artificial Intelligence technology and they appear particularly suited for service industries such as tourism. 4. Travel recommendation expert system includes the features of both the travel router : An intelligent routing module for the tourism and personalization travel support agent.
5. Travel Router is an intelligent routing module designed for assisting the tourist in finding the shortest possible land route to reach the intended destination assisting the tourist in finding the shortest possible land route to reach the intended destination. By combining the features of both the travel router: An intelligent routing module for the tourism and personalization travel support system, one can give a more effective approach for the management of various tourist information. ¨ Design for expert system for travel recommendation
1. The expert system is built to recommend a suitable travel schedule that satisfies user input constraints such as time period, budget and preferences. Tourist center managers need to answer similar set of queries in their day-to-day work which could be replaced by an expert system for tourist information management. There are many different tourist information such as activities and places which can be stored as similar data structure. The proposed knowledge structure would be flexible enough to cope with high volatility in some tourist information such as transportation routes. Fig. 5.11 Travel recommendation expert system architecture (kb is knowledge base).
2. Travel recommendation includes intelligent components that perform reasoning and have some built-in heuristics. It is based on a number of ontologies, which support the process of adding semantics to data and making them machine readable and understandable. In other words, Travel Guides illustrates how generating and using machine understandable data can Offer tourists a better service, v Decrease maintenance efforts of tourist agents, and v Increase interoperability of online tourism applications. Ontologies enable semantic description of data and more importantly -reasoning. Specifically, in Travel recommendation system, ontologies enable inferring of user profile types based on user interests and activities. Likely, destination types are inferred based on the destinations data. During process of search, the destination types are matched with the relevant user profiles. Searching for a perfect destination in Travel recommendation is performed using a very simple form that is part of the Travel recommendation environment.
3. The expert system structure includes the followings 1. Personalization Learner: Is the process of learning and analyzing of user behavior to understand user's interest. 2. Personalization Ranking: Its function is to rank the trip information for the users. The work process is based on the initial weight of learning and the user's interests on each trip. 3. User Profile Database: This is the database of users, which is operated for travel management depending on the user's behaviors, the database will be processed in mapping the trip list to the user's requirements. Profile database is categorized into two types : User's properties data and User's behavior. 4. Trip Features : Trip features associate to user interests in tourist programs, they are as follows: a) Trip Duration is numbers of days offering by each trip. b) Trip Categories is type of trip including shopping, eco tour, and scuba diving and trekking etc. c) Trip Lowest Price is the lowest prices for trip expenses. d) Trip Highest Price is the lowest prices for trip expenses. e) Trip Destination is the country of visitation.