- Email: [email protected]
EXSYS, an expert system for diagnosing flowerbulb diseases, pests and non-parasitic disorders
PII:
Agricultural Sysrem, Vol. 58, No. 1, pp. 57-85, 1998 0 1998 Elsevier Science Ltd. All rights reserved Printed in Great Britain 0308-521X/98 %19.00+ 0.00 SO308-521X(98)00046-8
ELSEVIER
EXSYS, an Expert System for Diagnosing Flowerbulb Diseases, Pests and Non-parasitic Disorders M. A. Kramers,* C. G. M. Conijn & C. Bastiaansen Bulb Research Centre, PO Box 85, 2160 AB, Lisse, The Netherlands (Received 3 April 1997; accepted 24 March 1998)
ABSTRACT When a commercial crop shows disease symptoms, it is important to make an accurate diagnosis to support control strategies. Diagnosing diseases in Jlowerbulbs requires considerable expertise. Only a few experts have the ability to do this, and each expert has his own specific domain. To retain expertise and to make it more generally accessible, an expert system, called EXSYS, has been developed. EXSYS contains disease descriptions and ofleers the ability to diagnose diseases in flowerbulbs. Digitalized photographic pictures of disease symptoms can be shown by the system to support an interacting session. This article describes the development of EXSYS, the structure of the knowledge base and the inference mechanism. A prototype has been built for diagnosing diseases in bulbous iris. Preliminary tests of this prototype at the Bulb Research Centre indicate that descriptions of observations can vary considerably between individuals. Adaptations have herefore been made to permit descriptions to d@er from the exact descriptions in the knowledge base. Tests made it clear that a correct and complete knowledge base is necessary to create a successful system. The aim is to reduce the percentage of failures to less than 5%. 0 1998 Elsevier Science Ltd. All rights reserved
INTRODUCTION Bulbous crops can suffer from many diseases caused by fungi, bacteria, viruses, nematodes, insects, mites and from non-parasitic disorders, caused *To whom correspondence should be addressed. 417762; e-mail: [email protected] 57
Tel.:
+ 31-252-462121; fax: + 31-252-
58
M. A. Kmners,
C. G. M. Con@, C. Bastiaansen
by physiological or chemical stress. In this article all disorders will be referred to as diseases. Accurate diagnosis is a prerequisite to control diseases in a crop. Where bulbous crops are concerned only a few experts have enough experience and knowledge of diseases to be able to make an adequate diagnosis. It is desirable to file this expertise. Within the diagnosis process two aspects can be distinguished: disease descriptions and reasoning. Problems that arise, when analysing working procedures of experts, are the diversity in technical terminology, the apparently inconsistent way of thinking and incomplete knowledge. An expert system was developed to compile the knowledge of experts, it compels uniformity of expression, but can cope with a lack of knowledge. This article describes the methods used to develop an expert system called EXSYS. It describes the structure of its knowledge base (disease descriptions) and inference mechanism (reasoning). The validation of the system is discussed and suggestions for further development are given.
EXPERT SYSTEM An expert system is an institutional memory. When key-people leave, their expertise is (partly) retained. (Waterman, 1986; Latin et al., 1987; Cooley, 1988; Travis and Latin, 1991). The system contains knowledge which makes it capable of making decisions. This knowledge is explicit and accessible. It mimics the way of thinking of an expert. Because these systems use heuristics instead of algorithms, they can operate with unknown or incomplete data. Many expert systems have been built for diagnosing diseases in plants (Michalski and Davis, 1983; Blancard et al., 1985; Plant et al., 1989; Adams et al., 1990; Latin et al., 1990) and for disease management (Roach et al., 1985; Ramon and Roland, 1994). Most systems are based on ‘if-then-procedures’ and use tree-structure like determination tables. They are built in a procedural language like PASCAL. However, when databases become larger and searching procedures more complex, these types of programme will become unmanageable, unacceptably slow and hard to modify. To avoid these problems EXSYS (Krammers et al., 1993, 1994a,b); was built in the declarative language PROLOG. PROLOG is based on definitions. This means that the inference mechanism combines separate definitions to compose diagnosing routes. This way of programming is less transparent but more flexible since definitions can be added whenever needed, at any place in the listing. A diagnosing process frequently requires comparison of sets of input data with data in the knowledge base. PROLOG has the ability to search very rapidly through large sets of information. Furthermore PROLOG uses frame structures, containing
Diagnosing diseases, pests and non-parasitic disorders
59
lists (sets) and nested lists. Since these lists have the ability to work with sets of information with an undefined number of elements, the knowledge base is extremely flexible. The nested structure provides an easy overview of the filed knowledge (Bratko, 1988; Coelho and Cotta, 1988; Dodd, 1990). EXSYS is not a determination table. Instead of using a fixed question procedure to reduce the solution area, the system looks directly for the most likely solution area, based on initial input data, which can be entered freely by the user. This prevents recurrence of questions and it reduces the number of questions (Fig. 1). In many systems numerical certainty factors are used to add a certain evidence degree to conclusions of systems (e.g. diagnostic certainty of Fusarium oxysporum is 80% and of Botrytis cinerea 30%). EXSYS does not use evidence degrees, since they are always susceptible to criticism and not absolutely necessary. EXSYS leaves it to the user to be critical about conclusions of the system (e.g. possible concluded diseases are F. oxysporum and B. cinerea). Elements of an expert system An expert system contains a knowledge base, an inference mechanism and a user interface (Fig. 2). The user communicates with the system through the user interface. The user interface passes information on to the inference mechanism. The inference mechanism selects information from the knowledge base. With this information and the user’s input it determines hypothesis and
Determination Follow question procedure: 5 questions asked to minimize the solution area
table
Expert system Go straight to the most likely solution, matching input.
Fig. 1. Finding the solution area.
hf. A. Kramers, C. G. M. Con&, C. Bastiaansen
60
/
EXPERT
fKnowledge base
SYSTEM
‘-
/
/
Inference mechanism
User interface
Fig. 2. Elements of an expert system.
formulates questions. The questions are passed on to the user through the user interface.
METHODS Development of EXSYS can be divided into four parts: 1. 2. 3. 4.
designing the inference mechanism, developing a knowledge structure, collecting disease descriptions, and building a prototype.
The inference mechanism and knowledge structure were developed simultaneously. Necessary changes were made during collection of disease descriptions and the system was even improved during construction of the prototype. Designing the inference mechanism Initially the way of thinking of one expert was analysed by the knowledge engineer using the following method. The knowledge engineer was provided
Diagnosing diseases, pests and non-parasitic disorders
61
with a sample of a diseased plant. The sample was not visible to the expert, this prevented him from drawing conclusions without explicitly asking for the information required. The knowledge engineer and expert were connected by a computer terminal. Questions and answers had to be written down. In this way it was possible to study not only the procedures followed, but also the terminology used by the expert. Writing down descriptions meant that they had to be clear, vague descriptions immediately requested clarification. This audio-method made it clear that an expert initially always asked basic questions: “Do you have a plant or a dry bulb?” “What part of the plant is diseased. 7” “Is there discoloration of the leaves.” The expert was obviously reasoning searching for a goal. This is called forward chaining. He was looking for a hypothesis. At first the most common diseases came to his mind and only when no solution was found would he come up with more rare diseases. So diseases were filed in his head in a certain order. This process ended by stating an hypothesis. At this point the questions became specific and detailed: “Are there small round spots on the upperside of the outer leaves?” He was now trying to confirm his hypothesis. This way of reasoning is called backward chaining, starting from the goal (Fig. 3). It also became clear which information was important and which was not. The expert always asked for the location of a symptom, while the pattern of rot for example was hardly ever important. The expert made no conscious difference between symptoms and attributes of symptoms. Rules concerning order of importance were put together. These rules were incorporated in the knowledge base and used by the inference mechanism to reduce the number of relevant questions as far as possible. Developing a knowledge structure To achieve a well organized knowledge base, it is necessary to develop an explicit structure capable of describing all diseases. This required many consultations between the expert and the knowledge engineer, resulting in the entity relation diagram given in Fig. 4. Form A disease can have different appearances, depending on the developmental stage of the plant or the disease. An appearence is called a form. So a disease may have one or more forms. A form contains a description of the origin of the sample, the so-called context, and one or more symptoms of the disease present on the sample.
62
M. A. Kramers, C. G. M. Con&, C. Bastiaansen
Backward
Confirm
chaining
I I I I
hypothesis
Fig. 3. Basic structure of diagnosing.
Context Knowledge of the context of the sample is necessary to diagnose the disease correctly. For example the type of crop, growing stage, type of soil, time of year and appearance of the disease in the field. A set of values belongs to every aspect of the context, so called attributes. Symptom A list of all possible symptoms was made. Each symptom has its own list of attributes that can describe the symptom as comprehensively and in as much detail as necessary. Descriptions needed to be sufficiently detailed to be distinguishable. Attribute Attributes are the characteristics of symptoms or context. For example, the symptom discoloration has the attributes location, colour, pattern, edge and sunken. Every attribute can have different values.
Diagnosing diseases, pests and non-parasitic disorders
63
Fig. 4. Entity relation diagram of the knowledge structure of EXSYS.
Value Values belong to an attribute. For example the pattern of the discoloration can be stripes or dots, the location is leaf tips and the colour is yellow: so the discoloration is described as yellow stripes or dots on leaf tips. Values are organized in tree structures. Each value has one or more successors. A value can have a predecessor (Fig. 5). Strong smell is a successor of a smell. A smell is predecessor of faint smell and strong smell. When more values are given to an attribute in the database it means that all these values are possible.
64
hf. A. Krmers,
C. G. M. Conijn, C. Bastiaansen
Faint smell / A smell Strong smell Smell
No smell
<
Fig. 5. Tree-structure
of values of attribute smell.
Collecting disease descriptions For this phase of the development domain experts were frequently consulted. Diseases of bulbous iris were described, with the developed knowledge structure, using slides of the different symptoms and other information (Anonymous, 1978, 1995). Images derived from the slides were filed as bitmaps. This was initially done by the knowledge engineer and one expert. The results were evaluated by a group of eight experts, all working at the Bulb Research Centre. Building a prototype Building a prototype was necessary in order to be able to test the inference mechanism, to discuss terminology in practice and to validate the system.
THE KNOWLEDGE
BASE
The knowledge base described 68 diseases of bulbous iris in the Netherlands. They are listed in Appendix A. The knowledge base contains 137 forms, 319 symptoms and 120 contexts. Knowledge is represented as frame structures. The knowledge base contains values and rules, all built in these frames. There is a list of tolerated value combinations. The knowledge base is augmented by images and additional remarks. Viruses can be treated separately. All these items will be discussed. Values and rules Rules decide in which order values are consulted. incorporated in the knowledge base:
There are three rules
1. diseases are divided into five categories of occurrence, 2. symptoms have a state of importance, and 3. attributes have a state of importance.
Diagnosing diseases, pests and non-parasitic disorders
65
Categories of diseases
The domain expert divided the diseases into five categories of appearance. Category 1 contains the most current diseases like Bulb rot (F. oxysporum), Iris mild mosaic virus and mechanical damage. Category 5 contains the rarest diseases like bulb mite and Phytophthora rot (Phytophthora). The system will start its research in the group of the most current diseases. If no hypothesis can be found the next category of diseases will be checked, etc. This shortens the average diagnosing time. Symptoms and their state of importance
A form contains a context and at least one symptom. One symptom is more important than another. To deal with this, every symptom belonging to a form receives a ‘state of importance’. ‘Crucial symptoms’ must be present, ‘probable symptoms’ are most likely present and ‘possible symptoms’ may occur. If all crucial symptoms are present, the diagnosis is complete. If a crucial symptom is absent, the description of the disease does not match. The disease can still be diagnosed because one disease can be described by several forms. The probable and possible symptoms are confirmatory but noncrucial symptoms for the diagnosis. Beside crucial, probable or possible, a symptom can be ‘specific’ or ‘nonspecific’ for one disease. If a specific symptom is present, the disease is present and the diagnosis is complete. A specific symptom is not always crucial, so absence of this symptom does not exclude the disease. Table 1 shows an example of a form of Rhizoctoniarot, Rhizoctonia solani. Attributes and their state of importance
A symptom has several attributes. The attributes are not all of the same importance. They are divided into six levels of decreasing importance. For example Table 2 shows the levels of symptom rot. Location is the most important, pattern and characteristic are the least important. It is possible to define the number of levels to be checked by the system, during diagnosis, depending on the state of a symptom in the case. Of a crucial symptom the user probably wants to examine more levels than of a likely symptom, for example Levels l-5 respectively l-3. A less detailed diagnosis, however, increases the chance of getting a wrong diagnosis. Tolerated value combinations The knowledge base includes a list of tolerated value combinations. These are values that differ so little that the system accepts them while matching values. For example ‘faint smell’ is hardly to be distinquished from ‘no
66
44. A. Kmners, C. G. M. Conijn. C. Bastiaansen
TABLE 1 A Form of Rhizoctonia-rot (Rhizoctonia solani) Rhizoctonia rot Context
Rhizoctonia solani crop and production manifestation in the field development stage
Rot
location colour solidity smell edge sunken
Hyphal threads
location colour thickness amount
CNStS
location size outer colour shape and attachment
State Dutch iris, production of flowers patches post emergence shoot, bulbnose, on outermost scales grey brown, light brown weak no smell smooth no
crucial
shoot, bulbnose, on outermost scales, on rot brown, white medium moderate
probable
shoot, bulbnose, on outermost scales, on rot l-5 mm brown irregular and loose
possible
smell’. Therefore ‘faint smell’ and ‘no smell’ are acceptable variances, so called ‘tolerated values’. Frame structures Knowledge is represented in the form of frame structures. These frame structures contain lists of undefined length. Every symptom can have its own number of attributes, every attribute can have its own number of values. Extra attributes or values can easily be added to the frames. The most important frames are symptom, context, form and successor. Table 3 shows the structure of these frames. An example is added to every frame in the table. The frame ‘Symptom’ describes one symptom, and contains five elements: 1, the symptom number; 2, the symptom name; 3, the list of relevant attributes and for every attribute a list of relevant values; 4 and 5, both states of importance (‘State_of_symptom’ and ‘Specific’). The frame ‘Context’ describes the context, and contains 3 elements: 1, the context number; 2, the context name; 3, the list of relevant attributes and for every attribute a list of relevant values.
Diagnosing diseases, pests and non-parasitic disorders
67
TABLE 2
Symptom Rot and its Levels Symptom name: rot Level
Attribute name
Location Colour Solidity Smell Edge Sunken/swollen Pattern Characteristic TABLE 3
Frame Structures, Elements and Examples Name of frame
Symptom
Example
Elements
(symptom_number, symptom_name_with_attributes [attribute_namel-[list_of_values], attribute_name2-[list_of_values], state_of_symptom,
etc.],
specific”).
(~228, colouring with-attributes [location-[bulb, bulbfoot], colour-[brown], border-[sharp], sunken-[moderately] 1, probable).
Context
(context_number, context_name_with_attributes [attribute_namel-[list_of_values], attribute_name2-[list_of_values],
Form
(form-number, disease, context_ number, [list of symptom numbers]).
(f12, Fusarium oxysporum f. sp. Gladioli, ~12, [s24,s228,s248]).
Successor
(symptom-name, attribute-name, value, successor)
(colouring, location, bulb, bulbfoot).
(cl2, [crop-[iris], stage of growth[‘dry bulb’], season-[autumn, etc.]). winter, spring], appearance[widespread]]).
“Only added to specific symptoms.
The frame ‘Form’ connects each disease to the relevant context and symptoms, and contains 4 elements: 1, form number; 2, name of disease; 3, context number; 4, set of symptom numbers, represented as list. The frame ‘Successor’ contains 4 elements. 1: the symptom name. 2: the attribute name. 3: the value. 4: the successor of the value. The frame ‘Successor’ describes the tree-structure of the values. Images Symptom descriptions are completed with images and filed as bitmaps. These images can be generated on request. They proved to be very important with
68
hf. A. Kramers, C. G. M. Conijn, C. Bastiaansen
regard to explaining questions the system asks and to evaluating conclusions given by the system. So far 247 images have been added. Every symptom in the knowledge base will eventually be provided with at least one image. Additional remarks Additional remarks by the experts have been added to some forms. This is information that could not be described by the developed structure, for example “Severe symptoms of Iris mild mosaic virus with grey-necrotic small spots and small stripes at leaf tips can be distinguished from light symptoms of Narcissus latent virus by Elisa tests.”
viruses Viruses can be excluded from the list of possible hypotheses. The user is not always interested in viruses and excluding them can reduce the number of questions.
THE INFERENCE
MECHANISM
The inference mechanism is the part of the system containing the problemsolving logic. Figure 6 gives an overview of the inference mechanism. The processes in the flowchart are described in the text below. Each process is illustrated by corresponding steps of the diagnosis of R. solani, described earlier. Appendix B gives an overview of this diagnosis session. Description of a sample Easily accessible input screens give the user the opportunity to describe the context and the symptoms that can be recognized on the sample. The user can put in as much description and detail as they want. The context can only be described in this phase of the program. No questions will be asked about it. The system will only ask about symptoms that are visible on the sample of the crop. The user interface is simple, the user only needs to use a mouse. Of course one must have the ability to discriminate a healthy plant from a diseased plant, and one must be able to describe the symptoms of the diseased plant properly. Diagnosis example: A sample of hisses grown for production of flowers. Diseased plants were found in patches in the field, post emergence. The user identified a rot of bulb noses which are weak and brown, with brown crusts on the outermost scales of bulbs. The users input will be as shown in Fig. 7.
Diagnosing diseases, pests and non-parasitic disorders
69
Fig. 6. A global flowchart of the inference mechanism of EXSYS.
Selection of set of input symptoms With the initial set of symptoms, the system will look for a disease that can explain as many symptoms as possible, in the given context. To do this, the system will first look for a disease that can explain all the symptoms. If there is no such disease, it will look for a disease that can explain all but one symptoms, etc., until it finds a possible disease. This is a permitted hypothesis. The hypothesis will be examined resulting in a rejected or accepted
70
M. A. Kramers, C. G. M. Conijn, C. Bastiaansen
context:
symptom
crop:
iris
production:
production of flowers
manifestation in the field:
patches
development stage:
post emergence
location
bulbnose
colour
brown
solidity
weak
location
on outermost scales
outer colour
brown
I:
rot
symptom 2: crusts
Fig. 7. User input of diagnosis example.
hypothesis. After that a new hypothesis will be sought. If no new hypothesis can be found for the current set of input symptoms, a new set of input symptoms will be dealt with. For example: there are three input symptoms, Sl, S2 and S3. The following sets of input symptoms will be checked for possible diseases: {Sl,S2,S2}, {Sl,S2}, {Sl,S3}, {S2,S3}, {Sl}, {S2}, (S3). If all sets have been checked and only the empty set is left, the diagnosis is completed. If, however, a hypothesis is accepted and one of the symptoms of the declared set is specific, previous accepted hypotheses that are based on (a set of) these same symptoms will still be rejected. The diagnostic procedure will continue with only the undeclared input symptoms. Diagnosis example: The following sets of symptoms will be explained: {rot, crusts}, {rot} and {crusts}. The first set can be explained by R.sohi. If hyphal threads are identified on shoot, bulb nose or outermost scales, the sets {rot} and {crusts} need no further investigation because hyphal threads are specific to R. sohni and all input symptoms are explained. However, since there are no hyphal threads on this sample every set will be examined. Determination of hypothesis To determine a hypothesis the first form of a disease is chosen from the knowledge base. The system has to find out whether this form can explain the set of input symptoms. To do so, every input symptom must have a
Diagnosing diseases, pests and non-parasitic disorders
71
similar knowledge-base symptom from the selected form. The system will check if all combinations of input symptoms and knowledge-base symptoms match. If they do not match, the hypothesis is rejected and the next form of the disease is selected (until all forms have been selected). If they do match, the system still has to check the state of importance of the symptoms. If all symptoms are possible, the hypothesis is declared unlikely and therefore rejected. Otherwise, if the set of input symptoms contains a crucial or probable symptom, the system has found a permitted hypothesis. Diagnosis example: The first hypothesis is R. soluni. In this form R. solani is described by three symptoms: rot, hyphal threads and crusts. Explained input symptoms are rot and crusts with, according to this form, status crucial and possible. The second hypothesis that the system comes up with is F. oxysporum. F. oxysporum can only explain the input symptom rot. Taking a form of disease Diseases are divided into five categories of occurrence. The system will start its procedure with the first form of the first disease of Category 1. All forms and all diseases will be reviewed in order. The most likely hypothesis will be found first, but eventually all possibilities will be checked. There are a few exceptions. If a disease is concluded, other forms of this disease will be skipped by the system. If the user excludes diseases during consultation, if for example he declares that the sample does not suffer from Ink spot (Drechslera iridis), all forms describing Ink spot will consequently be skipped by the system. Matching set of input symptoms to form To match the set of input symptoms to the selected form, all symptom combinations and the context combination must fit. The context is handled in a similar way to symptoms. A knowledge-base symptom and an input symptom match if they have the same symptom name, like rot, and all attributes match. An attribute matches if one value in the knowledge base matches with one value in the input, or if either knowledge base or input attribute is given no value. Table 4 shows two matching symptoms. The knowledge base value matches the input value if both are on the same route/branch of the tree structure of the attribute values. So the knowledge base value and the input value are equal, the input value is a predecessor of the knowledge base value or it is its successor. The values also match if they are tolerated values. Table 5 shows some possible value combinations and
72
M. A. Kramers, C. G. M. Con@, C. Bastiaansen
TABLE 4 A Knowledge Base Symptom of Rot Matching an Input Symptom of Rot Attributes to rot Location Solidity Edge Smell
Knowledge base symptom
Input symptom
bulbnose weak sharp
bulbnose weak no smell
TABLE 5 Example of Possible Value Combinations Input value
Knowledge base value
A smell No smell Strong smell No Smell
faint smell faint smell a smell strong smell
predecessor tolerated successor
match match match no match
the fact that they do or do not match. The table also shows whether the knowledge base value is equal, predecessor, successor or tolerated to the input value. Figure 5 shows the tree structure of the values of attribute smell. Diagnosis example: Input-information is matched to database-information (Fig. 8). Hypothesis is R. solani. All values match. Examining the hypothesis The hypothesis of the system is based on a selected form in the knowledge base that matches a set of input symptoms. To confirm the hypothesis, the system will take three steps: check the symptoms, ask questions and evaluate answers. Checking the symptoms means that the system will check whether the input contains all symptoms from the knowledge base and if important attributes are missing. If they are, the system will ask the user questions to complete missing values of the symptoms of the sample. The answers will be evaluated to examine whether the hypothesis will be rejected or accepted. An hypothesis will only be accepted if all symptoms of the selected set of input symptoms match the knowledge base. Checking symptoms The system will now check the symptoms for important missing information. To do so, it will first check the specific symptoms, then the crucial symptoms and finally the non-crucial, probable and possible symptoms.
Diagnosing diseases,pests and non-parasiticdisorders
73
Hypothesis: Rhimctonio solani.
input value
database value
match
crop:
iris
Dutch iris
pr&cessor
production:
production of flowers
production of flowers
equal
manifestation in the field:
patches
patches
equal
development stage:
post emergence
post emergence
equal
bulbnose
shoot, bulbnose,
equal
attribute name context
rot location:
on outermost scales WY brown,
predecessor
light bmwn solidity:
weak
weak
on outermost scales
shoot, bulbnose, on rot, equal
equal
on outermost scales outer colour:
brown
Fig. 8. Matching input-information
brown
equal
to database-information.
Examining specitic symptoms If the hypothesis contains a specific symptom, the system will check whether this symptom has been reported. If it has, the system will look for additional attributes and values that have not been mentioned. If the specific symptom has not been mentioned, the system will ask if this symptom, name and location, is present. If a specific symptom is confirmed, than the hypothesis will become a diagnosis. If there is no specific symptom or if a specific non-crucial symptom did not match, the system will continue its research and check if all the crucial symptoms of the hypothesis are present.
M. A. Kramers, C. G. M. Con@, C. Bastiaansen
74
Diagnosis example: The system will ask whether there are hyphal threads on the shoot, bulbnose or on the outermost scales. The answer is no. Since hyphal threads are specific but not crucial, research will continue. Examining crucial symptoms If a crucial symptom is not present, or if it does not match, the hypothesis will be rejected. If all crucial symptoms match the diseased sample, the system will check if the plant also explains the non-crucial, reported, symptoms. Diagnosing example: For R. soZani rot is a crucial symptom. The system will check all attributes of rot, up to level 5 (Fig. 9). There is only one crucial symptom and it matches. Examining probable and possible symptoms A non-crucial symptom is probably or possibly present. This difference is only important in their level of research. If a non-crucial input symptom does not match the knowledge base, the hypothesis will be accepted for a smaller set of input symptoms, excluding the non-crucials. Diagnosis example: For R. solani crusts is a possible symptom. The system will check all attributes of crusts, up to research level 2. No question is asked regarding location (level 1) and colour (level 2), which are already known. Matching symptoms If a knowledge-base symptom is not yet described by the user, the system will ask if the symptom, name and location, is present on the sample. The system will match the input-knowledge base combinations as detailed as defined in Rot on bulbnose: Question: are following values correct?
Answer:
attribute
input
VdW
colour
brown
grey brown
yes I no I maybe
light brown
yes I no I maybe
yes
smell
no smell
yes / no I maybe
Yes
edge
smooth
yes I no I maybe
yes
sunken
no
yes /no I maybe
yes
Fig. 9. Checking all attributes of rot of Rhizoctonia solani up to level 5.
15
Diagnosing diseases, pests and non-parasitic disorders
the level of research. These levels of research are different for all states of symptoms. They can be adjusted if necessary. The values of knowledge-base symptom and input symptom will be compared for each attribute. If an equal value is found or an input value is successor to a knowledge-base value, the attribute matches and no questions will be asked. If an input value is predecessor of a knowledgebase value, the system will ask if the detailed value in the knowledge-base is correct. If all input values of an attribute differ from the knowledgebase values, the attribute does not match and hence the symptom does not match. If an input value is a tolerated value of a knowledge base value, the system will ask if the knowledge-base value is correct. If no value is given during input, the system will ask for all possible knowledge base values. All questions will be gathered in one question-screen per symptom. Table 6 shows examples of all possible input-knowledge base combinations while matching values, using attribute smell (Fig. 5) of symptom rot, with the questions and conclusions. Asking questions
As described in Matching symptoms the user may expect two types of questions. One: the system asks for a new symptom, e.g. are there crusts visible on the outer bulb scales? Two: the system asks for missing or incomplete values of an already recorded symptom, e.g. are crusts on the outer bulb scales round in shape, size 3 mm and is the outer colour white? The user can answer every value asked with ‘yes’, ‘no’ or ‘maybe’. All extra knowledge of the diseased crop that is added by the user during a session is recorded and will be taken into account during the diagnosis process. So no questions will be repeated.
Examples of Value Combinations
TABLE 6 While Matching Attribute Smell of Symptom Rot
Input value
Kn. base value
Question (type)
Strong smell A smell
strong smell strong smell
is strong smell correct?
equal value predecessor
Faint smell Not ‘a smell No smell
a smell a smell faint smell
is faint smell correct?
successor ‘not’ value tolerated
faint smell
is there a faint smell?
no input value
Matching
Conclusion
match yes, match no, no match match no match yes, match no, no match yes, match no, no match
76
M. A. Kramers, C. G. M. Conijn, C. Bastiaansen
Evaluate answers After every question screen the system will evaluate answers to prevent unnecessary questions. Evaluation is executed per attribute. The system will first check ‘yes’ or ‘maybe’ answers and secondly ‘no’ answers. Finding a value with yes or maybe answer If ‘yes’ or ‘maybe’ is the answer for a value, the attribute matches. If no answer is given, the attribute still matches. If questions are not answered they can, of course, be asked again. Finding only ‘non’ values If no positive answer is given and one or more values are not present, the attribute is not matching so the symptom does not match.
VALIDATION Phase 1 The system was first tested for iris by approximately 20 researchers at the Bulb Research Centre and 8 experts in the bulb sector. These tests produced encouraging results. Table 7 shows the diseases diagnosed during these sessions. On average the system asks five questions per session. Figure 10 shows the number of questions asked in 54 registered test sessions. The number of questions did not depend on the number of input symptoms. The average working time of the system, this is waiting time for the user, was about 6 seconds, the maximum working time was about one minute. In this phase the system made about 65% error-free diagnoses. In the other 35% of the cases the diagnosis was insufficient, mostly due to incompleteness of the knowledge base. All failures made during testing can be reduced to interpretation differences by individuals. Three examples will illustrate the nature of misclassification that occurred. Example I
A dry bulb sample suffers from Ditylenchus destructor. There are brown stripes on bulb scales and tunic (Fig. 11). Hypothesis
F. oxysporum and Drechslera iridis. EXSYS will not come up with Ditylenchus destructor because the user interpreted the brown stripes on the bulb scales and tunic as discoloration although it was rotting.
Diagnosing diseases, pests and non-parasitic disorders
77
TABLE 7 Diseases and the Number of Times They Occurred During Testing Number of sessions
Name of disease
Black slime (Sclerotinia sclerotiorum) Blue mold (Penicillium hirsutum) Bud blasting Bulb rot (Fusarium oxysporum) Crown rot (Scleotium rolfsii) Grey bulb rot (Rhizoctonia tuliparum) Grey mold (Botrytis cinerea) Ink spot (Drechslera iridis) Iris severe mosaic virus Leaf dehydration Leaf spot (Heterosporium gracile) Mealy bug (Phenacoccus avenae) Mechanical damage Narcissus latent virus Nematode disease (Ditylenchus destructor) Phytophthora rot (Phytophthora) Rhizoctonia rot (Rhizoctonia solant) Root rot (Pythium) Soft rot (Erwinia carotovora) Storage moth (Plodia interpunctella) Stripe disease (Pseudomonas)
,5
. .._...__..._..._...__.._...............__....__
1
1 2 3 4 5 6 7 6 91011121314151617161920 numberofquestiono
Fig. 10. Number of questions in 54 sessions.
3 8 2
1 1 3
1 1 4 1 4 2 4 4 1 2 6 2
1 2 1
M. A. Kramers, C. G. M. Con@, C. Bastiaansen
78
Input:
context
discoloration
Fig.
crop
iris
development stage
dry bulb
location
bulb scales and tunic
colour
brown
pattern
stripes
11. User input of a sample suffering from Ditylenchus destructor.
SoZution Since this misjudgement is understandable (there is after all a discoloration caused by rot), the disease description will be completed with discoloration of bulb scales and tunic with status ‘probable’. Rot of bulb scales remains the crucial symptom. The complete knowledge base was checked for this type of misunderstanding. Example 2 A sample suffers from Penicillium hirsutum. It has soft, bluish grey rot on its bulb base which is slightly sunken. There are poor plants and occasionally no lifting in the field (Fig. 12). Hypothesis Penicillium hirsutum. Question I: Is there mold on the bulb base? Answer: No. Mold is a specific but non-crucial symptom for P. hirsutum so the hypothesis is not (yet) rejected. Input:
context
rot
retarded growth
crop
iris
development stage
post emergence, pre flowering
production
flower production
location
bulb base
colour
bluish grey
solidity
soft
sunken
slightly
degree
no lifting, poor plants
Fig. 12. Input description of a sample that suffers from Penicillium hirsutum.
Diagnosing diseases, pests and non-parasitic disorders
19
Question 2: (Table 8) Is the edge of the rotten area on the bulb base smooth? Answer: Yes. Question: Is the rotten area ‘not sunken’, instead of ‘slightly sunken’? Answer: No. Hypothesis will be wrongly rejected. P. hirsutum causes rot of the bulb
base that can be slightly sunken, so the knowledge base was too limited. It needed to be adjusted. This type of failure was the most difficult to find. Example 3
A sample suffers from Sclerotinia sclerotiorum. There are patches in the field. There is brown, grey and soft rot on the bulbs (see input in Fig. 13). Hypothesis S. sclerotiorum Question: Are there hyphal threads on bulb or foliage? Answer: No The hypothesis S. sclerotiorum will be accidently rejected because hyphal threads is a crucial symptom for S. sclerotiorum. The user did not recognize
the thin white hyphal threads. This type of failure shows that the user must have some knowledge of plant diseases. TABLE 8
Question Screen: Rot on Bulbbase Caused by Penicillium hirsutum Attribute
Input value
Knowledge base value
Correct?
Answer
-
smooth no
yes/no/maybe yes/no/maybe
yes no
We Sunken
slightly
Input: context
rot
crop
iris
development stage
post emergence, pre flowering
manifestation
patches in the field
location
bulb
colour
brow
solidity
soft
PY
Fii. 13. Input description of a sample that suffers from Sclerotinia sclerotiorum.
M. A. Kramers, C. G. M. Conijn. C. Bastiaansen
Phase 2 After the first tests the system was installed at 12 locations in the Netherlands: the Flower Bulb Inspection Service, the crop protection trade, the flower bulb extension service and iris preparation companies. The participants in this test phase were experts as well as semi-experts on iris diseases. The system was used for one year. The participants were asked to pay attention to the following aspects: user-friendliness, structure of the input menu, logic of questions, faith in conclusions, terminology, completeness of knowledge base and practical value. The objective was to trace the faults and shortcomings of the knowledge base. When the number of failing diagnosis sessions can be reduced to less than 5%, and the system’s practical value has been sufficiently proven, it will be decided whether or not extension to other crops is desirable. During the year of testing not every disease passed the system. The semiexperts used the system far more often than the experts. Unfortunately, semi-experts do not have enough knowledge to assess the contents of the knowledge base. These two aspects make it impossible to estimate the success percentage of the entire system. However, the sessions that were run, were error-free. The system was judged user-friendly. The input menu proved to be easy to use. Questions were said to be understandable and logical. Semi-experts, generally, had enough confidence in the conclusions of the system. The terminology was clear. All remarks made were collected and used to improve the system. Each participant was positive about the practical use of the system and insisted on extending the development of EXSYS to other crops. It was recently decided to proceed with the project, starting with tulip.
DISCUSSION
AND CONCLUSIONS
A question that always arises is why crop protection advice is not added to the diagnostic conclusions. Crop protection is an expertise on its own, and is constantly liable to change. EXSYS is restricted to diagnosis. Compared to crop protection advice, it will need little maintenance. Once the descriptions of the diseases are made, they will hardly ever change and modifications therefore will be minimal. Descriptions of new diseases and additional images will of course need to be added from time to time. Another question that is often asked is whether expansion to include other crops is possible. Yes, it is. Descriptions of diseases (the knowledge base), and diagnostic expertise (the inference mechanism), are separately stored and
Diagnosing diseases,pests and non-parasiticdisorders
81
separately maintained. The knowledge base can therefore easily be expanded without changing the inference mechanism. The inference mechanism can be used for all (bulb) crops, without further modifications. It was recently decided to proceed with the project. The knowledge base will be extended for tulips. The number of diseases known for tulips in The Netherlands is about twice the number of diseases known for iris. Potential users of the system are researchers, advisors of extension services, large farmers, bulb dealers, crop protection dealers and schools. Expert systems can easily be used as a training facility since they contain the necessary knowledge and the ability to explain their reasoning processes and actions (Stewart, 1992).
ACKNOWLEDGEMENTS We would like to thank Marco Balvers (Balvers, 1990) and Maarten Ketelaars (Ketelaars, 1991) for their contribution. They have participated in this research project as part of their studies at the Technical University in Eindhoven.
REFERENCES Adams, S. S., Stevenson, W. R., Delhotal, P. and Fayet, J. (1990) An expert system for diagnosing post-harvest potato diseases. Bulletin OEPPIEPPO 20, 341-347.
Anonymous (1978) Ziekten en Afwijkingen bij Bolgewassen, Dee1 1. Liliaceae. Laboratoxium voor Bloembollenonderzoek, Lisse, The Netherlands. Anonymous (1995) Ziekten en Afwijkingen bij Bolgewassen, Dee1 2. Amaryllidacea, et al. Laboratorium voor Bloembollenonderzoek, Lisse, The Netherlands. Balvers, M. A. H. (1990) DIABOL: Systeemspeczficatie, Gebruikers Handleiding en Bijlagen. Afstudeerverslag Technische Universiteit Eindhoven, Faculteit Wiskunde en Informatica. Blancard, D., Bonnet, A. and Coltno, A. (1985) TOM, un systeme expert en maladies des tomates. P.H.M. Revue Horticole 261,7-14. Bratko, I. (1988) Prolog Programming for Arttjicial Intelligence. Addison-Wesley, Wokingham, UK. Coelho, H. and Cotta, J. C. (1988) Prolog by Example. Springer, Berlin. Cooley, D. R. (1988) Expert systems: a new tool for plant pathologists. Plant Disease 72, 279.
Dodd, T. (1990) Prolog: a Logical Approach. Oxford University Press, Oxford, UK. Ketelaars, M. W. A. M. (1991) DESZ, bet ontwerp van een Diagnose-ExpertSysteem voor het gewas Iris. Afstudeerverslag Technische Universiteit Eindhoven, Faculteit Wiskunde en Informatica.
82
M. A. Kramers, C. G. M. Conijn, C. Bastiaansen
Kramers, M. A., Conijn, C. G. M. and Bastiaansen, C. (1993) Ontwikkeling van een Ziektediagnose-Expertsysteem. Annual Report, Bulb Research Centre Lisse, The Netherlands, pp. 38-41. Kramers, M. A., Conijn, C. G. M., Bastiaansen, C. (1994~) Ontwikkeling van een expertsysteem voor ziektediagnose. Agro Informatica 713, 21-24 Kramers, M. A., Conijn, C. G. M. and Bastiaansen, C. (1994b) Ziektediugnose per computer. Vakblad voor de bloemisterij 11: pp. 34-35, Vakwerk 10: pp. 44-45, and Bloembollencultuur nr 16: pp. 40-41. Latin, R. X., Miles, G. E. and Rettinger, J. C. (1987) Expert systems in plant pathology. Plant Disease 71, 866872. Latin, R. X., Miles, G. E., Rettinger, J. C. and Mitchell, J. R. (1990) An expert system for diagnosing muskmelon disorders. Plant Disease 74, 8387. Michalski, R. S. and Davis, J. H. (1983) A computer-based advisory system for diagnosing soybean diseases in Illinois. Plant Disease 67, 459-463. Plant, R. E., Zalom, F. G., Young, J. A. and Rice, R. E. (1989) CALEX/Peaches, an expert system for the diagnosis of peach and nectarine disorders. Hortscience 24, 700. Ramon, M. C. U. and Roland, F. (1994) An expert advisory system for wheat disease management. Plant Disease 78,209215. Roach, J. W., Virkar, R. S., Weaver, M. J. and Drake, C. R. (1985) POMME, a computer-based consultation system for apple orchard management using Prolog. Expert Systems 2, 56-69. Stewart, T. M. (1992) DIAGNOSIS, a microcomputer-based teaching aid. Plant Disease 76, 644647. Travis, J. W. and Latin, R. X. (1991) Development, implementation, and adoption of expert systems in plant pathology. Annual Reviews Phytopathology 29, 343360. Waterman, D. A. (1986) A Guide to Expert Systems. Addison-Wesley, Wokingham, UK.
APPENDIX
A
List of all described diseases of iris, added to the knowledge base of EXSYS
Fungi:
Grey bulb rot (Rhizoctoniu
tuliparum)
Bulb rot (F. oxysporum) Root rot (Pythium) Blue mold (Penicillium hirsutum) Rhizoctonia rot (R. solam) Grey mold (Botrytis cinerea) Crown rot (Sclerolium rorfiz) Leaf spot (Heterosporium gracile) Ink spot (Drechsleru iridis)
Diagnosing diseases, pests and non-parasitic disorders
Bacteria: Viruses:
Animal organisms:
Chemical damage:
Crown rot (Sclerotium rolfsii var. delphinit) Phytophthora rot (Phytoph thora) Rust (Puccinia iridis) Black slime (Sclerotiniu sclerotiorum) Black slime (Sclerotinia bulborum) Black leg (Sclerotium wakkerz) Reticulata rot (Altenaricz) Rhizopus rot (Rhizopus arrihizus) Stripe disease (Pseudomonas) Soft rot (Erwinia carotovora) Iris mild mosaic virus Narcissus latent virus Iris severe mosaic virus Bean yellow mosaic virus Tomato spotted wilt virus Wire worm (Agriotes species) Aphid (Aphidoidae) Leather jacket (Tip& species) Nematode disease (Ditylenchus destructor) Lesion nematode (Pratylenchus penetruns) Bean fly (Delia plutura) Tulip bulb aphid (Dysaphis tulipae) Snail, slug (Deroceras/arion) Mealy bug (Phenacoccus avenue) Root-knot nematode (Meloidogyne) Cutworm (Agroitis) Thrips (Taeniothrips atratusl-simplex) Storage moth (Plodia interpunctella) Leaf nematode (Aphelenchoides subtenuis) Bulb mite Caterpillar Asulan damage (Asulox) Phosphorus damage Gas damage Kasumin damage (kasugamycine) Gramoxone damage Sooted foliage Dimethachlorine damage Borium damage Formaline damage Methyl bromide damage Herbicide damage
83
84
M.
Non-parasitic
causes:
Unknown causes:
A.
Kramrs,
C. G. M. ConlQn,C.
Bastiaansen
Bud blasting Mechanical damage Blindness Gummosis Root damage Dead leaf tips Heat damage Frost damage More leaves Leaf dehydration Snapping Subtunic root growth Morfological defects Burst bulbs Flower discoloration Bulb base corking Head bud dehydration Soft bulb rot
APPENDIX
B
A complete diagnosis session The sample suffers from R.sohni. Input by user: context:
crop: production: manifestation in the field: development stage:
iris production of flowers patches post emergence
rot
location colour solidity
bulbnose brown weak
crusts
location outer colour
on outermost scales brown
EXSYS starts its research.
Diagnosing diseases, pests and non-parasitic disorders
85
Hypothesis: R. solani Question: Are there hyphal threads on shoot, bulbnose or on outermost scales? Answer: no Question: Are following values correct? Rot on bulbnose: attribute input colour brown smell edge sunken
Answers value grey brown light brown no smell smooth no
yes/no/maybe yes/no/maybe yes/no/maybe yes/no/maybe yes/no/maybe
yes Yes yes yes
R. solani is confirmed. EXSYS continues its research. Hypothesis: F. oxysporum Question: Is there deformation (ridges) on subterranean Answer: no Question: Are following values correct? Rot on bulbnose: attribute input edge sunken no
shoot?
Answers value sharp slightly
yes/no/maybe yes/no/maybe
no no
F. oxysporum is rejected. EXSYS can find no other possible diseases. Consultation
is finished.
Agricultural Sysrem, Vol. 58, No. 1, pp. 57-85, 1998 0 1998 Elsevier Science Ltd. All rights reserved Printed in Great Britain 0308-521X/98 %19.00+ 0.00 SO308-521X(98)00046-8
ELSEVIER
EXSYS, an Expert System for Diagnosing Flowerbulb Diseases, Pests and Non-parasitic Disorders M. A. Kramers,* C. G. M. Conijn & C. Bastiaansen Bulb Research Centre, PO Box 85, 2160 AB, Lisse, The Netherlands (Received 3 April 1997; accepted 24 March 1998)
ABSTRACT When a commercial crop shows disease symptoms, it is important to make an accurate diagnosis to support control strategies. Diagnosing diseases in Jlowerbulbs requires considerable expertise. Only a few experts have the ability to do this, and each expert has his own specific domain. To retain expertise and to make it more generally accessible, an expert system, called EXSYS, has been developed. EXSYS contains disease descriptions and ofleers the ability to diagnose diseases in flowerbulbs. Digitalized photographic pictures of disease symptoms can be shown by the system to support an interacting session. This article describes the development of EXSYS, the structure of the knowledge base and the inference mechanism. A prototype has been built for diagnosing diseases in bulbous iris. Preliminary tests of this prototype at the Bulb Research Centre indicate that descriptions of observations can vary considerably between individuals. Adaptations have herefore been made to permit descriptions to d@er from the exact descriptions in the knowledge base. Tests made it clear that a correct and complete knowledge base is necessary to create a successful system. The aim is to reduce the percentage of failures to less than 5%. 0 1998 Elsevier Science Ltd. All rights reserved
INTRODUCTION Bulbous crops can suffer from many diseases caused by fungi, bacteria, viruses, nematodes, insects, mites and from non-parasitic disorders, caused *To whom correspondence should be addressed. 417762; e-mail: [email protected] 57
Tel.:
+ 31-252-462121; fax: + 31-252-
58
M. A. Kmners,
C. G. M. Con@, C. Bastiaansen
by physiological or chemical stress. In this article all disorders will be referred to as diseases. Accurate diagnosis is a prerequisite to control diseases in a crop. Where bulbous crops are concerned only a few experts have enough experience and knowledge of diseases to be able to make an adequate diagnosis. It is desirable to file this expertise. Within the diagnosis process two aspects can be distinguished: disease descriptions and reasoning. Problems that arise, when analysing working procedures of experts, are the diversity in technical terminology, the apparently inconsistent way of thinking and incomplete knowledge. An expert system was developed to compile the knowledge of experts, it compels uniformity of expression, but can cope with a lack of knowledge. This article describes the methods used to develop an expert system called EXSYS. It describes the structure of its knowledge base (disease descriptions) and inference mechanism (reasoning). The validation of the system is discussed and suggestions for further development are given.
EXPERT SYSTEM An expert system is an institutional memory. When key-people leave, their expertise is (partly) retained. (Waterman, 1986; Latin et al., 1987; Cooley, 1988; Travis and Latin, 1991). The system contains knowledge which makes it capable of making decisions. This knowledge is explicit and accessible. It mimics the way of thinking of an expert. Because these systems use heuristics instead of algorithms, they can operate with unknown or incomplete data. Many expert systems have been built for diagnosing diseases in plants (Michalski and Davis, 1983; Blancard et al., 1985; Plant et al., 1989; Adams et al., 1990; Latin et al., 1990) and for disease management (Roach et al., 1985; Ramon and Roland, 1994). Most systems are based on ‘if-then-procedures’ and use tree-structure like determination tables. They are built in a procedural language like PASCAL. However, when databases become larger and searching procedures more complex, these types of programme will become unmanageable, unacceptably slow and hard to modify. To avoid these problems EXSYS (Krammers et al., 1993, 1994a,b); was built in the declarative language PROLOG. PROLOG is based on definitions. This means that the inference mechanism combines separate definitions to compose diagnosing routes. This way of programming is less transparent but more flexible since definitions can be added whenever needed, at any place in the listing. A diagnosing process frequently requires comparison of sets of input data with data in the knowledge base. PROLOG has the ability to search very rapidly through large sets of information. Furthermore PROLOG uses frame structures, containing
Diagnosing diseases, pests and non-parasitic disorders
59
lists (sets) and nested lists. Since these lists have the ability to work with sets of information with an undefined number of elements, the knowledge base is extremely flexible. The nested structure provides an easy overview of the filed knowledge (Bratko, 1988; Coelho and Cotta, 1988; Dodd, 1990). EXSYS is not a determination table. Instead of using a fixed question procedure to reduce the solution area, the system looks directly for the most likely solution area, based on initial input data, which can be entered freely by the user. This prevents recurrence of questions and it reduces the number of questions (Fig. 1). In many systems numerical certainty factors are used to add a certain evidence degree to conclusions of systems (e.g. diagnostic certainty of Fusarium oxysporum is 80% and of Botrytis cinerea 30%). EXSYS does not use evidence degrees, since they are always susceptible to criticism and not absolutely necessary. EXSYS leaves it to the user to be critical about conclusions of the system (e.g. possible concluded diseases are F. oxysporum and B. cinerea). Elements of an expert system An expert system contains a knowledge base, an inference mechanism and a user interface (Fig. 2). The user communicates with the system through the user interface. The user interface passes information on to the inference mechanism. The inference mechanism selects information from the knowledge base. With this information and the user’s input it determines hypothesis and
Determination Follow question procedure: 5 questions asked to minimize the solution area
table
Expert system Go straight to the most likely solution, matching input.
Fig. 1. Finding the solution area.
hf. A. Kramers, C. G. M. Con&, C. Bastiaansen
60
/
EXPERT
fKnowledge base
SYSTEM
‘-
/
/
Inference mechanism
User interface
Fig. 2. Elements of an expert system.
formulates questions. The questions are passed on to the user through the user interface.
METHODS Development of EXSYS can be divided into four parts: 1. 2. 3. 4.
designing the inference mechanism, developing a knowledge structure, collecting disease descriptions, and building a prototype.
The inference mechanism and knowledge structure were developed simultaneously. Necessary changes were made during collection of disease descriptions and the system was even improved during construction of the prototype. Designing the inference mechanism Initially the way of thinking of one expert was analysed by the knowledge engineer using the following method. The knowledge engineer was provided
Diagnosing diseases, pests and non-parasitic disorders
61
with a sample of a diseased plant. The sample was not visible to the expert, this prevented him from drawing conclusions without explicitly asking for the information required. The knowledge engineer and expert were connected by a computer terminal. Questions and answers had to be written down. In this way it was possible to study not only the procedures followed, but also the terminology used by the expert. Writing down descriptions meant that they had to be clear, vague descriptions immediately requested clarification. This audio-method made it clear that an expert initially always asked basic questions: “Do you have a plant or a dry bulb?” “What part of the plant is diseased. 7” “Is there discoloration of the leaves.” The expert was obviously reasoning searching for a goal. This is called forward chaining. He was looking for a hypothesis. At first the most common diseases came to his mind and only when no solution was found would he come up with more rare diseases. So diseases were filed in his head in a certain order. This process ended by stating an hypothesis. At this point the questions became specific and detailed: “Are there small round spots on the upperside of the outer leaves?” He was now trying to confirm his hypothesis. This way of reasoning is called backward chaining, starting from the goal (Fig. 3). It also became clear which information was important and which was not. The expert always asked for the location of a symptom, while the pattern of rot for example was hardly ever important. The expert made no conscious difference between symptoms and attributes of symptoms. Rules concerning order of importance were put together. These rules were incorporated in the knowledge base and used by the inference mechanism to reduce the number of relevant questions as far as possible. Developing a knowledge structure To achieve a well organized knowledge base, it is necessary to develop an explicit structure capable of describing all diseases. This required many consultations between the expert and the knowledge engineer, resulting in the entity relation diagram given in Fig. 4. Form A disease can have different appearances, depending on the developmental stage of the plant or the disease. An appearence is called a form. So a disease may have one or more forms. A form contains a description of the origin of the sample, the so-called context, and one or more symptoms of the disease present on the sample.
62
M. A. Kramers, C. G. M. Con&, C. Bastiaansen
Backward
Confirm
chaining
I I I I
hypothesis
Fig. 3. Basic structure of diagnosing.
Context Knowledge of the context of the sample is necessary to diagnose the disease correctly. For example the type of crop, growing stage, type of soil, time of year and appearance of the disease in the field. A set of values belongs to every aspect of the context, so called attributes. Symptom A list of all possible symptoms was made. Each symptom has its own list of attributes that can describe the symptom as comprehensively and in as much detail as necessary. Descriptions needed to be sufficiently detailed to be distinguishable. Attribute Attributes are the characteristics of symptoms or context. For example, the symptom discoloration has the attributes location, colour, pattern, edge and sunken. Every attribute can have different values.
Diagnosing diseases, pests and non-parasitic disorders
63
Fig. 4. Entity relation diagram of the knowledge structure of EXSYS.
Value Values belong to an attribute. For example the pattern of the discoloration can be stripes or dots, the location is leaf tips and the colour is yellow: so the discoloration is described as yellow stripes or dots on leaf tips. Values are organized in tree structures. Each value has one or more successors. A value can have a predecessor (Fig. 5). Strong smell is a successor of a smell. A smell is predecessor of faint smell and strong smell. When more values are given to an attribute in the database it means that all these values are possible.
64
hf. A. Krmers,
C. G. M. Conijn, C. Bastiaansen
Faint smell / A smell Strong smell Smell
No smell
<
Fig. 5. Tree-structure
of values of attribute smell.
Collecting disease descriptions For this phase of the development domain experts were frequently consulted. Diseases of bulbous iris were described, with the developed knowledge structure, using slides of the different symptoms and other information (Anonymous, 1978, 1995). Images derived from the slides were filed as bitmaps. This was initially done by the knowledge engineer and one expert. The results were evaluated by a group of eight experts, all working at the Bulb Research Centre. Building a prototype Building a prototype was necessary in order to be able to test the inference mechanism, to discuss terminology in practice and to validate the system.
THE KNOWLEDGE
BASE
The knowledge base described 68 diseases of bulbous iris in the Netherlands. They are listed in Appendix A. The knowledge base contains 137 forms, 319 symptoms and 120 contexts. Knowledge is represented as frame structures. The knowledge base contains values and rules, all built in these frames. There is a list of tolerated value combinations. The knowledge base is augmented by images and additional remarks. Viruses can be treated separately. All these items will be discussed. Values and rules Rules decide in which order values are consulted. incorporated in the knowledge base:
There are three rules
1. diseases are divided into five categories of occurrence, 2. symptoms have a state of importance, and 3. attributes have a state of importance.
Diagnosing diseases, pests and non-parasitic disorders
65
Categories of diseases
The domain expert divided the diseases into five categories of appearance. Category 1 contains the most current diseases like Bulb rot (F. oxysporum), Iris mild mosaic virus and mechanical damage. Category 5 contains the rarest diseases like bulb mite and Phytophthora rot (Phytophthora). The system will start its research in the group of the most current diseases. If no hypothesis can be found the next category of diseases will be checked, etc. This shortens the average diagnosing time. Symptoms and their state of importance
A form contains a context and at least one symptom. One symptom is more important than another. To deal with this, every symptom belonging to a form receives a ‘state of importance’. ‘Crucial symptoms’ must be present, ‘probable symptoms’ are most likely present and ‘possible symptoms’ may occur. If all crucial symptoms are present, the diagnosis is complete. If a crucial symptom is absent, the description of the disease does not match. The disease can still be diagnosed because one disease can be described by several forms. The probable and possible symptoms are confirmatory but noncrucial symptoms for the diagnosis. Beside crucial, probable or possible, a symptom can be ‘specific’ or ‘nonspecific’ for one disease. If a specific symptom is present, the disease is present and the diagnosis is complete. A specific symptom is not always crucial, so absence of this symptom does not exclude the disease. Table 1 shows an example of a form of Rhizoctoniarot, Rhizoctonia solani. Attributes and their state of importance
A symptom has several attributes. The attributes are not all of the same importance. They are divided into six levels of decreasing importance. For example Table 2 shows the levels of symptom rot. Location is the most important, pattern and characteristic are the least important. It is possible to define the number of levels to be checked by the system, during diagnosis, depending on the state of a symptom in the case. Of a crucial symptom the user probably wants to examine more levels than of a likely symptom, for example Levels l-5 respectively l-3. A less detailed diagnosis, however, increases the chance of getting a wrong diagnosis. Tolerated value combinations The knowledge base includes a list of tolerated value combinations. These are values that differ so little that the system accepts them while matching values. For example ‘faint smell’ is hardly to be distinquished from ‘no
66
44. A. Kmners, C. G. M. Conijn. C. Bastiaansen
TABLE 1 A Form of Rhizoctonia-rot (Rhizoctonia solani) Rhizoctonia rot Context
Rhizoctonia solani crop and production manifestation in the field development stage
Rot
location colour solidity smell edge sunken
Hyphal threads
location colour thickness amount
CNStS
location size outer colour shape and attachment
State Dutch iris, production of flowers patches post emergence shoot, bulbnose, on outermost scales grey brown, light brown weak no smell smooth no
crucial
shoot, bulbnose, on outermost scales, on rot brown, white medium moderate
probable
shoot, bulbnose, on outermost scales, on rot l-5 mm brown irregular and loose
possible
smell’. Therefore ‘faint smell’ and ‘no smell’ are acceptable variances, so called ‘tolerated values’. Frame structures Knowledge is represented in the form of frame structures. These frame structures contain lists of undefined length. Every symptom can have its own number of attributes, every attribute can have its own number of values. Extra attributes or values can easily be added to the frames. The most important frames are symptom, context, form and successor. Table 3 shows the structure of these frames. An example is added to every frame in the table. The frame ‘Symptom’ describes one symptom, and contains five elements: 1, the symptom number; 2, the symptom name; 3, the list of relevant attributes and for every attribute a list of relevant values; 4 and 5, both states of importance (‘State_of_symptom’ and ‘Specific’). The frame ‘Context’ describes the context, and contains 3 elements: 1, the context number; 2, the context name; 3, the list of relevant attributes and for every attribute a list of relevant values.
Diagnosing diseases, pests and non-parasitic disorders
67
TABLE 2
Symptom Rot and its Levels Symptom name: rot Level
Attribute name
Location Colour Solidity Smell Edge Sunken/swollen Pattern Characteristic TABLE 3
Frame Structures, Elements and Examples Name of frame
Symptom
Example
Elements
(symptom_number, symptom_name_with_attributes [attribute_namel-[list_of_values], attribute_name2-[list_of_values], state_of_symptom,
etc.],
specific”).
(~228, colouring with-attributes [location-[bulb, bulbfoot], colour-[brown], border-[sharp], sunken-[moderately] 1, probable).
Context
(context_number, context_name_with_attributes [attribute_namel-[list_of_values], attribute_name2-[list_of_values],
Form
(form-number, disease, context_ number, [list of symptom numbers]).
(f12, Fusarium oxysporum f. sp. Gladioli, ~12, [s24,s228,s248]).
Successor
(symptom-name, attribute-name, value, successor)
(colouring, location, bulb, bulbfoot).
(cl2, [crop-[iris], stage of growth[‘dry bulb’], season-[autumn, etc.]). winter, spring], appearance[widespread]]).
“Only added to specific symptoms.
The frame ‘Form’ connects each disease to the relevant context and symptoms, and contains 4 elements: 1, form number; 2, name of disease; 3, context number; 4, set of symptom numbers, represented as list. The frame ‘Successor’ contains 4 elements. 1: the symptom name. 2: the attribute name. 3: the value. 4: the successor of the value. The frame ‘Successor’ describes the tree-structure of the values. Images Symptom descriptions are completed with images and filed as bitmaps. These images can be generated on request. They proved to be very important with
68
hf. A. Kramers, C. G. M. Conijn, C. Bastiaansen
regard to explaining questions the system asks and to evaluating conclusions given by the system. So far 247 images have been added. Every symptom in the knowledge base will eventually be provided with at least one image. Additional remarks Additional remarks by the experts have been added to some forms. This is information that could not be described by the developed structure, for example “Severe symptoms of Iris mild mosaic virus with grey-necrotic small spots and small stripes at leaf tips can be distinguished from light symptoms of Narcissus latent virus by Elisa tests.”
viruses Viruses can be excluded from the list of possible hypotheses. The user is not always interested in viruses and excluding them can reduce the number of questions.
THE INFERENCE
MECHANISM
The inference mechanism is the part of the system containing the problemsolving logic. Figure 6 gives an overview of the inference mechanism. The processes in the flowchart are described in the text below. Each process is illustrated by corresponding steps of the diagnosis of R. solani, described earlier. Appendix B gives an overview of this diagnosis session. Description of a sample Easily accessible input screens give the user the opportunity to describe the context and the symptoms that can be recognized on the sample. The user can put in as much description and detail as they want. The context can only be described in this phase of the program. No questions will be asked about it. The system will only ask about symptoms that are visible on the sample of the crop. The user interface is simple, the user only needs to use a mouse. Of course one must have the ability to discriminate a healthy plant from a diseased plant, and one must be able to describe the symptoms of the diseased plant properly. Diagnosis example: A sample of hisses grown for production of flowers. Diseased plants were found in patches in the field, post emergence. The user identified a rot of bulb noses which are weak and brown, with brown crusts on the outermost scales of bulbs. The users input will be as shown in Fig. 7.
Diagnosing diseases, pests and non-parasitic disorders
69
Fig. 6. A global flowchart of the inference mechanism of EXSYS.
Selection of set of input symptoms With the initial set of symptoms, the system will look for a disease that can explain as many symptoms as possible, in the given context. To do this, the system will first look for a disease that can explain all the symptoms. If there is no such disease, it will look for a disease that can explain all but one symptoms, etc., until it finds a possible disease. This is a permitted hypothesis. The hypothesis will be examined resulting in a rejected or accepted
70
M. A. Kramers, C. G. M. Conijn, C. Bastiaansen
context:
symptom
crop:
iris
production:
production of flowers
manifestation in the field:
patches
development stage:
post emergence
location
bulbnose
colour
brown
solidity
weak
location
on outermost scales
outer colour
brown
I:
rot
symptom 2: crusts
Fig. 7. User input of diagnosis example.
hypothesis. After that a new hypothesis will be sought. If no new hypothesis can be found for the current set of input symptoms, a new set of input symptoms will be dealt with. For example: there are three input symptoms, Sl, S2 and S3. The following sets of input symptoms will be checked for possible diseases: {Sl,S2,S2}, {Sl,S2}, {Sl,S3}, {S2,S3}, {Sl}, {S2}, (S3). If all sets have been checked and only the empty set is left, the diagnosis is completed. If, however, a hypothesis is accepted and one of the symptoms of the declared set is specific, previous accepted hypotheses that are based on (a set of) these same symptoms will still be rejected. The diagnostic procedure will continue with only the undeclared input symptoms. Diagnosis example: The following sets of symptoms will be explained: {rot, crusts}, {rot} and {crusts}. The first set can be explained by R.sohi. If hyphal threads are identified on shoot, bulb nose or outermost scales, the sets {rot} and {crusts} need no further investigation because hyphal threads are specific to R. sohni and all input symptoms are explained. However, since there are no hyphal threads on this sample every set will be examined. Determination of hypothesis To determine a hypothesis the first form of a disease is chosen from the knowledge base. The system has to find out whether this form can explain the set of input symptoms. To do so, every input symptom must have a
Diagnosing diseases, pests and non-parasitic disorders
71
similar knowledge-base symptom from the selected form. The system will check if all combinations of input symptoms and knowledge-base symptoms match. If they do not match, the hypothesis is rejected and the next form of the disease is selected (until all forms have been selected). If they do match, the system still has to check the state of importance of the symptoms. If all symptoms are possible, the hypothesis is declared unlikely and therefore rejected. Otherwise, if the set of input symptoms contains a crucial or probable symptom, the system has found a permitted hypothesis. Diagnosis example: The first hypothesis is R. soluni. In this form R. solani is described by three symptoms: rot, hyphal threads and crusts. Explained input symptoms are rot and crusts with, according to this form, status crucial and possible. The second hypothesis that the system comes up with is F. oxysporum. F. oxysporum can only explain the input symptom rot. Taking a form of disease Diseases are divided into five categories of occurrence. The system will start its procedure with the first form of the first disease of Category 1. All forms and all diseases will be reviewed in order. The most likely hypothesis will be found first, but eventually all possibilities will be checked. There are a few exceptions. If a disease is concluded, other forms of this disease will be skipped by the system. If the user excludes diseases during consultation, if for example he declares that the sample does not suffer from Ink spot (Drechslera iridis), all forms describing Ink spot will consequently be skipped by the system. Matching set of input symptoms to form To match the set of input symptoms to the selected form, all symptom combinations and the context combination must fit. The context is handled in a similar way to symptoms. A knowledge-base symptom and an input symptom match if they have the same symptom name, like rot, and all attributes match. An attribute matches if one value in the knowledge base matches with one value in the input, or if either knowledge base or input attribute is given no value. Table 4 shows two matching symptoms. The knowledge base value matches the input value if both are on the same route/branch of the tree structure of the attribute values. So the knowledge base value and the input value are equal, the input value is a predecessor of the knowledge base value or it is its successor. The values also match if they are tolerated values. Table 5 shows some possible value combinations and
72
M. A. Kramers, C. G. M. Con@, C. Bastiaansen
TABLE 4 A Knowledge Base Symptom of Rot Matching an Input Symptom of Rot Attributes to rot Location Solidity Edge Smell
Knowledge base symptom
Input symptom
bulbnose weak sharp
bulbnose weak no smell
TABLE 5 Example of Possible Value Combinations Input value
Knowledge base value
A smell No smell Strong smell No Smell
faint smell faint smell a smell strong smell
predecessor tolerated successor
match match match no match
the fact that they do or do not match. The table also shows whether the knowledge base value is equal, predecessor, successor or tolerated to the input value. Figure 5 shows the tree structure of the values of attribute smell. Diagnosis example: Input-information is matched to database-information (Fig. 8). Hypothesis is R. solani. All values match. Examining the hypothesis The hypothesis of the system is based on a selected form in the knowledge base that matches a set of input symptoms. To confirm the hypothesis, the system will take three steps: check the symptoms, ask questions and evaluate answers. Checking the symptoms means that the system will check whether the input contains all symptoms from the knowledge base and if important attributes are missing. If they are, the system will ask the user questions to complete missing values of the symptoms of the sample. The answers will be evaluated to examine whether the hypothesis will be rejected or accepted. An hypothesis will only be accepted if all symptoms of the selected set of input symptoms match the knowledge base. Checking symptoms The system will now check the symptoms for important missing information. To do so, it will first check the specific symptoms, then the crucial symptoms and finally the non-crucial, probable and possible symptoms.
Diagnosing diseases,pests and non-parasiticdisorders
73
Hypothesis: Rhimctonio solani.
input value
database value
match
crop:
iris
Dutch iris
pr&cessor
production:
production of flowers
production of flowers
equal
manifestation in the field:
patches
patches
equal
development stage:
post emergence
post emergence
equal
bulbnose
shoot, bulbnose,
equal
attribute name context
rot location:
on outermost scales WY brown,
predecessor
light bmwn solidity:
weak
weak
on outermost scales
shoot, bulbnose, on rot, equal
equal
on outermost scales outer colour:
brown
Fig. 8. Matching input-information
brown
equal
to database-information.
Examining specitic symptoms If the hypothesis contains a specific symptom, the system will check whether this symptom has been reported. If it has, the system will look for additional attributes and values that have not been mentioned. If the specific symptom has not been mentioned, the system will ask if this symptom, name and location, is present. If a specific symptom is confirmed, than the hypothesis will become a diagnosis. If there is no specific symptom or if a specific non-crucial symptom did not match, the system will continue its research and check if all the crucial symptoms of the hypothesis are present.
M. A. Kramers, C. G. M. Con@, C. Bastiaansen
74
Diagnosis example: The system will ask whether there are hyphal threads on the shoot, bulbnose or on the outermost scales. The answer is no. Since hyphal threads are specific but not crucial, research will continue. Examining crucial symptoms If a crucial symptom is not present, or if it does not match, the hypothesis will be rejected. If all crucial symptoms match the diseased sample, the system will check if the plant also explains the non-crucial, reported, symptoms. Diagnosing example: For R. soZani rot is a crucial symptom. The system will check all attributes of rot, up to level 5 (Fig. 9). There is only one crucial symptom and it matches. Examining probable and possible symptoms A non-crucial symptom is probably or possibly present. This difference is only important in their level of research. If a non-crucial input symptom does not match the knowledge base, the hypothesis will be accepted for a smaller set of input symptoms, excluding the non-crucials. Diagnosis example: For R. solani crusts is a possible symptom. The system will check all attributes of crusts, up to research level 2. No question is asked regarding location (level 1) and colour (level 2), which are already known. Matching symptoms If a knowledge-base symptom is not yet described by the user, the system will ask if the symptom, name and location, is present on the sample. The system will match the input-knowledge base combinations as detailed as defined in Rot on bulbnose: Question: are following values correct?
Answer:
attribute
input
VdW
colour
brown
grey brown
yes I no I maybe
light brown
yes I no I maybe
yes
smell
no smell
yes / no I maybe
Yes
edge
smooth
yes I no I maybe
yes
sunken
no
yes /no I maybe
yes
Fig. 9. Checking all attributes of rot of Rhizoctonia solani up to level 5.
15
Diagnosing diseases, pests and non-parasitic disorders
the level of research. These levels of research are different for all states of symptoms. They can be adjusted if necessary. The values of knowledge-base symptom and input symptom will be compared for each attribute. If an equal value is found or an input value is successor to a knowledge-base value, the attribute matches and no questions will be asked. If an input value is predecessor of a knowledgebase value, the system will ask if the detailed value in the knowledge-base is correct. If all input values of an attribute differ from the knowledgebase values, the attribute does not match and hence the symptom does not match. If an input value is a tolerated value of a knowledge base value, the system will ask if the knowledge-base value is correct. If no value is given during input, the system will ask for all possible knowledge base values. All questions will be gathered in one question-screen per symptom. Table 6 shows examples of all possible input-knowledge base combinations while matching values, using attribute smell (Fig. 5) of symptom rot, with the questions and conclusions. Asking questions
As described in Matching symptoms the user may expect two types of questions. One: the system asks for a new symptom, e.g. are there crusts visible on the outer bulb scales? Two: the system asks for missing or incomplete values of an already recorded symptom, e.g. are crusts on the outer bulb scales round in shape, size 3 mm and is the outer colour white? The user can answer every value asked with ‘yes’, ‘no’ or ‘maybe’. All extra knowledge of the diseased crop that is added by the user during a session is recorded and will be taken into account during the diagnosis process. So no questions will be repeated.
Examples of Value Combinations
TABLE 6 While Matching Attribute Smell of Symptom Rot
Input value
Kn. base value
Question (type)
Strong smell A smell
strong smell strong smell
is strong smell correct?
equal value predecessor
Faint smell Not ‘a smell No smell
a smell a smell faint smell
is faint smell correct?
successor ‘not’ value tolerated
faint smell
is there a faint smell?
no input value
Matching
Conclusion
match yes, match no, no match match no match yes, match no, no match yes, match no, no match
76
M. A. Kramers, C. G. M. Conijn, C. Bastiaansen
Evaluate answers After every question screen the system will evaluate answers to prevent unnecessary questions. Evaluation is executed per attribute. The system will first check ‘yes’ or ‘maybe’ answers and secondly ‘no’ answers. Finding a value with yes or maybe answer If ‘yes’ or ‘maybe’ is the answer for a value, the attribute matches. If no answer is given, the attribute still matches. If questions are not answered they can, of course, be asked again. Finding only ‘non’ values If no positive answer is given and one or more values are not present, the attribute is not matching so the symptom does not match.
VALIDATION Phase 1 The system was first tested for iris by approximately 20 researchers at the Bulb Research Centre and 8 experts in the bulb sector. These tests produced encouraging results. Table 7 shows the diseases diagnosed during these sessions. On average the system asks five questions per session. Figure 10 shows the number of questions asked in 54 registered test sessions. The number of questions did not depend on the number of input symptoms. The average working time of the system, this is waiting time for the user, was about 6 seconds, the maximum working time was about one minute. In this phase the system made about 65% error-free diagnoses. In the other 35% of the cases the diagnosis was insufficient, mostly due to incompleteness of the knowledge base. All failures made during testing can be reduced to interpretation differences by individuals. Three examples will illustrate the nature of misclassification that occurred. Example I
A dry bulb sample suffers from Ditylenchus destructor. There are brown stripes on bulb scales and tunic (Fig. 11). Hypothesis
F. oxysporum and Drechslera iridis. EXSYS will not come up with Ditylenchus destructor because the user interpreted the brown stripes on the bulb scales and tunic as discoloration although it was rotting.
Diagnosing diseases, pests and non-parasitic disorders
77
TABLE 7 Diseases and the Number of Times They Occurred During Testing Number of sessions
Name of disease
Black slime (Sclerotinia sclerotiorum) Blue mold (Penicillium hirsutum) Bud blasting Bulb rot (Fusarium oxysporum) Crown rot (Scleotium rolfsii) Grey bulb rot (Rhizoctonia tuliparum) Grey mold (Botrytis cinerea) Ink spot (Drechslera iridis) Iris severe mosaic virus Leaf dehydration Leaf spot (Heterosporium gracile) Mealy bug (Phenacoccus avenae) Mechanical damage Narcissus latent virus Nematode disease (Ditylenchus destructor) Phytophthora rot (Phytophthora) Rhizoctonia rot (Rhizoctonia solant) Root rot (Pythium) Soft rot (Erwinia carotovora) Storage moth (Plodia interpunctella) Stripe disease (Pseudomonas)
,5
. .._...__..._..._...__.._...............__....__
1
1 2 3 4 5 6 7 6 91011121314151617161920 numberofquestiono
Fig. 10. Number of questions in 54 sessions.
3 8 2
1 1 3
1 1 4 1 4 2 4 4 1 2 6 2
1 2 1
M. A. Kramers, C. G. M. Con@, C. Bastiaansen
78
Input:
context
discoloration
Fig.
crop
iris
development stage
dry bulb
location
bulb scales and tunic
colour
brown
pattern
stripes
11. User input of a sample suffering from Ditylenchus destructor.
SoZution Since this misjudgement is understandable (there is after all a discoloration caused by rot), the disease description will be completed with discoloration of bulb scales and tunic with status ‘probable’. Rot of bulb scales remains the crucial symptom. The complete knowledge base was checked for this type of misunderstanding. Example 2 A sample suffers from Penicillium hirsutum. It has soft, bluish grey rot on its bulb base which is slightly sunken. There are poor plants and occasionally no lifting in the field (Fig. 12). Hypothesis Penicillium hirsutum. Question I: Is there mold on the bulb base? Answer: No. Mold is a specific but non-crucial symptom for P. hirsutum so the hypothesis is not (yet) rejected. Input:
context
rot
retarded growth
crop
iris
development stage
post emergence, pre flowering
production
flower production
location
bulb base
colour
bluish grey
solidity
soft
sunken
slightly
degree
no lifting, poor plants
Fig. 12. Input description of a sample that suffers from Penicillium hirsutum.
Diagnosing diseases, pests and non-parasitic disorders
19
Question 2: (Table 8) Is the edge of the rotten area on the bulb base smooth? Answer: Yes. Question: Is the rotten area ‘not sunken’, instead of ‘slightly sunken’? Answer: No. Hypothesis will be wrongly rejected. P. hirsutum causes rot of the bulb
base that can be slightly sunken, so the knowledge base was too limited. It needed to be adjusted. This type of failure was the most difficult to find. Example 3
A sample suffers from Sclerotinia sclerotiorum. There are patches in the field. There is brown, grey and soft rot on the bulbs (see input in Fig. 13). Hypothesis S. sclerotiorum Question: Are there hyphal threads on bulb or foliage? Answer: No The hypothesis S. sclerotiorum will be accidently rejected because hyphal threads is a crucial symptom for S. sclerotiorum. The user did not recognize
the thin white hyphal threads. This type of failure shows that the user must have some knowledge of plant diseases. TABLE 8
Question Screen: Rot on Bulbbase Caused by Penicillium hirsutum Attribute
Input value
Knowledge base value
Correct?
Answer
-
smooth no
yes/no/maybe yes/no/maybe
yes no
We Sunken
slightly
Input: context
rot
crop
iris
development stage
post emergence, pre flowering
manifestation
patches in the field
location
bulb
colour
brow
solidity
soft
PY
Fii. 13. Input description of a sample that suffers from Sclerotinia sclerotiorum.
M. A. Kramers, C. G. M. Conijn. C. Bastiaansen
Phase 2 After the first tests the system was installed at 12 locations in the Netherlands: the Flower Bulb Inspection Service, the crop protection trade, the flower bulb extension service and iris preparation companies. The participants in this test phase were experts as well as semi-experts on iris diseases. The system was used for one year. The participants were asked to pay attention to the following aspects: user-friendliness, structure of the input menu, logic of questions, faith in conclusions, terminology, completeness of knowledge base and practical value. The objective was to trace the faults and shortcomings of the knowledge base. When the number of failing diagnosis sessions can be reduced to less than 5%, and the system’s practical value has been sufficiently proven, it will be decided whether or not extension to other crops is desirable. During the year of testing not every disease passed the system. The semiexperts used the system far more often than the experts. Unfortunately, semi-experts do not have enough knowledge to assess the contents of the knowledge base. These two aspects make it impossible to estimate the success percentage of the entire system. However, the sessions that were run, were error-free. The system was judged user-friendly. The input menu proved to be easy to use. Questions were said to be understandable and logical. Semi-experts, generally, had enough confidence in the conclusions of the system. The terminology was clear. All remarks made were collected and used to improve the system. Each participant was positive about the practical use of the system and insisted on extending the development of EXSYS to other crops. It was recently decided to proceed with the project, starting with tulip.
DISCUSSION
AND CONCLUSIONS
A question that always arises is why crop protection advice is not added to the diagnostic conclusions. Crop protection is an expertise on its own, and is constantly liable to change. EXSYS is restricted to diagnosis. Compared to crop protection advice, it will need little maintenance. Once the descriptions of the diseases are made, they will hardly ever change and modifications therefore will be minimal. Descriptions of new diseases and additional images will of course need to be added from time to time. Another question that is often asked is whether expansion to include other crops is possible. Yes, it is. Descriptions of diseases (the knowledge base), and diagnostic expertise (the inference mechanism), are separately stored and
Diagnosing diseases,pests and non-parasiticdisorders
81
separately maintained. The knowledge base can therefore easily be expanded without changing the inference mechanism. The inference mechanism can be used for all (bulb) crops, without further modifications. It was recently decided to proceed with the project. The knowledge base will be extended for tulips. The number of diseases known for tulips in The Netherlands is about twice the number of diseases known for iris. Potential users of the system are researchers, advisors of extension services, large farmers, bulb dealers, crop protection dealers and schools. Expert systems can easily be used as a training facility since they contain the necessary knowledge and the ability to explain their reasoning processes and actions (Stewart, 1992).
ACKNOWLEDGEMENTS We would like to thank Marco Balvers (Balvers, 1990) and Maarten Ketelaars (Ketelaars, 1991) for their contribution. They have participated in this research project as part of their studies at the Technical University in Eindhoven.
REFERENCES Adams, S. S., Stevenson, W. R., Delhotal, P. and Fayet, J. (1990) An expert system for diagnosing post-harvest potato diseases. Bulletin OEPPIEPPO 20, 341-347.
Anonymous (1978) Ziekten en Afwijkingen bij Bolgewassen, Dee1 1. Liliaceae. Laboratoxium voor Bloembollenonderzoek, Lisse, The Netherlands. Anonymous (1995) Ziekten en Afwijkingen bij Bolgewassen, Dee1 2. Amaryllidacea, et al. Laboratorium voor Bloembollenonderzoek, Lisse, The Netherlands. Balvers, M. A. H. (1990) DIABOL: Systeemspeczficatie, Gebruikers Handleiding en Bijlagen. Afstudeerverslag Technische Universiteit Eindhoven, Faculteit Wiskunde en Informatica. Blancard, D., Bonnet, A. and Coltno, A. (1985) TOM, un systeme expert en maladies des tomates. P.H.M. Revue Horticole 261,7-14. Bratko, I. (1988) Prolog Programming for Arttjicial Intelligence. Addison-Wesley, Wokingham, UK. Coelho, H. and Cotta, J. C. (1988) Prolog by Example. Springer, Berlin. Cooley, D. R. (1988) Expert systems: a new tool for plant pathologists. Plant Disease 72, 279.
Dodd, T. (1990) Prolog: a Logical Approach. Oxford University Press, Oxford, UK. Ketelaars, M. W. A. M. (1991) DESZ, bet ontwerp van een Diagnose-ExpertSysteem voor het gewas Iris. Afstudeerverslag Technische Universiteit Eindhoven, Faculteit Wiskunde en Informatica.
82
M. A. Kramers, C. G. M. Conijn, C. Bastiaansen
Kramers, M. A., Conijn, C. G. M. and Bastiaansen, C. (1993) Ontwikkeling van een Ziektediagnose-Expertsysteem. Annual Report, Bulb Research Centre Lisse, The Netherlands, pp. 38-41. Kramers, M. A., Conijn, C. G. M., Bastiaansen, C. (1994~) Ontwikkeling van een expertsysteem voor ziektediagnose. Agro Informatica 713, 21-24 Kramers, M. A., Conijn, C. G. M. and Bastiaansen, C. (1994b) Ziektediugnose per computer. Vakblad voor de bloemisterij 11: pp. 34-35, Vakwerk 10: pp. 44-45, and Bloembollencultuur nr 16: pp. 40-41. Latin, R. X., Miles, G. E. and Rettinger, J. C. (1987) Expert systems in plant pathology. Plant Disease 71, 866872. Latin, R. X., Miles, G. E., Rettinger, J. C. and Mitchell, J. R. (1990) An expert system for diagnosing muskmelon disorders. Plant Disease 74, 8387. Michalski, R. S. and Davis, J. H. (1983) A computer-based advisory system for diagnosing soybean diseases in Illinois. Plant Disease 67, 459-463. Plant, R. E., Zalom, F. G., Young, J. A. and Rice, R. E. (1989) CALEX/Peaches, an expert system for the diagnosis of peach and nectarine disorders. Hortscience 24, 700. Ramon, M. C. U. and Roland, F. (1994) An expert advisory system for wheat disease management. Plant Disease 78,209215. Roach, J. W., Virkar, R. S., Weaver, M. J. and Drake, C. R. (1985) POMME, a computer-based consultation system for apple orchard management using Prolog. Expert Systems 2, 56-69. Stewart, T. M. (1992) DIAGNOSIS, a microcomputer-based teaching aid. Plant Disease 76, 644647. Travis, J. W. and Latin, R. X. (1991) Development, implementation, and adoption of expert systems in plant pathology. Annual Reviews Phytopathology 29, 343360. Waterman, D. A. (1986) A Guide to Expert Systems. Addison-Wesley, Wokingham, UK.
APPENDIX
A
List of all described diseases of iris, added to the knowledge base of EXSYS
Fungi:
Grey bulb rot (Rhizoctoniu
tuliparum)
Bulb rot (F. oxysporum) Root rot (Pythium) Blue mold (Penicillium hirsutum) Rhizoctonia rot (R. solam) Grey mold (Botrytis cinerea) Crown rot (Sclerolium rorfiz) Leaf spot (Heterosporium gracile) Ink spot (Drechsleru iridis)
Diagnosing diseases, pests and non-parasitic disorders
Bacteria: Viruses:
Animal organisms:
Chemical damage:
Crown rot (Sclerotium rolfsii var. delphinit) Phytophthora rot (Phytoph thora) Rust (Puccinia iridis) Black slime (Sclerotiniu sclerotiorum) Black slime (Sclerotinia bulborum) Black leg (Sclerotium wakkerz) Reticulata rot (Altenaricz) Rhizopus rot (Rhizopus arrihizus) Stripe disease (Pseudomonas) Soft rot (Erwinia carotovora) Iris mild mosaic virus Narcissus latent virus Iris severe mosaic virus Bean yellow mosaic virus Tomato spotted wilt virus Wire worm (Agriotes species) Aphid (Aphidoidae) Leather jacket (Tip& species) Nematode disease (Ditylenchus destructor) Lesion nematode (Pratylenchus penetruns) Bean fly (Delia plutura) Tulip bulb aphid (Dysaphis tulipae) Snail, slug (Deroceras/arion) Mealy bug (Phenacoccus avenue) Root-knot nematode (Meloidogyne) Cutworm (Agroitis) Thrips (Taeniothrips atratusl-simplex) Storage moth (Plodia interpunctella) Leaf nematode (Aphelenchoides subtenuis) Bulb mite Caterpillar Asulan damage (Asulox) Phosphorus damage Gas damage Kasumin damage (kasugamycine) Gramoxone damage Sooted foliage Dimethachlorine damage Borium damage Formaline damage Methyl bromide damage Herbicide damage
83
84
M.
Non-parasitic
causes:
Unknown causes:
A.
Kramrs,
C. G. M. ConlQn,C.
Bastiaansen
Bud blasting Mechanical damage Blindness Gummosis Root damage Dead leaf tips Heat damage Frost damage More leaves Leaf dehydration Snapping Subtunic root growth Morfological defects Burst bulbs Flower discoloration Bulb base corking Head bud dehydration Soft bulb rot
APPENDIX
B
A complete diagnosis session The sample suffers from R.sohni. Input by user: context:
crop: production: manifestation in the field: development stage:
iris production of flowers patches post emergence
rot
location colour solidity
bulbnose brown weak
crusts
location outer colour
on outermost scales brown
EXSYS starts its research.
Diagnosing diseases, pests and non-parasitic disorders
85
Hypothesis: R. solani Question: Are there hyphal threads on shoot, bulbnose or on outermost scales? Answer: no Question: Are following values correct? Rot on bulbnose: attribute input colour brown smell edge sunken
Answers value grey brown light brown no smell smooth no
yes/no/maybe yes/no/maybe yes/no/maybe yes/no/maybe yes/no/maybe
yes Yes yes yes
R. solani is confirmed. EXSYS continues its research. Hypothesis: F. oxysporum Question: Is there deformation (ridges) on subterranean Answer: no Question: Are following values correct? Rot on bulbnose: attribute input edge sunken no
shoot?
Answers value sharp slightly
yes/no/maybe yes/no/maybe
no no
F. oxysporum is rejected. EXSYS can find no other possible diseases. Consultation
is finished.