Expert Systems and Farm Management

Expert Systems and Farm Management

M. Evans,’ R. Mondor’ and D. Flaten2 ‘Department of Computer Science, University of Manitoba,

Winnipeg, R3T 2N2. 2Faculty of Agriculture, University of Manitoba, Winnipeg, R3T 2N2,

INTRODUCTION Artificial intelligence (AI) may be defined as ‘‘the branch of computer science that is concerned with the automation of intelligent behavior” (Luger and Stubblefield 1989). The major topics of study in A1 include natural language processing, robotics and expert systems. Researchers involved in natural language processing are concerned with the design and construction of programs that can accept, understand and produce language as it is used by people in everyday communication. In essence, these programs are attempting to simulate the human ability to effectively communicate using some established language. Research in robotics is concerned with making robots more intelligent through the duplication of certain human senses, most commonly sight and touch. The main objective is to create robots that can move around freely in a dynamic environment. For this to be possible, a robot would have to be capable of perceiving changes in its immediate environment and able to take any actions that might be necessitated by that change. However, by and large the most successful area of research in A1 has been in expert systems.

EXPERT SYSTEMS OVERVIEW In the late 1970s, during the quest to construct intelligent systems, developers realized that knowledge, and not formalism or inference mechanism, was the key to intelligent behavior (Waterman 1986). It was recognized that the human ability to display intelligent problem solving behavior was in part due to a sufficient fund of knowledge about a particular problem area. In general, a person who has a significant depth of understanding in some specific field is called an expert, and a system designed to simulate some task performed by an expert is called an expert system. Hence, expert systems are designed to mimic the ability of an expert in some narrow problem area. To gain a better fundamental understanding of expert systems, it would be beneficial to first consider the characteristics of human experts.

Human Experts Waterman defines an expert as “a person who, because of training and experience, is able to do things the rest of us cannot; experts are not only proficient but also

Canadian Journal of Agricultural Economics 37 (1989) 639-666 639

640 CANADIAN JOURNAL OF AGRICULTURAL ECONOMICS

smooth and efficient in the actions they take.” Experts are able to perform at high levels when solving difficult problems and it is this “performance” trait that dis- tinguishes an expert from a novice. A high level of performance is achieved by combining a theoretical understanding of the problem domain with heuristic rules of problem solving that experience has shown to be effective (Luger and Stubble- field 1989). For example, consider the difference between the functioning of a skilled medical practitioner and a senior intern. The skilled practitioner is generally able to arrive at a diagnosis in less time and with much less effort than most interns. Skilled practitioners utilize intuition and experience to formulate a diagnosis, whereas an intern may feel compelled to perform some standard set of tests and interviews, some of which will be irrelevant, before a diagnosis can be suggested. The skilled practitioner exhibits certain characteristics and techniques that are common to many human problem solvers. The goal of expert system development is to replicate these features.

An attempt to describe all possible features exhibited by a problem solver would be futile; instead the approach taken here is to summarize some of the features considered pertinent to expert system development. Firebaugh (1983) identifies several features he believes are common to human experts. First, human experts are able to solve problems, both rudimentary and difficult, in their area of expertise. Second, when questioned, a human problem solver is able to explain the reasoning processes that lead hidher to a solution. The ability to learn is also a fundamental trait of all human problem solvers. Competent experts are contin- ually acquiring new knowledge and skills in an attempt to improve and broaden their problem-solving capabilities. A concept closely related to learning is that of restructuring. Humans are able to dynamically restructure knowledge when faced with a novel situation or idea. Humans generally begin to understand a new concept by modifying or extending a previously learned concept that is in some way similar to the new concept. Expert problem solvers also possess the power of discernment - the ability to recognize when a problem is outside their area of expertise. For example, an oncologist can quickly discriminate between a patient with cancer and a patient with heart disease; in the latter case, an oncologist would refer the patient to a cardiologist. Experts are also “good at plowing through irrelevant information in order to get to the relevant issues” (Waterman 1986), a feature not usually displayed by a novice. When solving a problem, it is often difficult to arrive at a solution with complete confidence. In such a situation, the human expert can provide some measure of solution reliability (Miller 1986). Finally, human experts are known to be apt at balancing the effort expended on deriving a solution to the quality of that solution. When an acceptable answer to a problem is produced, no extra effort will be expended on deriving an optimal solution unless that effort can be reasonably justified.

The goal of researchers involved in developing expert systems is to try to replicate, to some degree, the features outlined above. A closer analysis of the

EXPERT SYSTEMS AND FARM MANAGEMENT 641

measures and components of expert systems will provide insight into what extent these goals have been achieved.

What are Expert Systems? Harmon and King (1985) quote E. Feigenbaum’s definition of an expert system as “. . .an intelligent computer program that uses knowledge and inference procedures to solve problems that are difficult enough to require significant human expertise for their solution.” Knowledge, in this context, refers to information that has been procured from an expert. This knowledge can be roughly classified into two different categories: facts and heuristics. Facts are propositions that are known, either by observation or experience, to be true. Heuristics are subjective rules of good judgment (“rules of thumb”) that characterize expert-level decision making in a particular field. Generally, heuristics are established through experience and cannot be learned from the standard theory presented in textbooks and classes.

An expert system is a specialized instance of a more common type of system known as a knowledge-based (or simply knowledge) system. Knowledge-based systems use large amounts of domain-specific knowledge to solve problems in a particular domain; however, the problems they solve are not considered difficult enough to require an expert’s attention. The term “expert system” is often abused by those impressed with the implications of the phrase. In reality, seldom does a system reach a level of competence that is deserving of the title “expert.” In this paper, in accordance with most of the available literature, the name most often used will be “expert system.”’

Expert System Features Expert systems exhibit a number of features that make them unique. First, at the root of every system is a large store of knowledge about some domain. This knowledge is what gives an expert system its problem-solving capability. The importance of knowledge cannot be overemphasized. ‘‘The accumulation and codification of knowledge is one of the most important aspects of an expert system” (Waterman 1986). Knowledge in an expert system is explicit and accessible and hence can be easily understood and reproduced.

Firebaugh (1988) states that expert systems have the quality of being “open to inspection,” a term that embodies several features. First, being open to inspection implies that users are able to interact with a system during processing. Users can inspect the state of reasoning and can pose questions concerning intermediate decisions. Such a capability has proven extremely valuable for expert system developers responsible for maintaining and extending knowledge bases. Second, if a system is to be open to inspection, it must be able to explain the reasoning processes used to establish an eventual conclusion. Explanation can occur at various levels. At a very rudimentary level, explanation simply consists of tracing the


