We have boldly stated that DLP promises to be a suitable
vehicle for implementing a variety of
distributed knowledge based systems.
Our argument in supporting this claim, however,
merely consisted in showing that our language is sufficiently
expressive for implementing the examples figuring
in the literature as somehow important.
One question that remains to be answered, if
no objections are raised to this procedure,
is how efficiently DLP can be implemented.
At this stage we must postpone the research necessary for efficiently
implementing DLP to the future,
although we find sufficient encouragement in the work
reported in [He86], describing an extension
of the Warren Abstract Machine that provides instructions for
process creation and communication among processes.
A different approach to supporting this claim would consist of
trying to establish the usefulness of DLP for (Distributed) AI
by enumerating the problems and requirements of this
field of research
and check whether DLP satisfies these needs.
Instead of an exhaustive treatment however we will highlight
one issue of crucial importance and provide some
pointers to the literature.
By far the most difficult problem to solve
in designing a (truly) distributed system
is not how to distribute the data but
how to tackle the problem of distributing control.
Apart from solving problems in a certain domain of expertise,
the system must somehow decide how to decompose a
complex task in subtasks.
Also, in many cases, a final answer must be constructed
from the pieces resulting from processing
the subtasks.
Several metaphors exist that describe different solutions
to these problems,
ranging from the image of a hierarchic (military-like)
organisation of processes to
a heterarchical (market-like) configuration
where processes buy or sell the needed capabilities. Cf. [Fo81].
A very interesting solution to the effective mating of
tasks and capabilities is provided in [Da80] where the active
participation of both processes needing and processes
offering a certain capability is described as
contract negotiation.
The idea is that a process that needs some task to
be performed broadcasts a message, inviting processes
to subscribe to the task and state their price.
After a certain time then the process that initiated
the subscription decides what offer, if any, is the most suitable.
Further negotiation may follow
if the process does not accept the task after all,
or if it needs some further information or capability to
perform the task effectively.
In the latter case the initiating process
may send the required information or capability.
Our distributed logic programming language, as we have
presented it, offers no facilities for
broadcasting messages.
It may be worthwhile to consider incorporating
a restricted broadcast facility, for instance
to send a message to all instances of a named object.
How to deal with shared instantiations of
logical variables however is not immediately obvious.
Moreover, although a bit tedious, such a broadcast
facility can be programmed in DLP as it is.
Sending information or clauses, on the other hand,
does not cause any problem,
since we have provided an assert statement,
that enables to dynamically modify the functionality
of an object.
These considerations do not allow to take our argument with
respect to the usefulness of DLP any further.
We must await (sic) real life applications written in DLP
before passing a final judgement.