On 10/19/2016 08:40 PM, Ben Goertzel wrote:
Nil, others,
In working out w/Amen how to apply PLN to various Atoms derived from
natural language, I started to think we might want a truth value that
has the following fields:
***
float positive_evidence
float total_evidence // aka count, but this should be an OPTIONAL value
***
Where the total_evidence is defined one can then say
probabilistic strength = positive_evidence / total_evidence
The point is that for an Atom like the EvaluationLink in the construct
EvaluationLink
PredicateNode "eat"
List
ConceptNode "cat"
ConceptNode "mouse"
we can meaningfully accumulate a number indicating how many instances
of this relationship have been observed (the positive_evidence of the
I'm trying to understand specifically your problem. By instances I
suppose you mean
EvaluationLink (stv 1 1)
PredicateNode "eat_342"
List
ConceptNode "cat_132"
ConceptNode "mouse_243"
for a positive one.
Evaluation (stv 0 1)
PredicateNode "eat_635"
List
ConceptNode "cat_768"
ConceptNode "mouse_129"
for a negative one.
Then you're goal is to define the strength and count of
> EvaluationLink (stv strength count)
> PredicateNode "eat"
> List
> ConceptNode "cat"
> ConceptNode "mouse"
right?
But the calculation of strength depends on the semantics you want to
this TV to have, right?
There is no standard semantics for that according to PLN, as far as I know.
For instance you may say that the strength represents the probability of
cat eating a mouse vs not eating a mouse, and then your total count is
the sum of positive and negative instances.
> EvaluationLink (stv strength count)
> PredicateNode "eat"
> List
> ConceptNode "cat"
> ConceptNode "mouse"
I suppose the count would the number of all instances you have, and the
strength would the number instance with (stv 1 1) / by the number of
instances with (stv 0 1). But again that's up to the semantics you want
it to capture.
Link) ... but there's no obviously maximally meaningful way to
normalize this positive_evidence value into a probabilistic or fuzzy
strength value....
If there's no obvious way, it means the semantics is not completely
determined, then it needs to be determined...
If we apply Evaluation2Member to get
MemberLink
ConceptNode "mouse"
SatisfyingSet
VariableNode $X
EvaluationLink
PredicateNode "eat"
List
ConceptNode "cat"
$X
then we could meaningfully come up with some fuzzy strength, and if we
then apply M2I to get
InheritanceLink
ConceptNode "mouse"
SatisfyingSet
VariableNode $X
EvaluationLink
PredicateNode "eat"
List
ConceptNode "cat"
$X
Do you mean?
> InheritanceLink
> SetLink ConceptNode "mouse"
> SatisfyingSet
> VariableNode $X
> EvaluationLink
> PredicateNode "eat"
> List
> ConceptNode "cat"
> $X
that is what the PLN gives, which contradicts the implementation, which
match what you wrote... I'm confused.
then we can normalize the positive-evidence in the obvious way (i.e.
the total_evidence we want for the InheritanceLink is the total number
of entities satisfying the SatisfyingSet, within the assumed overall
universe of discourse)...
No, it is the count of (SetLink (Concept "Ben")), which is 1. Or if that
weird M2I as currently implemented rule is correct, it is the count of
(Concept "Ben"). Do we agree on that?
If this approach is right, then the PLN formulas like Eval2Member and
M2I would propagate positive_evidence values rather than strengths...
Since I can't make sense of these rules and I'm not sure what they are
supposed to be, I can't comment.
No changes for the PLN rules acting on straightforwardly probabilistic
links like InheritanceLinks would be needed, because these rules use
strength which can be derived from positive_evidence and
total_evidence...
Agreed.
Adding new TV types like this is annoying, but OTOH abusing the
"strength" or "mean" field in an existing TV type by making it mean
positive_evidence for certain link types, seems even more annoying...
Agreed. Ultimately I think we could offer a positive_evidence setter.
But I still don't understand the need for propagating positive_evidence
without knowing the total count.
Nil
Hopefully someone will bite the bullet and implement ProtoAtom soon ;p ;)
thoughts?
ben
--
You received this message because you are subscribed to the Google Groups
"opencog" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at https://groups.google.com/group/opencog.
To view this discussion on the web visit
https://groups.google.com/d/msgid/opencog/5808CC40.6030503%40gmail.com.
For more options, visit https://groups.google.com/d/optout.