system reasoning processes. More complex explanations are supported by what is known as meta knowledge - knowledge about knowledge. At this level of explanation, a system is able to display not only what decisions were made but also why those decisions were made.

Because of the exploratory nature of expert system programming, it is important that development environments be highly interactive, with ability to support incremental testing, prototyping, and debugging. When good programming techniques are used, programs developed in such an environment are easy to extend and modify. In rule-based systems,’ for example, it should be possible to add new rules to the knowledge base without causing any negative side effects. As Fire- baugh points out, “Expert system designers have commented that easy modification of the knowledge base is a major factor in producing a successful program.”

Heuristic knowledge, unlike facts, cannot be represented in an expert system with complete confidence. In recognition of this problem, a number of methods have been developed for manipulating imprecise knowledge. In general, associated with each bit of knowledge is a measure of confidence called a certainty factor. During reasoning processes, certainty factors are manipulated and combined using various formalisms until eventually a measure of certainty is propagated to the final solution. In brief, expert systems have the ability to associate a degree of confidence with their solutions. This feature suggests two important points. First, if a solution cannot be suggested with complete confidence, then there is a chance that the solution is incorrect, implying that expert systems are prone to making mistakes. Second, if expert systems are capable of making mistakes, those people using them should be aware of this fact and should exercise caution when deciding whether or not to accept a recommendation.

Components of an Expert System Figure 1 depicts the architecture of a typical expert system. The fundamental components of an expert system, as cited by Miller (1986), include a user interface module, an inference engine, a knowledge base and working memory. In addition to these fundamental components, many systems have an explanation subsystem and a knowledge base editor.

Acceptance of a system by a targeted group of users is generally contingent upon how natural and clear the user interface appears. The interface component of the system supports user interaction while concealing system complexity. Depending on user needs, the interface module may be designed using several different conventions, including menu-driven, natural-language, or graphics inter- faces (Luger and Stubblefield 1989).

The knowledge base contains the domain-specific information used in problem solving. This is where the domain expert’s knowledge is codified using some internal representation scheme. Generally, the knowledge is represented using a set of If-Then rules, structured in some format that is natural for the environment.


Figure 1 . A typical expert system architecture

An expert system designed to make recommendations concerning weed control, for example, might have its knowledge partitioned into several classes: one for knowledge about herbicides, one for knowledge about climatic conditions, and perhaps another containing knowledge about weed varieties. Structuring knowledge makes it easier to understand, modify and extend a system.

The inference engine is the “work-horse’’ of the entire system. It uses a single strategy, or combination of strategies, to traverse the knowledge base in an attempt to generate a solution. A solution is generated progressively as new information is inferred from existing knowledge and data. The new information causes further inferences to be made and this cyclic process continues either until a solution unfolds or until the knowledge base is exhausted; that is, all possible inferences are tried but no new information is generated. In the latter case, a solution to the problem would remain unknown. In short, the inference engine contains knowledge about how to solve problems and the knowledge base contains what is known about the problem.

Working memory contains the case-specific data used by the inference engine while searching the knowledge base. Initially, working memory contains a set of assertions made by the user or retrieved from some other source such as a data base management system. During processing, additional data are added to working memory as inferences are made. Working memory is used to keep track of what is currently known about a problem for each stage of processing.

An expert system may also have a knowledge base editor - a tool used to access the knowledge base. Knowledge base editors are used by programmers to modify, extend and scan the knowledge base. By hiding some of the low-level programming detail, they generally make editing of the knowledge base more


simplistic. The more powerful editors may also detect knowledge base inconsist- encies resulting from the addition of new information.

The practicality of an expert system, in many cases, is determined by the success of its explanation subsystem. Expert systems must be able to explain why a specific piece of information is being requested or how a particular conclusion was reached. In addition, if the user is puzzled about why some other considered recommendation was not suggested, the system should be able to explain why that possibility was ruled out. Without such an ability user confidence in a system will be understandably fleeting and the system simply will not be used.

This concludes the portion of the paper concerned with introducing the concept of an expert system. In the next section, an effort will be made to differentiate expert systems from conventional systems.

Conventional Versus Expert Systems Conventional systems are data intensive. They use complex algorithms to process large volumes of data and the results they produce are often predictable and correct. Billing of hydro-electric power is an example of a typical application addressed by a conventional data-processing system. Each month, meter readings are accu- mulated, fed into the computer and processed via a series of mathematical manip- ulations. A bill documenting the amount of electricity used and the amount owed is then issued to each customer. A task of this proportion is tedious and cumber- some but requires little intelligence.

In contrast, expert systems manipulate knowledge as opposed to data. Peter Hart (1986), in an interview conducted for IEEE Expert, tries to clarify the difference, ‘‘. . . I think of ‘data’ as describing the facts associated with a specific object or situation. I think of ‘knowledge’ as describing relations among gener- alized sets of objects or situations.” He contends that a knowledge base is exe- cutable because it contains information about how to combine, weigh and assess data. A data base, on the other hand, is passive and simply contains raw data that can either be queried or updated.

Conventional systems are most often developed using one of the more common procedurally oriented languages such as Fortran, Pascal or COBOL. Pro- grams developed using these languages are characterized by a mixture of objects, operators and control ~trategy.~ The resulting code is ultimately difficult to understand and modify.

The declarative programming style used to develop expert systems tends to result in code that is more explicit and straightforward. Declarative systems feature a separation of the available operators from the control strategy, which decides in what order to apply operators to solve a particular problem. The programmer is not responsible for creating an algorithm that specifies how to solve a problem, as is the case in conventional programming; instead, he/she simply specifies what is


known about the problem and the system determines how to solve it. The resulting code may be less efficient but is easier to understand and extend.

Code that is easy to change is a requirement of the development life cycle of an expert system. Expert systems are developed incrementally through successive extensions and modifications. The process is exploratory by nature; that is, when aproject is started, the method for solving a particular problem may not be known. As effort is expended on trying to better understand the problem, methods for solving the problem are slowly uncovered and added to the developing system. Feedback from the system is then used to further explore the problem. In com- parison, conventional systems are developed from strict design specifications drafted before the implementation begins. Hence, any methods used by the system to solve a problem must be completely specified in advance. Because of the complexity of problems most commonly solved by expert systems, it is not generally possible to completely specify a problem in advance.

