Local Logics

 

The logical foundations of Milord II have been the main topic of several papers, for instance [14, 18, 3, 2, 12]. It is based on a family of many-valued logics. Each logic is determined by a particular algebra of truth-values. Any of such truth-values algebra is completely determined as soon as the set of truth-values and the conjunction operator are fixed. In Milord II these logics can be local to each module. To declare a local logic (see Figure 9) the user has to write down the set of linguistic terms and the conjunction operation best adapted to the solution of the problem the module represents.

  
Figure 9: Syntax of local logic definition.

lingtermdef is the declaration of an ordered set of n linguistic terms , where stands for false and for true. For instance,

Truth values = (false, unlikely, may_be, likely, true)

conjunction is the declaration of the truth table of a conjunctive connective over the previously defined term set. A possible such operator, representing the min conjunction, could be,

Conjunction = truth table
             ((false false    false    false    false)
              (false unlikely unlikely unlikely unlikely)
              (false unlikely may_be   may_be   may_be)
              (false unlikely may_be   likely   likely)
              (false unlikely may_be   likely   true))

Different modules can have different local logics. We allow this because a very important part of any problem solving method is the way the programmer will deal with the uncertainty of the problem. And this may be particular to each subproblem: a richer set of linguistic terms can help in giving more precise answers to queries; different connectives represent different rule interpretations, and hence different deductive behaviours; even changing just the name of the terms from a module to another can make the knowledge represented in them more readable.

The main problem that has to be addressed in a system with local logics is how modules communicate and with are the properties that are to be held in that communication. That is, how a module has to interpret the answer to a query made to a submodule with a different logic. The topic is of great importance for the uncertainty research community [1]. The practical aspect of it is that any language providing such local logic facilities has to permit a way of defining the relation between the values of different logics. In the case of Milord II we do so by the declaration, in the local logic of a module, of a renaming function that maps the linguistic terms of the local logics of submodules into intervals of the linguistic terms of the module.

For instance, the translation of the terms of a module B, = {impossible, few_possible, slightly_possible, possible, quite_possible, very_possible, definite} to a module containing a local logic with terms = {false, unlikely, may_be, likely, true} could be expressed as the following sentence,

Renaming B/false ==> impossible
         B/unlikely ==> [impossible, few_possible]
         B/may_be ==> [few_possible, very_possible]
         B/likey ==> [very_possible, definite]
         B/true ==> definite

Milord II checks whether the proposed translation between modules satisfies the requirements expressed in [2, 1]. If the local logics are the same the identity renaming function is assumed by default and no renaming declaration is necessary.