Next: Example `Pet Holder' Up: The Uncertainty Translator Previous: The Uncertainty Structure

## The Combination Function

As said before, the premises have to be functional; otherwise the combination function will produce an error. Premises defined by hornish clauses have to be changed into premises defined by footed clauses with a returned value in . This is performed by the RELFUN command footer, translating all hornish definitions into footed ones. footer expects an argument which represents the returned value of the constructed footed clauses. By default hornish clauses are understood as certain, thus their uncertainty factor is set to 1: footer acts like footer 1

The translation of uncertainty clauses into footed clauses (as described in section 1.1) is done with the function uncertain. Like footer it translates a whole database. uncertain expects the combination function combrule as argument, which may be a built-in or a user-defined function, either of which may be computed as the value of a higher-order function.

• uncertain min where min is a built-in function,
• uncertain myrule where myrule is a user-defined function,
• uncertain (cr) where cr is a (parameterless) higher-order function which returns a combination function (like a globally declared constant, this returned value can be changed easily). This can e.g. be useful in the `test phase' of a system, when combination functions are changed several times.
Altogether, the translation yields ft clauses, which can then be compiled as usual:

Even more than one combination function can be used in a single database. For that, all uncertainty clauses whose returned value is calculated the same way are added to the database. This is then translated with the chosen combination function. After that the next uncertainty clauses are asserted or consulted, and a second translation with another combination function follows, etc. This is no problem because the uncertain command only changes the uncertainty clauses, while footed clauses stay unmodified.

Note that uncertainty facts have no premises: (uc (c ..) UC_FACTOR), and no combination function is called to calculate uncertainty values:
(ft (c ..) UC_FACTOR).
So, if there are only uncertainty facts, it is insignificant which combination function is given to the uncertain command. Actually, it is no problem to write uncertainty facts directly as footed facts if the returned values are understood as uncertainty values.

We should note that our combination function combines values of the premises of a conjunction, hence could be called AND-combination function. Uncertainty systems often also permit what we may call an OR-combination function. However there is a restriction in handling uncertainty in backtracking languages like PROLOG or RELFUN: if there exists more than one solution for a query, then the individual solutions cannot easily be (OR-) combined into a final result (see the `certainty factors' used in MYCIN). But the observation that most of these OR-combined models are mathematically inconsistent anyway [3] makes this restriction appear an advantage. Only by using bagof or tupof , is it possible to deduce all solutions in our implementation, and then compute the solution with the greatest uncertainty factor of this collection of solutions (see function fetch [5] or reduce applied to maxp).

Next: Example `Pet Holder' Up: The Uncertainty Translator Previous: The Uncertainty Structure

Harold Boley & Victoria Hall (hall@dfki.uni-kl.de)