One final difference concerns the reliability of system results. Expert systems are designed to simulate the problem-solving ability of an expert, and hence they can make mistakes. The recommendations they produce are generally neither correct nor incorrect, but only more or less plausible (Harmon and King 1985). This is due to the hueristic nature of their knowledge and reasoning mechanisms. On the other hand, the results procured by conventional systems, such as the billing system mentioned earlier, must be correct; otherwise they are simply not acceptable.

In summary, fundamental differences between expert systems and conventional systems exist, with each system “type” having certain weaknesses and advantages. By employing expert systems technology in conjunction with conventional computing techniques, it is possible to capitalize on the advantages of both. This trend is gradually gaining popularity and some companies are now using expert system technology to extend and enhance conventional information systems (McNurlin 1988).

Why Build Expert Systems Expert systems may offer a number of advantages, depending on the particular problem being solved. Expert systems:

provide a permanent record of expertise (they do not quit or retire); make high-level expertise available to less experienced employees; are consistent (results produced do not degrade because of fatigue or illness); are valuable educational tools that can be used to train employees; can operate in hostile environments such as inside a nuclear power plant; can assist in formalizing the knowledge of experts; “can be replicated for pennies; human experts require educational costs in the hundreds of thousands of dollars” (Firebaugh 1988); and


can distribute expert knowledge to a larger community (perhaps in more remote areas).

In essence, expert systems have the potential to provide a high payoff by reducing costs and increasing productivity and efficiency.

EXPERT SYSTEM DEVELOPMENT When considering the construction of an expert system, there are several crucial aspects that must be addressed. Presumably, there is a problem that needs a solution. First, that problem must be deemed well suited to expert system technology. If the problem is suitable, then some plan for building a system that solves the problem is needed. A plan should contain some guidelines governing the devel- opmental process and a rough estimate of the resources required. Part of the plan should include a decision concerning what tool (or tools) to use during the first phase of development.

This section of the paper attempts to define the criteria of a problem applicable to expert system technology and outlines the stages of the expert system development process. In addition, a brief description of the personnel involved in the process is given. In the following section, a summary of the broad spectrum of available development tools is given.

Problem Selection Criteria The current interest in expert systems has led many people to believe that all problems are suitable candidates for development as expert systems. Many problems should not, however, be solved using expert system technology. Cohventional computing techniques are considerably more refined as they have been in existence for a longer period of time. In general, a problem can be solved with less time, effort and risk using conventional techniques as opposed to expert system technology. Some problems, on the other hand, cannot be solved using conventional methods. Identifying the major characteristics of a problem can help determine which approach to use.

Luger and Stubblefield (1989) outlined an information set of guidelines for determining whether a problem is appropriate for an expert system solution:

“The need for a solution justifies the cost of building an expert system.” The application must have potential for producing a high payoff in terms of money, time or human life. Increasing accessibility to high-level expertise increases employee productivity and relieves the expert from mundane tasks so that he/she may pursue more lucrative work such as advanced research. In some areas, a nuclear power plant, for example, humans are needed to perform jobs that may be threatening to their well-being. Expert systems designed to alleviate potential danger to human life have obvious benefits. With the cost of building expert systems decreasing, the number of potential applications are increasing.


“Human expertise is not available in all situations where it is needed.” Human expertise is always in short supply and heavy demand, and thus is very expensive. It is therefore not always financially feasible or possible to have experts available whenever they are needed. In a small community hospital, for example, it is not financially possible to have a resident expert for each area of specialized expertise. In addition, whereas human experts may retire or move to a new job, expert systems provide apermanent wealth of knowledge. “The problem may be solved using symbolic reasoning techniques.” Rob- lems that require symbolic reasoning and not numerical processing, physical dexterity or perceptual skill are usually best suited for expert system development. “The problem domain is well structured and does not require commonsense reasoning.” Commonsense reasoning is a task easily performed by most humans because of our broad ranging knowledge. Current technology restricts the amount of knowledge that can be effectively stored and manipulated in a machine. As a result, expert systems are generally confined to reasoning in a very narrow and well-structured domain. “The problem may not be solved using traditional computing methods.” Traditional technology is less expensive and better understood; when possible, it should be used to solve problems. “Cooperative and articulate experts exist.” The success of a project depends greatly on the personality and skill of the expert or experts involved. The inability or unwillingness of an expert to communicate his/ her knowledge will inevitably lead to a project’s demise. “The problem is of proper size and scope.” To be feasible, a problem should not be too large or complex; to be of practical value, finding a solution to a problem must not be too easy. They key lies in finding a balance between the two objectives that will yield a manageable amount or risk.

Who Is Involved in Expert System Development? The primary players involved in the development of an expert system are the end user, the domain expert, and the knowledge engineer.

An end user is a person who eventually applies the knowledge contained within a newly developed system to practical, everyday problems. End-user pref- erence and ability influence design decisions, such as level of explanation, style of interface and extent of data editing. End-user support should be sought from the conception of a project through to its end. If end-user support is not enlisted early on in the project, developers run the risk of having the final system rejected.


A domain expert is a person who provides the bulk of a system’s knowledge (additional knowledge can be gathered from empirical data, case studies, texts and other sources), Preferably, a domain expert will be a leader in hidher field who possesses a good understanding of the domain and ability to solve difficult problems quickly and concisely. The quality of a domain expert is ultimately reflected in the performance of the resulting expert system, and hence a domain expert should be chosen with care.

Another important member of an expert system development team is the knowledge engineer.4 A knowledge engineer is a “person who designs and builds the expert system. This person is usually a computer scientist experienced in applied artificial intelligence methods” (Waterman 1986). A knowledge engineer should harbor a number of special qualities, including organizational skills, communication skills and creativity. In addition, a knowledge engineer should have an in-depth understanding of expert system technology. The main tasks performed by a knowledge engineer include selecting the software and hardware tools for the project, extracting knowledge from the domain expert and implementing knowledge in a concise and efficient knowledge base (Luger and Stubblefield 1989).

The remainder of the project team consists of programmers, support personnel, consultants and project managers.

Knowledge Engineering/Acquisition Process ‘ ‘Knowledge acquisition is the transfer and transformation of problem-solving expertise from some knowledge source to a program” (or knowledge base) (Buch- anan et a1 1983). Sources of knowledge include text books, data bases and human experts. In its most common form, knowledge acquisition occurs between adomain expert and a knowledge engineer.5 A knowledge engineer, through a lengthy set of interviews, acquires knowledge from a domain expert and transforms that knowledge for representation in a knowledge base.

