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}.