This work describes a tool that aids the development of a plant protection expert system (ES) for field crops. It is the result of accumulation of knowledge and expertise for building agricultural expert systems for about 20 years in the Central Laboratory for agricultural Expert Systems (CLAES). We have found out that all crop management tasks are candidate for using the ES technology to transfer expertise from highly qualified human experts to small farmers through intermediaries whom we call, extension workers in the agriculture domain. Plant protection tasks are part of crop management of any crop which need expertise that can be better represented in symbolic knowledge representation schemes rather than other tasks, like irrigation and fertilization which includes mathematical models more than symbolic knowledge. In addition to that annual yield losses due to pests are estimated to be in billions of dollars worldwide. Therefore, a decision has been taken to develop a plant protection expert systems building tool to expedite the development and maintenance processes of plant protection expert systems for field crops. Analyzing the plant protection task we come up with four sub tasks namely: variety selection, cultural practices, pest diagnosis, and pest control.
The second section will address the importance of building such tool. The third section will describe previous related work. The fourth section will describe the design and implementation of the tool, its web interfaces and its four main components corresponding to the four agricultural sub tasks : variety selection, cultural practices, pest diagnosis, and pest control. The fifth section will include our experience in developing the Barley expert system using this tool. The last section will conclude the chapter and propose new ideas for future research needed to enhance the tool.
2. Importance of building such tool
One of the most important problems that hinders the developing of expert system was the knowledge acquisition which is characterized in the literature as the bottle neck in building any expert system. Early research was concentrating on building generic problem solving shells like EMYCIN (van Melle, 1981) in which the problem solving method was an inference engine for rules knowledge base. Later on the frame paradigm was included with rules like the tools called KEE, LOOPS (Jackson, 1999) which allowed the behaviour of a frame to be represented in terms of a set of production rules. Other tools based on what is called second generation expert systems (David et. Al., 1993) was allowing a generic problem solving scheme like the generic task methodology proposed by Chandrasekaran (1988) and the KADS methodology which has been developed in an European project (Wielingaa et al., 1992). Those tools were never being commercialized on a large scale and stayed in the academic and research environment. All these tools were oriented toward general problem solving task not toward domain specific tasks. Our work concentrated on building domain specific problem solving tasks that could help in acquiring domain knowledge in specific format and consequently help knowledge engineers and domain experts in expediting the development of expert systems in a specific domain; in our case the domain is crop protection for plants.
3. Related work
In general the tools built for second generation expert systems for specific tasks like classifications, design and other tasks are related to what we are going to present in this chapter. The main difference is that we are more concentrating on the domain in addition to the tasks. Clancey (1993) introduced the heuristic classification task as he identified a wide range of expert systems in different domains which appear to function in more or less the same way. Ontology was recognized by many scientists as important component in an expert systems and some efforts were exerted to develop tools to assist users in building ontology and associated with it problem solving reusable methods. An example of these tools is PROTÉGÉ (Musen, 1989; Rothenfluh et al., 1994). Role limiting method is another method used to knowledge modelling (Studer et. al., 1998) but we are not aware of any tools developed to implement this method. The generic task (GT) methodology (Chandrasekaran, 1988) was introduced in the late eighties and some tools have been built for hierarchical classification and routine design task in academic and research institutions. The expertise model of CommonKADS methodology was also introduced for knowledge modelling using three layered approach domain knowledge layer, inference layer, and task layer (Wielingaa et al., 1992). Tools have been developed based on CommonKADS methodology for helping knowledge engineers in acquiring and analyzing knowledge such as the PC PACK tool which is developed by Epistemics company (www.epistemics.co.uk). Some other tools were developed in the early nineties but they were not used on a large scale.
In effect we have developed many expert systems using the GT methodology and CommonKADS methodology. The interested reader can search the following web site to get a lot of papers on the developed expert systems http://wwww.claes.sci.eg. In effect we were working on developing tools to help us in building expert systems using GT and CommonKADS methodology since long time. We started by developing tool similar to first generation rule based system tools augmented with objects on the top of Prolog to enable us in building the CommonKADS three layers better than commercial shells. This tool was called KROL (Shaalan et.al., 1998). We also developed a methodology for automatic KBS construction from reusable domain Specific components (Abdelhamid et.al., 1997). In 2003, we published a paper on automatic knowledge acquisition tool for irrigation and fertilization expert systems (Rafea et.al., 2003) in which we made use of the domain layer we have developed in irrigation and fertilization expert systems to develop an interactive tool to acquire knowledge from domain experts in these areas. This task was repeated for other tasks like diagnosis of plant disorders (El-Korany et. al, 2004). The accumulated experience enabled us to build the tool that we are going to present in this paper.
4. Design and implementation of the tool
The objective of building this tool was to expedite the knowledge acquisition process and implementation of plant protection tasks expert systems. The tool was availed on the web and allowed collaborative development of these expert systems on the web. It has an administration component that enables the tool administrator to: manage registrations of different types of users (administrator, expert, end user), manage the addition /deletion of expert systems projects, and assign users to projects. The tool contains also an ontology editor to help the user in building the plant protection ontology. This section describes the four task that comprise the plant protection expert system namely variety selection, cultural practice, pest identification, and pest control.
4.1. Variety selection task
The varietal selection task assists the user in identifying varieties that are resistant to certain pests and is suitable for cultivation according to other user requirements. The variety selection task is simply modelled in CommonKADS. The task layer uses a specially designed problem solving method called "select and assign". The inference layer contains two inference steps named "select" and "assign-value". The domain layer has two knowledge bases. The first knowledge bases is for selecting the appropriate variety based on input user requirements, and the second knowledge base is for assigning a value to an attributes like predicted yield based on environmental parameters like soil type or weather condition. The tool contains the task, and the inference steps, and the domain knowledge types, in this case the knowledge types are rules.
The knowledge acquisition mode works in a very a simple way such that a domain expert can use the tool. The user who may be a knowledge engineer or a domain expert can specify the varieties of the crop he will be using and add them to the ontology available with the tool which contains basic concepts and properties of any agricultural expert system. For each variety the user adds the features of the variety such as the pests it is resistant to, the environmental factor it is tolerant to, its expected yield, and other features. For each feature the user can decide whether this feature is an input or output feature of the variety selection task (rule schema for selecting the variety). If it is an output feature the tool acquire other factors that affect this feature (rule schema for assigning attribute value). For example the expected yield may change based on environmental factor and consequently the tool acquires these factors. Once the schema is defined the rule instances are acquired.The acquired knowledge is mapped into a suitable rule based knowledge representation scheme using XM L while the input/output features are represented in a presentation layer.
The consultation mode uses the built-in task layer to run on the acquired knowledge: This task starts by asking the users about the features of the variety they want, and run the inference mechanism to produce the recommended variety and then ask the user about the environmental parameters to determine the value of attributes that depend on these parameters.
4.2. Cultural practices task
The cultural practice task recommends cultural practices that should be done before and/or after cultivation to prevent disorder appearance. This task is modelled using routine design generic task. In the Routine Design Generic Task the problem is divided into a collection of specialists, and each a specialist is responsible for accomplishing a small part of the overall design. Following the Generic Task view, the specialist decides which of his plans should be carried out based on the plan constrains (Plan selector). Generally each specialist selects one of its plans. Each plan selected decides which tasks should be carried out based on the task constrains (Task selector), and each task has a number of steps that determine the detailed description for it. The cultural practices task has one specialist, six plans corresponding to the main pests categories: fungal diseases, viral diseases, insects, weeds, nematodes, and snail slugs, a number of tasks corresponding to practices types applied on each of the main pests categories under the plan handling each category, and steps under each task that assign values to the attributes describing the agricultural practices handled by the task. The generic task control that handles this knowledge representation scheme is a built-in module in the tool.
The knowledge acquisition mode: In the knowledge acquisition mode the tool acquires the cultural practices to protect the crop against certain pests given by the user. After providing the tool with the practices needed to protect the crop against a category of pests, the properties of each practice that are represented as steps of the task, and the factors that affect the decision for choosing a value for this property, the tool starts asking the user about the properties values of each practice and the factors that affect the selection of this value. For example if the practice is “spraying pesticides” and this operation has a property called pesticide name, and this pesticides depends on the soil type and the variety cultivated, the tool asks the user about the soil type and cultivated variety that are used to determine the pesticide name. It can acquire as many decision rules that relate pesticides protecting a crop against certain pest taking into consideration the factors affecting the selection. The acquired knowledge instantiates the routine design knowledge representation scheme using XM L while the input/output features are represented in a presentation layer.
The consultation mode uses the built-in task control to ask the users about the pest against which they want to protect their crops. Based on this pest and the attributes added to the presentation layer built during the knowledge acquisition of factors affecting the generation of the solution, the system generates a screen asking about the factors and then run the routine design task control that generates the recommended practices with their properties.
4.3. Pest identification task
The pest identification task assists the user in identifying the causes (disease, Insect, and others) of the user complains (Observation). The pest identification task is modelled in CommonKADS. The task layer uses a specially designed problem solving method called "generate and confirm". The task contains the sub task "generate" which is implemented using the problems solving method "identify and generate, and the inference step "confirm-hypothesis". The task "generate" has two inference steps" identify-observation" and" generate-hypothesis". The inference layer contains the subtask "generate" and the inference step "confirm-hypothesis". The domain layer has two knowledge bases. The first knowledge base is a tree where growth stages node is the root, and each growth stage is a child node of the root, plant parts that appear within this growth stage are children of this growth stage, and observation for each plant part are the leaves. The second knowledge base is a relation between primary and secondary observations and causes. The tool contains the task, the inference steps, and the domain knowledge types; in this case the knowledge types are tree together with its schema and rules.
The knowledge acquisition module acquires all diseases, insects and other pests affecting the underlying crop. For each cause the user adds its symptoms and the plant part on which this symptom appears (In effect the second knowledge base is built during this acquisition process). For each symptom the user can decide whether this symptom is a primary observation or not. It is also required to acquire first knowledge base by acquiring the growth stages of the underlying crop, the plant parts that are visible during each growth stage, and the primary observations on these parts..The acquired knowledge is mapped into a suitable knowledge representation using XML while the input/output features are represented in a presentation layer.
The consultation mode uses the built-in task layer to run on the acquired knowledge: This task starts by running the subtask "generate" which asks the users about the growth stage, selects the primary observations that can be visible during this stage, generate a screen containing these primary observations, asks the user about primary observations, and generate suspected disorders. After generating the suspected disorder the pest identification asks the user whether they want to confirm the suspected disorders. If the user clicks yes the confirmation process starts by generating related observation which are generated from the rules that have partially matched. The inference steps "generate-hypothesis" and "confirm-hypothesis" use a specially designed inference method that partially match the condition part of the rule and come up with a certainty measure based on the number of premises matched in case of the confirmation process. Each time the users select an observation the confirmed causes appear with a certain degree of certainty. In effect there are two modes of confirmation process; one mode which diagnoses a single cause and another mode which diagnoses multi-causes. In the single cause diagnosis the confirmation process tries to satisfy the rule that diagnoses one cause by selecting this rule once the user chooses a certain observation while in the multi-causes diagnosis the confirmation process keeps the list of suspected disorders and just changes their certainty measures after each observation selection. The certainty measure ranges from 0.0 to 1.0.
4.4. Pest control task
The pest control module is similar to the cultural practice module. It is also based on the routine design generic task. It differs in that it assumes that the pest has appeared and needs to be controlled. So this task needs to acquire more inputs from the user during the knowledge acquisition phase such as the infestation level, and time to harvest.
5. Developing Barley Expert System
The development of Barley Expert System for plant protection was the first expert system developed using the tool presented in this paper. The effort in developing this expert system started in collaboration with International Centre for Agricultural Research in the Dray Areas (ICARDA) in 2003 and a paper documenting this collaboration was published (Abdul- Hadi et.al. 2006). CLAES continued working on this expert system and developed a new version containing the Egyptian expertise only (http://es.claes.sci.eg/barley/). The system contains the four tasks presented here above. The following sections describe briefly the four tasks as an example to of using the tool to clarify the concepts provided in section 4.
5.1. Variety selection module
The input parameters identified by the domain expert are plant height, row type, and the pests that the variety needs to be resistant to. Providing the system with the following data: plant height =tall, row type=6-Row, and the pest that the variety needed to be resistant to, is leaf rust, the system generated two varieties: Giza 123, and Giza 132. In this implementation the domain experts did not find that it is necessary to add the second knowledge base that determine some features based on environmental parameters. So the only output is the varieties selected. Clicking on the variety selected the features of the variety is displayed.
5.2. Cultural practice module
The cultural practice module covers 7 pest classes with a total of 38 pests. Once the user chooses certain pests the system responds by giving the cultural practices needed to be done as a preventive measure to inhibit their appearances. For example choosing cultural practices to prevent the appearance of Loose smut and Grasshoppers and click on cultural practices button produces the output shown in figure-2.
5.3. Pest identification module
The first thing that the system requests as input from the end user is the growth stage. The system covers the 8 growth stages of Barley. If the user chooses one stage, say flowering, the system displays a screen that contains primary observation on plant, leaf, and grain. Entering the primary observation, say dead plants, and clicking on diagnosis using single cause mode, the suspected causes, Bird cherry-oat aphid and Green bug aphid are displayed as shown in figure 3.
Clicking confirm diagnosis, the secondary observations appear. Choosing the leaf colour to be brown the Bird cherry-oat aphid is taken out of the diagnosis and the Green bug aphid stays with 0.4 certainty as shown in figure 4. The observations that are still being displayed are related to the diagnosed disorder and they are shrinking each time one observation is selected. If they exist the user can reach diagnosis with 1.0 certainty. Applying the same scenarios using the multi-cause diagnosis the two suspected causes are displayed after providing the same observations with these certainties Bird cherry-oat aphid with 0.14 certainty and Green bug aphid with 0.4 certainties as shown in figure 5. As you can see the secondary observations are not shrinking like the single-cause diagnosis because the system tries to diagnose all suspected causes. Each time the user chooses an observation the certainty measure of one or more causes increases based on its relevance to these causes.
5.4. Pest control module
The Pest Control module covers the same number of pests covered by the cultural practices module. The difference is that this module is used when a disorder appears and the pest that causes this disorder is diagnosed. For example if leaf rust is diagnosed, the system asks first about the percentage of infected plants, the available pesticide, and then give the recommendation as shown in figure 6.
6. Conclusion and future work
This paper describes the development of a Web-Based Domain Specific Tool for Building Plant Protection Expert Systems and its usage to build an expert system for Barley protection. The plant protection knowledge has been modelled into four modules: variety selection, cultural practices, pest identification, and pest control. The tasks of the four modules are built-in in the tool. The tool also allows the user to choose the input and outputs of thee system as it has a presentation layer. The main contribution of this work is in building such tool that has the following characteristics: share knowledge acquisition through availing the tool on the Internet, enable human experts to cooperate with knowledge engineer through using the tool, and represent the knowledge in XML which is a standard data language to facilitate knowledge verification and future upgrading. There is still some work to be done to further verify the tool to be more user friendly for human experts and to support more crops with minimum intervention from the tool developer.