Knowledge acquisition tends to be the bottleneck in the construction of many expert systems (Buchanan et al). There are several arguments that can be made to account for this fact. First, the knowledge engineer plays a large role in the con- version of knowledge from an expert to an expert system. In enacting this role, the knowledge engineer is required to converse extensively with the domain expert. However, communication between the expert and knowledge engineer is some- times clumsy and awkward, since the knowledge engineer’s initial familiarity with terminology is in most instances limited. Luger and Stubblefield mention a second problem that impedes the knowledge acquisition process: ‘‘Human experts are notoriously unreliable in explaining exactly what goes on in solving a complex problem. Often they forget to mention steps that have become obvious or even automatic to them after years of work in their field.” A knowledge engineer, for example, might conceivably consider broadcasting anhydrous ammonia as a cost- effective method for applying fertilizer. Not being familiar with fertilizer appli-


cation, when given a choice of application methods and fertilizer compounds, the knowledge engineer simply selects a combination of method and fertilizer compound that yields the lowest cost. To an agronomist, such a suggestion would seem ludicrous, since any nutrient in the fertilizer would be lost to the atmosphere. The agronomist, however, may fail to mention the seemingly obvious fact that anhydrous ammonia is a gas and therefore cannot be broadcast. Hence, communication problems that occur between the domain expert and the knowledge engineer often impede the development process.

Construction Phases The actual process of building an expert system cannot be described in a single, straightforward algorithm. The complexity of the construction process resists any formal definition, and hence expert system developers cannot rely on a sequence of well-defined steps to guide them during development. Alternatively, expert system developers have adopted an evolutionary method of construction, which at present appears to be the best approach.

The evolutionary concept of development complements the exploratory nature of expert system programming. A project generally begins with the construction of a demonstration prototype - “a small, demonstration program that handles a portion of the problem that will eventually be addressed” (Waterman 1986). The demonstration prototype is then analyzed by the domain expert and possibly the end users. Problems are identified through this analysis and suggestions are made on which area of the problem to focus during the next stage of development. Upon the expert’s recommendations, a second-cut prototype is created by modifying, extending and testing the original prototype. When developers of the second prototype, called a research prototype (Waterman), are satisfied with the test results, the new prototype undergoes another review. This process is repeated several times as the system progresses from a research prototype, to a field prototype, to a production model, and eventually to a commercial system (Waterman). It is through this process of successive refinement that expert systems evolve.

Although no standard sequence of steps exists to describe the expert system building process, Bruce Buchanan et al (1983) describe a set of highly inter- dependent stages that roughly characterize the tasks involved. The phases are termed identification, conceptualization, formalization, implementation and testing, respectively (see Figure 2).

While it is possible to describe each stage in sequence as a separate task, in reality a developing system will seldom progress through the stages as neatly as depicted in Figure 2. It is not uncommon for a knowledge engineer to be involved in tasks from several different phases concurrently. At any time during development, it is possible to regress to any earlier phase for some reworking or to skip ahead several phases without performing any intermediate tasks.


Testing V s d a l e Rulcs That Organize

Knowledge

The first phase, identijication, involves characterizing all aspects of the problem. This includes defining the problem and its scope, identifying required resources and personnel, and establishing a set of realistic goals for the project. To define the problem, the knowledge engineer in cooperation with the domain expert attempts to identify, isolate and verbalize key problem concepts and their relationships. In essence, the knowledge engineer is trying to uncover the knowledge used to solve typical problems in the domain.

One of the most difficult aspects of this phase is determining the scope of the problem. The knowledge engineer can gain insight into the size and complexity of the problem by posing a few typical problem scenarios for the expert to solve and then analyzing the breadth and depth of knowledge used by the expert to solve those problems. Using such means, the knowledge engineer is able to scale the project to a manageable size.

During conceptualization, the knowledge engineer and the domain expert work toward making the concepts and relations mentioned during identification more explicit. The knowledge engineer generally documents and diagrams information pertaining to the types of data available, relationships among objects in the domain, subtasks and strategies used to solve problems, and any constraints related to problem solving activities. At this point, an attempt to diagram a conceptual hierarchy of the domain space (or problem space) is usually undertaken. The domain expert’s input is crucial to the success of this phase. It is hidher respon- sibility to verify that the knowledge engineer’s conceptualization of the problem is correct before the next phase begins.

The next phase, formalization, involves expressing the key concepts, sub- problems and relations in a more formal manner, as dictated by the knowledge engineer’s choice of tools or framework. The knowledge engineer is concerned with selecting a representational framework that closely matches the characteristics of the problem at hand. Experience, informal experimentation with a preliminary

Reformulations Rcdcsigns A

Refinements Rulcs

Identify Problem --

Charactcnstics Requiremen;

Design Formulate Structure to Rulcs to

Knowledge Knowlcdge

Find Conccpts to Rcprcsent Knowlcdgc Conccp:

EXPERT SYSTEMS AND FARM MANAGEMENT 65 1

prototype, collaboration with the expert, and knowledge about the available tools and languages can help the knowledge engineer select an appropriate tool. At the completion of this stage, a set of formal specifications describing how to represent the problem using the chosen tools or framework should exist.

During implementation, the formal specifications outlined in the previous stage are used as the basis for the construction of a prototype system. Programmers, under the guidance of the knowledge engineer, encode the data, knowledge and problem-solving methods uncovered in previous phases. The resulting prototype generally consists of data structures, inference rules and a control strategy for applying data to the inference rules. The form of the prototype is dependent on the particular representation language or tool used and many have to change during development.

Once a working prototype is produced, the next phase, testing, can begin. The utility and performance of the prototype are evaluated against sample problems prepared by the domain expert. Observing the prototype’s behavior allows the domain expert to suggest possible modifications and extensions. Testing will generally uncover problems with the representational scheme, such as missing concepts and relations, knowledge represented at the wrong level of detail, or unwieldy control mechanisms (Waterman 1986). It is best to use sample problems that test the bounds of the system’s knowledge, challenging the systems performance and uncovering any weaknesses. Problems uncovered during a testing make it necessary for developers to recycle through the various phases of development.

PUTTING TOOLS INTO PERSPECTIVE Each craftsman has available to hidher a set of tools for performing a given job. A farmer, for example, has available many different machines, which can be loosely grouped into several different classes. He/she will have machines for seeding, a discer, a tractor, and harrows, for example, as well as machines for thrashing, such as a combine, a truck, and an auger. A knowledge engineer, like a craftsman, also has an available set of tools to help perform hidher job, namely, building expert systems.

‘‘Expert system tools are programming systems that simplify the job of constructing an expert system” (Waterman). Following the conventions of Waterman, we divide our discussion of expert system tools into four major categories, as depicted in Figure 3.

