Truth Value Semantics and Logic Rule Mappings

Defining Truth Value types with specific semantics

Proposal

It is proposed to replace what is currently called the SimpleTruthValue class with several classes so that the meaning is not overloaded in a confusing and potentially inconsistent manner.

Most importantly for current PLN work, SimpleTruthValue would become PLNSimpleTruthValue and PLNFuzzyTruthValue.

Discussion

The following explanation is from the comment here.

Ben:

In summary, I think it would be OK to replace SimpleTruthValue with
PLNSimpleTruthValue and PLNFuzzyTruthValue

The complexity swept under the rug by this terminology is that
PLNSimpleTruthValue actually means SimpleProbabilisticPLNTruthValue.   So
e.g. later on we will also have PLNIndefiniteTruthValue, which is a more
complex kind of probabilistic PLN truth value, and
PLNDistributionalTruthValue.   But it seems OK to me to use
PLNSimpleTruthValue as a shorthand for SimpleProbabilisticPLNTruthValue.

Note that we could also have

ProbabilityTruthValue // just a single probability
BinaryTruthValue
TernaryTruthValue // for discrete TV logics
FuzzyTruthValue // a single fuzzy membership degree

None of these have users at the moment, but the are logically sensible...

...

SUMMARY: my recommendation is for a list of types like


BinaryTruthValue
TernaryTruthValue
FuzzyTruthValue
ProbabilityTruthValue

PLNSimpleTruthValue ***
PLNFuzzyTruthValue ***
PLNIndefiniteTruthValue
...

and then others as needed...

It happens that the two marked *** are the ones we're using right now for
PLN .  But earlier prototype PLN code used PLNIndefiniteTruthValue and
there was some support for this in the C++ PLN code...

There are also other potential truth value types that Linas may want to describe further, e.g.:

Linas:

I am currently using EvaluationLinks  to give a name to relationships between atoms: viz.

EvaluationLink
    SomeNode "name-of-relationship"
    ListLink
        ...

For statistical counting I put CountTV's on the EvaluationLink only.  This discussion is making me think that sooner or later, my use of evaluation links will collide with PLN, 
and that perhaps it would be better to change this to some other, brand new link type, for example RelationshipLink.  So:

1) should I do this,

2) if so, should RelationshipLink inherit from EvaluationLink, or from something else?

3) Does PLN work with EvlautionLinks only, or EvaluationLinks and any link type derived from that?

Ben:

Linas, 

The useful point I'm going to make here is: Yes, I think it would make 
sense for you to use a different link type for these things you're 
using that I've called CountedRelationshipLinks... 

I don't think calling these RelationshipLinks is a good idea, because 
the word "relationship" is very broad.... 

Arguably "EvaluationLink" is not a great name either (evaluation is a 
pretty generic process) but it's been around a while and changing it 
would cause confusion... 

But names are not the most important point.  The key point is that 
you're using these links with a quite particular semantics, tied in 
with the CountTV objects attached to the links, and this semantics is 
not the same as that which is assumed for EvaluationLinks (which is 
plain old evaluation of crisp or fuzzy predicates on their arguments) 
.... So a different link type would be better..... 

Associating link types with truth value types

Discussion

The atom type system supports multiple parent types: https://github.com/opencog/opencog/blob/master/opencog/atomspace/README#L57

There is a mailing list thread here that discusses what link types are meant to be associated with what truth value types.

Cosmo:

The current SimpleTruthValue type leaves room for ambiguities; it would be good to refactor the code to replace these ambiguities with explicit types for the benefit of the humans that work with it.

So, there is a discussion to create various distinct truth value types. For simplicity, in this e-mail I will restrict discussion to the following two which are needed for PLN work that is in-progress today:

PLNSimpleTruthValue
PLNFuzzyTruthValue

I suggest that we need to construct a precise enumeration of:

- what link types are valid for each of those two truth values

- what PLN rules are valid for each of those link types

Ben:

Just brainstorming a bit ... an alternative or complement could be to 
organize the rules into superclasses such as 

+ ProbabilisticRule 
+ FuzzyRule 
+ FuzzyToProbabilisticRule 
+ ProbabilisticToFuzzyRule 

Somewhere, though, there would still need to be information indicating 
which Atom types have which TV type -- at least in the constructor 
that builds new Atoms of each type ;p 

Complete enumeration of mappings

An enumeration of link types, their associated truth value semantics, and the associated logic rules is described in this spreadsheet under the two tabs "Rules" and "Link Types".

Proposal

It is proposed that this spreadsheet should be converted into an implementation by subclassing the link types to enforce the link type/truth value type mapping, and constructing a mechanism in the PLN rule engine so that the rules accept typed inputs, where the inputs are restricted to the valid associated link types.