Distributed problem solving

\label{des/know/xps} The motivation for proposing DLP for implementing problem solving and reasoning systems is twofold. First, there is the obvious need to structure knowledge in a, what once was called, frame-like system. That is were the constructs derived from object oriented programming come in. Cf.  [Ai80]. Secondly, there is the wish to distribute the reasoning among independent parts of the system in order to gain efficiency by exploiting parallelism. Cf.  [Da80]. In the realm of medical diagnosis systems an early attempt at distributing knowledge can be found in  [GC81]. Apart from proposing how to distribute knowledge as a hierarchy of medical concepts, it is suggested there to regard each concept as a specialist that is busy checking whether the observed symptoms justify the diagnosis of the particular disease represented by the concept. With respect to the organization of knowledge the key issues are the efficiency with which a diagnosis is found and how to focus and control the search. Although lacking any medical knowledge whatsoever we will sketch in global lines what the architecture of such a system might look like in DLP. The knowledge we do have of rule based medical expert systems comes to a great extent from  [Lu86]. The toy system that we will propose here is rule based, in the sense that the knowledge concerning a particular disease is stored in production rules that operate on a collection of established data. The declaration for the object containing the data is given below. \lprog{facts}{ .ds facts.pl } Clearly, one can ask whether a particular data item holds, that is if it is contained in the list of data. Also, data items may be added. For a particular patient the facts are accessible by all doctors that are trying to assess some diagnosis.

The inference engine

is the part responsible for the actual derivation of a possible diagnosis. It operates on a collection of facts, by applying knowledge contained in rules. \lprog{infer}{ .ds infer.pl } Before it may start to derive new facts, it must have the possession over an initial collection of facts and a body of knowledge. This requirement is met by including the sequence of accept statements in the constructor, and by providing the corresponding methods. The derivation itself proceeds by backward chaining. When a particular hypothesis is not yet established as a fact, its derivation is attempted by (recursively) applying some knowledge rule, stating that the hypothesis holds if certain premisses are fulfilled. If the derivation succeeds, the hypothesis is added to the facts already established. Now we come to defining a doctor as an entity that, having the capacity to infer, tries to establish a diagnosis on the basis of the facts and her knowledge. Somewhat naively, our doctor needs to refresh his knowledge with each case that presents itself. Due to this knowledge she knows what she is looking for. Establishing a diagnosis amounts to checking the possible hypotheses. \lprog{doctor}{ .ds doctor.pl }

Knowledge representation.

To illustrate the work of a medical doctor we must supply some (medical) knowledge. Since our intent was to give a clue how to organize knowledge in a hierarchic fashion we will start with specifying a generic object disease. \lprog{disease}{ .ds disease.pl } Apart from the rules that contain the knowledge needed to establish a diagnosis, the object contains also a list of possible diagnoses, which for the generic case simply states that a patient may have a disease. The rules inform us that a patient has a disease if he has fever, that is a high temperature. The knowledge concerning a disease contains also an indication of its possible causes. However, such knowledge is only necessary when one wants to consult a specialist. As an example of refining the generic object disease to a particular case consider the declaration for a liver disease. \lprog{liver}{ .ds liver.pl } Notice that, in accordance with our discussion in section \ref{des/know/inheritance}, the values of the variables diagnoses and causes are determined by the object containing the knowledge pertaining to a liver disease. Before going to a specialist, lets see what a doctor can do. .ds xps1.g After being informed of the symptoms of our patient, the doctor will on the basis of her knowledge concerning liver diseases, correctly diagnose a liver disease. Before being able to continue, we must enlarge our body of knowledge, according to the possible causes indicated for each disease. \lprog{knowledge}{ .ds lungs.pl .ds intrahepatic.pl .ds extrahepatic.pl } The knowledge that we have added contains some fictional rules concerning lung diseases, and some knowledge refining what we know about liver diseases. Neither for lung diseases nor for the intrahepatic and extrahepatic variants of liver diseases we seem to know any causes.

Cooperation and communication.

Our objective is to let a number of specialists cooperate in treating a patient. A specialist is a doctor that is specialized in some field of (medical) knowledge. Given a case, a specialist may state a diagnosis and advice what other specialists a patient must consult. \lprog{specialist}{ .ds specialist.pl } For treating a patient, we create a clinic. We assume that a clinic has an unlimited supply of specialists in all possible disciplines. \lprog{clinic}{ .ds clinic.pl } When a patient comes in, his complaints are filed and his treatment is started by assuming that he has a disease. The result of the treatment will be a list of possible diagnoses. The treatment is initially taken care of by a specialist that must assess whether the patient has a disease. If a specialist succeeds in establishing a diagnosis, then her advice with respect to the possible causes of the disease is used to try further treatment. If the list of possible causes is empty, then no possible diagnoses will be added, naturally. On the other hand, each possible cause may give rise to a new treatment, that may be executed in parallel with the exploration of alternative causes. Below we present the worst case that we can imagine. .ds xps2.g Please notice that apart from treating multiple cases simultaneously, we also may encounter parallelism in the exploration of possible causes, due to the parallel and-operator introduced in section \ref{des/ext/proc}. A more effective distribution of processing may be obtained by using the allocation primitives introduced in section \ref{des/ext/alloc}.