There are two basic types of programming languages, those being problem- oriented languages and symbol- manipulation languages. Traditionally, problem- oriented languages have been used successfully in scientific, mathematical and statistical applications. More recently, some attempts have been made to develop expert systems using these languages but, for the most part, the class of problem applicable to an expert system solution is not easily handled by a problem-oriented language. On the other hand, symbol-manipulation languages were designed spe-

652 CANADIAN JOURNAL OF AGRICULTURAL ECONOMlCS

manipulation

Programming Problem- Languages

Knowledge Engineering Languages

I I

Skeletal

General-

Aids acquisition

I 1-1 Design I 1

support Facilities Programming

I 1-1 Explanation I I

Figure 3 . Expert system tool categories

cifically to handle problems requiring an intelligent solution. Languages such as LISP and PROLOG allow for the creation and manipulation of symbols or collec- tions of symbols. Newel1 and Simon (1976) maintain that symbol manipulation is both a necessary and sufficient condition of intelligent behavior.

Languages such as LISP and PROLOG, while having the flexibility needed to solve a wide variety of problems, may require much effort to learn and use. In contrast, knowledge engineering languages are generally easy to learn and use but may not have the flexibility required to solve a problem.


Knowledge engineering languages were originally developed by A1 researchers specifically for the development of expert systems. In general, they consist of an expert system building language embedded in a supportive environment. The building language allows programmers to represent the expert’s knowledge using a representation scheme, such as rules or frames,6 and provides an inference engine for utilizing that knowledge. Support environments consist of various facilities for aiding programmers and end users. Some of the possible features include:

a windowing facility, a knowledge base editor,

a reporting facility, natural language interface, data base query support,

an explanation subsystem.

the ability to create pop-up menus,

access to procedural languages, and

Waterman (1 986) differentiates between two general categories of knowledge engineering languages, skeletal systems and general-purpose systems. Skeletal systems are simply “stripped-down’’ expert systems; that is, an expert system with all domain-specific knowledge removed. Examples include EMYCIN, derived from the MYCIN expert system, and KAS, derived from the expert system PRO- SPECTOR. This type of system, perhaps more than any other, lacks flexibility and generality. When considering the use of a skeletal system such as EMYCIN, a knowledge engineer must ensure that hidher particular problem is very similar to the problem originally solved by the corresponding parent expert system, in this case MYCIN. Expert systems can be developed quickly and with minimal effort by simply adding domain knowledge to a skeletal system. This appears to be the main incentive in their use.

General-purpose systems are still more restrictive than the programming languages mentioned previously; however, they tend to be less restrictive than the skeletal system. General-purpose systems may provide alternative control schemes, as opposed to a single control scheme, and the ability to customize the support environment. Commercially available examples of such systems include GURU, NEXPERT and PCPlus .

The next category of expert system tools is called system-building aids. There are basically two types of system-building aids: knowledge acquisition programs and system design aids. Knowledge acquisition programs assist the knowledge engineer in acquiring and representing the domain experts knowledge. System design aids help the knowledge engineer to design and build expert systems. Sys- tem-building aids are less common than the aforementioned tools and have only just begun to appear in the commercial market. In the future, these systems may prove to be useful aids for the knowledge engineer.


The last group of expert system tools can be loosely categorized as support facilities. Support facilities include tools for helping the programmer during development and tools for interfacing with the end user. These tools are generally provided as support environments with knowledge engineering languages. Some of the most common support facilities include debugging aids for tracing a system’s operation, VO facilities for accepting user input (i.e., queries, problem data) and generating formatted output (i.e., reports, replies), explanation facilities for jus- tifying system conclusions and lines of reasoning, and knowledge base editors for updating and maintaining the knowledge base. Each of these facilities may vary in capability and few knowledge engineering languages support all of them, although some may try.

AN APPLICATION IN AGRICULTURE

As a result of competition in world grain markets, it has become necessary for farmers to streamline production techniques and to increase the efficiency of their operations. The Manitoba Department of Agriculture has proposed several crop management methodologies to assist Manitoba farmers in attaining this goal. The purpose of these methodologies is to help maximize net returns on crop production investment. To maximize net returns, farmers must ensure that each management input is applied at the optimum rate and time. Crop management decisions must be made concerning seedbed preparation, seed selection, seed treatment, seeding rate and methodology, fertilizer application, and weed, insect and disease control. In all likelihood, many farmers do not have all the necessary knowledge or expertise to make effective decisions about each of these management inputs, and so help is often sought. However, the detailed knowledge needed to help farmers and advisers make effective crop management decisions is complex and scattered. To rectify this problem, researchers at the University of Manitoba from the Depart- ment of Computer Science, the Faculty of Agriculture, and the Solomon Sinclair Farm Management Institute have been examining the application of expert system technology to crop management decision making. The goal of this research is twofold:

to formalize decision-making expertise in the area of crop production,’ and

to make crop management expertise available to a broader population of farmers and advisers.

As part of this work, a prototype knowledge-based system, known as the Fertilizer Selection Adviser (FSA), has been developed to demonstrate the feasibility of providing assistance to farmers in making decisions about rates, sources, timing and methods of applying fertilizers. Although this project is still in its infancy, results produced so far have been very encouraging.


Problem Definition At present, Manitoba Agriculture has a system in place for aiding Manitoba farmers and advisers in making decisions concerning fertilizers. The main component of this system is the Provincial Soil Testing Laboratory. Farmers, agricultural rep- resentatives and fertilizer dealers send soil samples to the Provincial Lab for analysis of nutrient concentrations in the soil. On the basis of this analysis, fertilizer recommendations are provided. For all crops, a standard soil test recommendation is given, which suggests a single application rate for each nutrient required, as determined by the soil test performed. These recommendations are said to provide a good economic return under reasonable Manitoba growing conditions.

This system has been criticized by many as being somewhat crude. For instance, each farmer deals with a different set of crop and fertilizer prices and a unique set of growing conditions. One farmer, for example, may be able to capitalize on low prices for anhydrous ammonia, whereas a neighbor may not because of a lack of suitable equipment. Growing conditions, being highly dependent on soil type and climatic conditions, are also highly variable across many areas of the province as well as from year to year. Therefore, for the best results, farmers should have the results from the soil test interpreted by an agronomist and tailored toward hidher specific conditions before fertilization begins.

Ideally, recommendations concerning additional crop nutrients should take into consideration the following variables:

