Truth Value Semantics and Logic Rule Mappings
Defining Truth Value types with specific semantics
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.
The following explanation is from the comment here.
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.:
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?
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.....
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.
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
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".
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.