|
|
2. PROBLEMS WITH REUSE SOFTWARE OR SHARE KNOWLEDGE
Suppose you are commissioned by an aircraft company to build an intelligent system for aircraft design, diagnosis, prediction, repair, and maintenance. The system must be ready in a short period of time and at minimum cost. Then, instead of starting from scratch, you raise if it is possible to adapt knowledge from existing knowledge bases (KBs) into your new system. You have two options: reuse software and share knowledge.
If you select the option of reusing software already built, after carefully investigating applications produced by others, you decide which modules are potentially useful and usable in your system.
- The chosen modules satisfy 100% of your requirements. Then you can integrate them with your system, using a translator that umpires between existing programs and moderates the communication between them, or a capsule or container that covers the programs to be reused, or you have to completely rewrite the original program.
- The modules partially satisfy your requirements. Then you need to study carefully what portion (knowledge and software) is reusable for your objectives. Software Engineering provides guidelines, methods and techniques to reuse software made by others. Note that if the system you are trying to reuse is a KBS (knowledge-based system), together with the software reuse you are also reusing knowledge. In this case, after investigating which kind of knowledge and inference engines are reusable for your goals and which are not, you will probably find some of the following problems:
- The heterogeneity of knowledge representation formalisms (Neches et al., 1991). That is, each intelligent system has its own formalism to represent knowledge (rules, frames, logic, etc.) and its own techniques to perform inferences. The formalism and inference engine of the new system may, or may not, be coincident with those used in the systems you try to reuse.
- Supposing that the knowledge representation formalism and the inference engines of the two systems used to build the new system are the same, i.e., frames, then each system could have been implemented in a different language or shell from the target language in which the new system will be implemented. So, the heterogeneity of the implementation languages and shells could also be a problem when you try to reuse implemented knowledge.
- Even if the knowledge representation formalism and the computational environment of the source systems and of the new system are the same, additional problems emerge due to lexical problems. For example, the assertion that "person X is poor" could be represented in two knowledge bases as: "poor(x)" or "¬ rich(x)". If we mix these two expressions into one KB, it would be impossible to establish an inference sequence in which both sentences were involved simultaneously since the lexis used is not uniform.
- Even if the two KBs employ the same lexis, reusing their knowledge might be difficult due to semantic problems. This occurs when the new system and the source system use the same term with different meanings, that is, in different contexts. For example, the term "analysis" could refer to a blood analysis in medicine or to the activity to be performed during the life cycle of a software product.
- Additionally, synonyms may appear. In this case, different terms refer to the same concept. For example, "to pass" or "to be qualified" after doing an exam. A synonym problem always causes a lexical problem, but the reverse is not true. Note that the terms "poor" and "rich" are not synonyms.
- The hidden assumptions (Lenat, 1995) under which each system is built are important barriers if you try to reuse knowledge (e.g., assumptions about time, space, etc.). For example, the factor time in a medical system used in nonemergency situations (consultations) is usually treated implicitly in a discrete manner. Then if you try to reuse knowledge from this system to be processed in an intensive care unit, you may come up against serious problems since time is continuous there.
- Finally, loss of common sense knowledge; that is, it is always possible to forget something important, assuming something that everyone knows.
There are many strategies to solve these problems, including:
- Translators between formalisms and languages and tools could be developed to solve problems caused by the heterogeneity of the knowledge representation formalisms, languages, and tools. Since each language has its own expressiveness, much of knowledge is lost when the source is more expressive than the target.
- Ontologies constitute a warehouse of vocabulary to solve lexical, semantic, and synonym problems, as well as assumptions.
- Finally, machine learning, natural language understanding, and ontologies could be used to prevent loss of common sense knowledge. Machine learning and natural language are not appropriate since they need a broad KB underneath them, both to learn new knowledge and to do semantic disambiguation of terms (Lenat, 1995).
The second option is to share knowledge with other applications already built. In this approach, agents are distributed in agents networks. Agents ask other agents to solve problems according to a specific communication protocol. Independent systems carry out complementary tasks. One of the main problems of communication is the absence of a shared vocabulary pool. For example, if inside an American aircraft design system, distances are represented in "miles" and in a European aircraft diagnosis system distances are represented in "kilometers", and the European system requires information from the American system, someone must tell them that "a mile is about 1.6 kilometers." To share knowledge, you need to share the vocabulary and its meaning, a communication protocol between agents, and an interlingua.
|