soil type, concentration of nutrients already in the soil (i.e., soil test results), soil moisture content at planting time, regional climatic conditions including growing season precipitation, the effect of method, cost and time of application on toxicity constraints and the efficiency of added nutrients, fertilizer compound nutrient analysis, form and price, and the client’s own preferences (a farmer may have certain equipment constraints, dollar constraints, safety preferences or simply a desire to stick with tradition).

Each of the above variables can take on many values. For example, climatic conditions, soil type and soil moisture content may take on a variety of different values from one field to another and from one year to another. Fertilizers can be applied either in the spring or fall using a single or combination of the following methods: banded prior to planting, banded with the seed, banded besidehnder the seed, or broadcast. The common nutrients, being nitrogen, phosphate, potash and sulphur, can be combined in numerous ways to yield the various fertilizer compounds in dry, gas or liquid form. The difficulty in making effective fertilizer recommendations lies in considering how to work with all the variables to arrive


at the best recommendation. For lack of a better term, we call this the fertilizer problem.

In theory, to solve the fertilizer problem, one could consider all potential recommendations by generating all possible combinations of the variables and selecting the most cost-effective alternatives (i.e., an exhaustive search of the problem space). In fact, such an approach is not viable, since the computational complexity of this problem is exponential in nature, implying that a “brute force” search of the problem space may take a very long time. Clearly, a better method for finding a solution to the fertilizer problem must exist.

Upon consultation with various experts in the field of crop management, it was determined that there was no formal algorithm used by agronomists for generating solutions to the fertilizer problem. It was discovered that, when making fertilizer recommendations, agronomists rely on experience, intuition, heuristics* and knowledge about the domain. The lack of a formal algorithm, combined with the recognition of informal methods used by agronomists for making fertilizer recommendations, suggested to the prototype development team that perhaps this problem was applicable to expert system technology.

Further investigation into the problem uncovered an additional interesting characteristic: with each recommendation, there is an associated degree of uncertainty or risk. Uncertainty enters the problem when attempts are made to predict certain variables, such as distant weather conditions and future grain prices. This discovery served to further convince the researchers that expert system development techniques were appropriate.

Problem Formulation In the philosophy of AI, the fertilizer problem is best characterized as a planning problem with constraints. The crux of the problem involves generating a plan that details when to apply the fertilizer, how to apply the fertilizer, in what amounts to apply the fertilizer, and what specific fertilizer compound to apply. When establishing this plan, certain constraints need to be taken into account, such as the toxicity limits of certain fertilizer compounds, cost of applying the fertilizer (including application costs and prices of the various compounds), and individual preferences (e.g., a farmer may have limited resources, including time, machinery and capital). The goal of a system designed to assist farmers in making fertilizer decisions is to develop a cost-effective plan while abiding by the given constraints.

To construct a fertilizer plan, a system needs knowledge about the domain and knowledge about problem solving in the domain. This knowledge must be structured into the system using some specific scheme known as a knowledge representation scheme. In the FSA prototype, knowledge is represented using an object-oriented approach. Objects may be physical objects that can be seen or touched (e.g., fertilizers, machinery) or conceptual entities such as acts, events or abstract categories (e.g., application methods, moisture categories)(Harmon


NAME: UREA TYPE: FERTILIER PRICE: $25Q/tonne FORM: DRY CONTENT: 46% Nitrogen.. . TOXICITY: IF applied with the seed

THEN maximum application of 2Olkg of Nitrogen Figure 4. An example object

and King 1985). In an object-oriented system, distinct entities are used to represent knowledge describing an object’s physical characteristics and its behavior. To supplement the object-oriented scheme, the FSA prototype incorporates a second knowledge representation scheme known as a rule-bused approach:

Rule-based knowledge representation centers on the use of IF condition THEN action state- ments. When the current problem situation satisfies or matches the IF part of a rule, the action specified by the THEN part of the rule is performed. This action may affect the outside world (e.g., cause text to be printed at the user’s terminal), may direct program control (e.g., cause a particular set of rules to be tested and fired), or may instruct the system to reach a conclusion (e.g., add a new fact or hypothesis to the data base). (Waterman 1986)

An example of an object supplemented with situation-action knowledge is given in Fig. 4.

In addition to knowledge about a problem domain, a system also needs case- specific data to formulate a plan. In the FSA system, data are made available via two sources: the user and data tables. The user, through an interactive exchange with the system, supplies information that is specific to hidher scenario, such as soil nutrient levels, soil type, crop variety and application preferences. User information varies for each problem. Data tables are used to store information that may vary occasionally, but not quite so often as user-supplied data. Examples of possible data tables include yield response tables for a variety of cereal crops, regional precipitation tables, and tables containing the market price for the different varieties of grain.

Task Overview The main objective in formulating a recommendation for fertilizer application is to maximize dollar returns on fertilizer investment. Returns are calculated by sub- tracting the total money invested in fertilizer application (i.e., costs) from the gross revenue procured from the sale of the harvested produce.

Consider first the effects of a single nutrient, nitrogen. If it is determined that the supply of nitrogen in the soil prior to fertilization is not sufficient to yield an optimal return,’ the cost of adding more nitrogen to the soil is considered. The total cost of additional nitrogen is equal to the sum of the cost of the fertilizer itself (i.e., the cost per unit increment of nitrogen times the number of increments) plus

65 8 CANADIAN JOURNAL OF AGRICULTURAL ECONOMICS

Gross hlargin Duc LO Nitrogcn Fcrulixr

Gross

Projected n Projcctcd

Revenue : Tolal Cost

olAddcd N i uogen

Y icld Crop Prim

cost or Application lricrcmcnlal costs

\ incrcascs in Tomi Nilrogcn Supply

Tomi A Soil

Moisture Niuogcn

Caccgory Supply in Soil A Application Mclhod

Fcrtililcr W of Niuogcn Application Comoound in Compound Efficiency

Pricc

Application Timc and Mclhcd

Figure 5. Task overview for a given level of existing nitrogen supply in soil

the application cost. Application costs are dependent on the method of application and include such expenditures as fuel, repair and labor. The cost per unit increment of nitrogen supply is a function of fertilizer compound price, percentage of nitrogen in the fertilizer compound,"and the efficiency by which the application method and time increases the nitrogen supply in the soil. For a summary of these depend- encies, see the right half of Figure 5.

Consider now the left half of Figure 5. Gross revenue is a function of the projected crop price multiplied by the projected yield. Yield is, to a great degree, dependent on available moisture and total nitrogen supply (including added nitrogen)

The task of determining the optimum yield - the yield that will provide the greatest margin of returns over fertilizer costs - is complex. Generally, yield is described as a function of nitrogen supply, as depicted in Figure 6 . The curve describing the yield at each increment in nitrogen can be derived in one of two ways. First, a complex equation based on such variables as water supply, nitrogen supply and growing degree days could be used to plot a continuous curve. However, to the best of our knowledge and of those involved in the development of the FSA system, no equation exists that can be used to accurately plot the yield response of any crop. Second, a tabular approach based on observations of multiple trials


3500 1

3000

2500

2000

1500

1000

I I I I I I I 1 0 50 100 150 200

Nitrogen Supply (kg/ha) Figure 6. An example of a yield curve for Neepawa wheat under moist growing conditions

under similar conditions can be used to estimate the response for set increments in nitrogen supply. The second alternative, a tabular approach, has been adopted for use in the FSA system. This approach, when illustrated graphically, results in a segmented curve. However, for illustrative purposes, the curve has been smoothed.

The specific values used for plotting the yield response curves are taken from the YieWNitrogen Supply Tables used by the Manitoba Provincial Soil Testing Laboratory (see Table 1). For each cereal crop, there are four separate tables, one for each of four moisture regimes (i.e., arid, dry, moist and imgated). Each table describes the average expected yield (kg/ha) for increments of total nitrogen supply in the soil. These tables, with slight modification to decrease the increments between data points, are used in the FSA prototype.

The second step in determining the optimum yield involves establishing a corresponding fertilizer cost curve (Figure 7). Cost curves are linear and can be calculated by determining the cost of adding one increment of nitrogen, using a specific application method and time, and a single fertilizer compound. The object of the decision-making process is to select a fertilization program that results in the lowest possible cost for a given yield and nitrogen supply. Thus, the FSA system is designed to prescreen the relevant information on fertilizer and application costs and efficiencies, developing a table of information describing gross revenue as a function of the least-cost combination of fertilizers and application methods. Combinations that do not result in the least cost for a particular level of


Table 1 . An example of a yield table for Neepawa wheat under moist growing conditions

Nitrogen supply Yield

0 10 20 30 40 50 60 70 80 90

100 110 120 130 140 150

800 1120 1440 1760 2080 2400 2675 2860 2980 3060 3 100 3140 3180 3180 3180 3180

nitrogen supply in soil are disregarded, except in cases where other constraints such as, for example, toxic limits for applying a certain fertilizer with the seed must be considered. Once completed, the cost curve is superimposed on the yield curve, and the point at which the distance between the two curves is greatest marks the maximum net returns for that fertilizer and method (Figure 8).

System Overview When the implementation phase of the FSA development project first began, no concrete decisions had been made concerning development tools. The project team thus began by exploring a variety of commercially available software packages. After experimenting with the PCPlus, GURU and NEXPERT system shells, it was decided that expert system shells simply did not provide the flexibility required for this project. Although development is known to be slower when A1 languages are used, the flexibility afforded persuaded the project team to develop the system using a version of Expert Common LISP. LISP is an acronym for List Processing and refers to the nature of LISP languages. LISP languages are largely geared toward the manipulation and interpretation of list structures. List structures are used to represent data structures and procedures. At present, the FSA system is being developed on a Macintosh; however, work has already begun on developing a similar system using C on an IBM 286 machine.

EXPERT SYSTEMS AND FARM MANAGEMENT 66 1

Total Fertilizer Costs ($/ha)

i 150.00

Thc cost curve is linear with a slope dctermined

by thc cost of incremental incrcascs in total nitrogen supply.

0 50 100 150 200

Figure 7. An example of a cost curve for one type of fertilizer and one application method Nitrogen Supply (kg/ha)

When completed, the FSA prototype will consist of three main components: a front end for interfacing with the user, a processing component, and an explanation subsystem (see Figure 9). The user interface will provide the system with

Revenue Curve Nccpawa What +

480.00 - 400.00 -

Maximum distance bctween curves

Optimum Yield I 0 1 I I * I I I I I

0 50 loo 150 200

Nitrogen Supply (kg/ha) Figure 8. A fertilizer cost curve superimposed on a revenue curve. The revenue curve is simply the yield curve from Figure 6 multiplied by a price of $160 per tonne

662 CANADIAN JOURNAL OF AGRICULTURAL ECONOMICS a Interface Module 12 Explanation Subsystem

Processing Module

Figure 9 , Components of the FSA system

a means of requesting data from the user, responding to questions from the user and displaying the final results. The processing component will use information supplied by the user as well as domain knowledge to formulate a recommendation. At the end of the consultation, any questions the user may have concerning the system’s recommendations may be directed toward the explanation subsystem.

The processing component of the system is divided into three separate phases: pre-processing, main processing, and post-processing (see Figure 10). The first phase, pre-processing, constrains the problem space to a manageable size. During this phase, possibilities not applicable to the specific problem are constrained out. For example, if the user has instructed the system to consider only a subset of the possible application methods as a result of availability of machinery, those application methods no longer rated are constrained out during pre-processing. Other constraints are not quite so intuitively obvious and may require extensive processing. At the end of this phase, a constrained possibilities list, now representing a reduced problem space, is passed to the next processing phase.

The second phase, main processing, performs the actual search of the problem space. The search performed during this phase is known as a constraint-directed search. Constraints introduced during the search process constrain the search space and decrease the necessary search time.” A good example of a constraint that might be encountered during the search process is a fertilizer toxicity limit. When considering the possibility of adding a fertilizer compound to the seed row, toxicity constraints govern the amount of fertilizer that can be added before damage to the seed occurs. The search algorithm must recognize these toxicity constraints and not surpass them when recommending the amount of fertilizer to apply. At the end of the search, a list of all solutions is presented to the user, with the most cost- effective alternative being highlighted. This alternative will detail the method (or combination of methods) that should be used to apply the fertilizer, the fertilizer compound (or compounds) that should be applied under each method, the cost per hectare of applying the fertilizer, the additional revenue generated as a result of


\Possibilities /

Y t I PRE-PROCESSING I

Constrain problem space

Reduced possibilities list

Search Algorithm Constraint-Directed

Sol 11 t ion list

POST-PROCESSING

Risk Analysis

Recommendations

Figure 10. Processing components

applying that fertilizer and, if all goes well, the forecast profit margin. Table 2 gives an approximation to the format of the generated solution.

During post-processing, the system attempts to perform risk analysis on a subset of the possible solutions to generate some form of feedback for the user. This feedback gives the user a rough estimate of the risk involved with each recommendation. In general, the amount of risk involved is proportional to the profit margin. For example, to attain the best possible profit margin, a farmer may decide to apply the maximum amount of fertilizer recommended by the system; however, if growing conditions do not remain favorable (e.g., drought, early frost, etc.), the amount of money invested that stands to be lost is quite substantial. The risk


Table 2. An example solution

Name: Solution- 1 Type: Recommendation Soil nitrogen supply: Expected crop price: Total nitrogen supply: Expected yield: Gross revenue: Fertilization costs: Gross margin: Components: A. Fertilizer:

Method: Amount: cost:

B. Fertilizer: Method: Amount: cost:

40 kglha $160lt 70 kglha 2815 kglha $460/ha $ 38/ha $442/ha

urea banded-with-seed 36 kgha $9/ha urea spring-broadcast 86 kglha $29lha

factor assigned to this recommendation would be correspondingly high. On the other hand, a farmer who is not quite so bold may decide to go with a lesser recommendation; in this case, the risk factor would be much lower because of the reduced chance of incurring a big loss. This analysis is designed to provide for maximum flexibility, allowing the user to select a recommendation that best matches his/her temperament and goals.

What the Future Holds At the conception of the project, it was agreed that after six months of work a review of the project would be undertaken to establish whether or not the project was feasible and to discuss the prospects of future funding. The six-month time period is drawing to a close and at present it looks as if the project will continue. The current prototype definitely displays the ability of an expert system to assist farmers and advisers with fertilizer decision malung. In addition, working on the prototype has enabled the people involved in the project o get a better understanding of the problem domain.

At present, the prototype is limited to solving only a representative sample of the possible problems. It is restricted to reasoning with one type of crop (wheat), four different moisture regimes (arid, dry, moist and irrigation), one soil nutrient (nitrogen) and four different fertilizer compounds (urea, ammonium nitrate, urea ammonium nitrate and ammonia). The user interface and the explanation subsystem need some refinement and the risk analysis component is still being designed.


Although the prototype appears somewhat limited, it has demonstrated the feasibility of expert system technology to applications in agriculture.

In the future, work will continue on the user interface module, allowing users to vary a greater number of parameters, and on the explanation subsystem. The system will also be expanded to reason with additional nutrients and a wider variety of crops. Because of the nature of the fertilizer problem, it will be necessary to devise a means for handling uncertainty. Certainty factors, as implemented in the MYCIN expert system, appear to be the most viable approach for this problem domain. To make the system more sensitive to specific growing conditions, data concerning soil and whether conditions from a variety of locations in the province will be collected and used by the system to fine tune its recommendations.

During development, much emphasis is being placed on making the system small enough and fast enough to run on an average-sized microcomputer. To improve portability, the prospects of developing an additional prototype using a language other than LISP is also being explored. The intent of the development team is to make the system available to a wide variety of users, including farmers, agronomists, government and private industry. Interest in the project is being expressed by all four of these groups. In the future, it is hoped that the FSA system will be put into use in the province of Manitoba to assist farmers with fertilizer decision making on a regular basis. The success of this system will inevitably lead to feasibility studies concerning the application of expert system technology to other farm management tasks, such as weed and pest control, crop rotation, and perhaps even financial planning.

SUMMARY

We have found that expert system technology is suitable to solving problems in farm management, for example, the fertilizer problem, because of several important features. First, the incremental development process is exploratory by nature, and hence it aids in the formalization of ill-structured and poorly understood problems. Second, explicit representation schemes make it easy to understand and modify knowledge; thus, it is much easier to make changes to a developing system. Third, through the use of extensive domain knowledge, an expert system considers only relevant information and is able to reduce difficult problems down to a manageable size. Finally, the ability of an expert system to provide explanations and justification for its recommendations decreases user scepticism and makes it possible to ensure that a system’s results are accurate. The construction of the FSA prototype has demonstrated the feasibility of applying expert system technology and techniques to a single farm management task. It is our estimation that this approach to increasing access to decision support resources in agriculture will continue on as a trend in the future.


NOTES ‘Bear in mind that most of the concepts discussed here are also applicable to knowledge- based systems. ‘A rule-based system is a system in which knowledge is represented using a specific technique. This technique is based on independent units of knowledge known as rules. More about this will appear later. ’An object is a group of related facts; operators manipulate objects; and a control strategy determines in what order to apply the operators to the objects. T h e equivalent to a knowledge engineer in a more conventional environment is the software engineer or system analyst. ‘Knowledge acquisition, by definition, may also occur between an expert and an intelligent editing program having access to a knowledge base or, alternatively, between a data source, such as a data base, and an induction program. The induction program, in theory, would draw inferences from the data and represent them in a knowledge base (Buchanan et a1 1983). ‘A frame is a knowledge representation method that associates features with nodes representing concepts or objects. The features are described in terms of attributes (called slots) and their values (Waterman 1986). ’Knowledge formalized in an expert system would provide a valuable educational tool for use by students in agriculture. ‘A heuristic is a “rule of thumb or simplification that limits the search for solutions in domains that are difficult or poorly understood” (Waterman 1986). ‘A discussion of how to determine the optimal return is given later in the paper.

of a fertilizer’s total composition. “This technique is commonly used to solve planning problems.

Fertilizer compounds may contain up to four nutrients, each accounting for a percentage 10

REFERENCES Buchanan, B. G., D. Barstow, R. Bechtal, J. Bennett, W. Clancey, C. Kulikowski, T. Mitchell, and D. A. Waterman. 1983. Constructing an expert system. In Building Expert Systems. Reading. Mass. : Addison-Wesley. Firebaugh, M. W. 1988. Artificial Intelligence: A Knowledge-Based Approach. Boston: Boyd and Fraser. Harmon, P. and D. King. 1985. Expert Systems. New York: John Wiley and Sons. Hart, P. 1986. Peter Hart talks about expert systems. IEEE Expert l(1). Luger, G . F. and W. A. Stubblefield. 1989. Artificial Inrelligence and the Design of Expert Systems. Cummings, Calif.: Benjamin. McNurlin, B. C., ed. 1988. Trends in artificial intelligence. IIS Analyzer 26(2). Miller, A. 1986. Expert systems: The StNCtUre. history, and future of successful A1 applications. IEEE Potentials, October. Newell, A. and H. A. Simon. 1976. Computer science as empirical inquiry: Symbols and search. Communications of The ACM. 19(3). Waterman, D.A. 1986. A Guide to E-rpert Systems. Reading, Mass.: Addison-Wesley.

Expert Systems and Farm Management

Documents

Transcript of Expert Systems and Farm Management