Link types, truth values, and PLN

[Cosmo Harrigan]

Hi,

Following up on a recent discussion in: https://github.com/opencog/opencog/issues/587

Summarizing part of that discussion: 

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

My hope is that someone could assist me in constructing this enumeration. I have extracted the current lists and included them in this e-mail for convenience (warning - long email).

So, the complete enumeration of link types currently in use is the intersection of these lists: 

https://github.com/opencog/opencog/blob/master/opencog/atomspace/atom_types.script

https://github.com/opencog/opencog/blob/master/opencog/dynamics/attention/atom_types.script

https://github.com/opencog/opencog/blob/master/opencog/learning/pln/atom_types.script

https://github.com/opencog/opencog/blob/master/opencog/spacetime/atom_types.script

https://github.com/opencog/opencog/blob/master/opencog/nlp/types/atom_types.script

https://github.com/opencog/opencog/blob/master/opencog/embodiment/AtomSpaceExtensions/atom_types.script

which produces this list when parsed by OpenCog:

AfterLink

AndLink

AssociativeLink

AsymmetricHebbianLink

AtTimeLink

AttractionLink

AverageLink

BeforeLink

BindLink

ContainsLink

ContextLink

CosenseLink

DuringLink

EqualsLink

EquivalenceLink

EvaluationLink

ExecutionLink

ExecutionOutputLink

ExistsLink

ExtensionalSimilarityLink

FalseLink

FeatureLink

FinishedByLink

FinishesLink

ForAllLink

FrameElementLink

FrequencyLink

HebbianLink

HolonymLink

ImplicationLink

InheritanceLink

IntensionalInheritanceLink

IntensionalSimilarityLink

InterpretationLink

InverseHebbianLink

IsAcceptableSecondArgLink

LatestLink

LemmaLink

LinkGrammarDisjunctNode

LinkGrammarRelationshipNode

ListLink

MeetsLink

MemberLink

MetByLink

NotLink

OntologicalInheritanceLink

OrLink

OrderedLink

OverlappedByLink

OverlapsLink

ParseLink

PartOfSpeechLink

PredictiveAttractionLink

PredictiveImplicationLink

QuantityLink

ReferenceLink

SatisfyingSetLink

SchemaEvaluationLink

SchemaExecutionLink

ScholemLink

SequentialAndLink

SetLink

SimilarityLink

SimultaneousAndLink

SimultaneousEquivalenceLink

StartedByLink

StartsLink

SubsetLink

SymmetricHebbianLink

SymmetricInverseHebbianLink

TailPredictiveImplicationLink

TrueLink

TypedVariableLink

UnorderedLink

WRLink

WordInstanceLink

WordSenseLink

and the complete enumeration of currently existing PLN rules is:

AbductionRule

AndBulkEvaluationRule

AndEvaluationRule

AttractionRule

DeductionGeometryRule

DeductionRule

EvaluationToMemberRule

ExtensionalLinkEvaluationRule

ExtensionalSimilarityEvaluationRule

GeneralAtTimeEvaluationToMemberRule

GeneralEvaluationToMemberRule

InductionRule

InheritanceRule

InheritanceToMemberRule

IntensionalInheritanceEvaluationRule

IntensionalLinkEvaluationRule

IntensionalSimilarityEvaluationRule

InversionRule

LinkToLinkRule

MemberToEvaluationRule

MemberToInheritanceRule

MembershipBasedEvaluationRule

ModusPonensRule

NegatedSubsetEvaluationRule

OntologicalInheritanceRule

OrEvaluationRule

PreciseModusPonensRule

ProcedureEvaluationRule

SimilarityRule

SubsetEvaluationRule

SymmetricModusPonensRule

TermProbabilityRule

TransitiveSimilarityRule

and, for reference, here is a complete enumeration of current node types:

https://gist.github.com/cosmoharrigan/9534793

Thanks,

Cosmo

[Linas Vepstas]

Presumably, the PLN truth types apply *only* to the atom types that are given by the PLN types.script, and maybe some of the types in the core atomspace list.  The should NOT apply to any of the space-server, time-server, attention, NLP or embodiment types.  This is one reason why the various  atom-type lists appear in separate files to begin with: to clearly demarcate who uses what, for what purpose.

---linas

--
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 opencog+u...@googlegroups.com.
To post to this group, send email to ope...@googlegroups.com.
Visit this group at http://groups.google.com/group/opencog.
For more options, visit https://groups.google.com/d/optout.

[Ben Goertzel]

Cosmo,

The attached file goes thru the link types you listed above and
indicated which ones are, according to PLN, given Probabilstic, Fuzzy,
None or ??? truth values...

Basically -- the PLN logical link types are given probabilistic TVs
except for Member, Evaluation and Execution which are given fuzzy TVs.
The temporal link types are given fuzzy TVs. The attentional link
types are also given probabilistic TVs.

Various linguistics related link types are currently pretty much
crisp, but in a language learning context could get probabilistic TVs.

Any Atom that can take a probabilistic TV, can take a PLN TV, because
the PLN truth values are ultimately just particular ways of
summarizing / approximating / expressing probability distributions...
Whether such an Atom takes

-- a single number probability TV
-- a Simple PLN TV (s,c)
-- a more complex PLN TV like an indefinite probability

really depends on the application and the MindAgents etc., rather than
on the basic semantics of the Atom type...

The preponderance of Atom types is one of the complaints many OpenCog
newbies or outsiders have about the system, so imposing more explicit
order on the Atom types and their truth values seems a good step...

-- 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 opencog+u...@googlegroups.com.
> To post to this group, send email to ope...@googlegroups.com.
> Visit this group at http://groups.google.com/group/opencog.
> For more options, visit https://groups.google.com/d/optout.

--
Ben Goertzel, PhD
http://goertzel.org

"In an insane world, the sane man must appear to be insane". -- Capt.
James T. Kirk

"Emancipate yourself from mental slavery / None but ourselves can free
our minds" -- Robert Nesta Marley

[Amen Belayneh]

Hi Cosmo,

How are you thinking of implementing the categorization/restriction of Atoms to the type of TV they use?  

[Cosmo Harrigan]

Hi Ben,

Thanks very much for annotating the link types.

If you don't mind, could you also describe the correct mapping of probabilistic link type / fuzzy link type input/output to PLN rules, using the list of rules I included in the prior message?

Thanks,

Cosmo

[Ben Goertzel]

I believe the current PLN rules all act on probabilistic TVs, except
the following rules that are designed to convert:

EvaluationToMember
MemberToEvaluation
MemberToInheritance
InheritanceToMember

It would be reasonable to have additional fuzzy rules, but they're not
there now (e.g. one could have a fuzzy AND as a separate operator from
a probabilistic AND, etc. But we haven't experimented with that...)

ben



On Sat, Mar 15, 2014 at 1:24 AM, Cosmo Harrigan

[Cosmo Harrigan]

Hi Ben,

Thanks; I have some additional questions to clarify some points.

So, here are the 4 rules you listed as responsible for converting between the two types:

EvaluationToMemberRule

MemberToEvaluationRule

MemberToInheritanceRule

InheritanceToMemberRule

However, for EvaluationToMemberRule and MemberToEvaluationRule, if both MemberLink and and EvaluationLink belong to the 'fuzzy' category according to the spreadsheet, what does it mean to categorize them as 'converting'?

There are also these rules; do they also belong to that category?

GeneralEvaluationToMemberRule

MembershipBasedEvaluationRule

NegatedSubsetEvaluationRule

SubsetEvaluationRule

How about these?

LinkToLinkRule

GeneralAtTimeEvaluationToMemberRule

ProcedureEvaluationRule

Leaving the following rules, which would all be categorized as taking probabilistic inputs and creating probabilistic outputs, and not permitting fuzzy inputs and outputs, is that correct?

AbductionRule

AndBulkEvaluationRule

AndEvaluationRule

AttractionRule

DeductionGeometryRule

DeductionRule

ExtensionalLinkEvaluationRule

ExtensionalSimilarityEvaluationRule

InductionRule

InheritanceRule

IntensionalInheritanceEvaluationRule

IntensionalLinkEvaluationRule

IntensionalSimilarityEvaluationRule

InversionRule

ModusPonensRule

OntologicalInheritanceRule

OrEvaluationRule

PreciseModusPonensRule

SimilarityRule

SymmetricModusPonensRule

TermProbabilityRule

TransitiveSimilarityRule

Thanks,

Cosmo

[Ben Goertzel]

> However, for EvaluationToMemberRule and MemberToEvaluationRule, if both
> MemberLink and and EvaluationLink belong to the 'fuzzy' category according
> to the spreadsheet, what does it mean to categorize them as 'converting'?

They map fuzzy to fuzzy ... they just rearrange Evaluation expressions
to Member expressions
and vice versa...

> There are also these rules; do they also belong to that category?
> GeneralEvaluationToMemberRule

Also maps fuzzy to fuzzy

> MembershipBasedEvaluationRule
> NegatedSubsetEvaluationRule
> SubsetEvaluationRule

These output probabilistic truth values. If they encounter
MemberLinks, they utilize their fuzzy truth values appropriately....

> How about these?
> LinkToLinkRule

I don't know what it is, and am too sleepy to investigate ;)

> GeneralAtTimeEvaluationToMemberRule

Sounds like it must map fuzzy to fuzzy

> ProcedureEvaluationRule

I don't know what it is, and am too sleepy to investigate ...

Yes ;)

ben

[Cosmo Harrigan]

Hi Ben (and Jade),

I noticed that the Rule class has a boolean property called self.probabilistic_inputs. 

Some rule classes also inherit from superclass rule definitions: currently there are 4 superclasses, MembershipBasedEvaluationRule, LinkToLinkRule, BooleanLinkCreationRule, AbstractEliminationRule. Others inherit directly from Rule. 

I also found that there are some additional rules that weren't listed in the original e-mail.

So, I have summarized the current rule classes and class hierarchy here; please take a look:

https://docs.google.com/spreadsheets/d/1iSXwM2qSBuIXqRXzrORYM-eiI0mdUuiIE0RH3J5VTzw/edit#gid=0

Therefore, I think there are two actions needed:

No rule should inherit directly from Rule unless it is itself a superclass with other rules as subclasses. Therefore there needs to be additional superclasses defined. Jade, what do you think?

The cells highlighted in yellow need to be filled in or confirmed as correct. The cells in red seem to contradict with each other.

Thanks,

Cosmo

[Cosmo Harrigan]

Hi Amen,

I'm not sure.

One way to handle it might be to define a new level in the atom types hierarchy, so that Atom -> Link -> (FuzzyLink, ProbabilisticLink) and then redefine the parent types of each of the link types that those categories subsume accordingly. But is that a good idea? Linas, do you have any suggestions?

Cosmo

[Jade O'Neill]

I don't see why there needs to be an extra superclass called
"RulesThatDontInheritFromASuperClassButHaveNothingInCommon".

Link2Link is a base class to convert e.g. SubsetLink->InheritanceLink
(which is approximate but useful).

I'll look at the spreadsheet now

[Jade O'Neill]

That's an interesting idea. One potential problem is that every link
inherits from OrderedLink or UnorderedLink, and atoms don't have
multiple inheritance...

[Jade O'Neill]

There are rules MemberToInheritance and InheritanceToMember that
heuristically convert between probabilistic and fuzzy links. The
intention of self.probabilistic_inputs is that you could use
ModusPonensRule for example

Implication
Eval foo
Eval bar

Eval foo
|=
Eval bar

the modus ponens formula is defined based on probability, but eval
links use fuzziness, so the chainer would automatically use the above
rules (or related ones) to convert the fuzzy strength to probability
and back again...

I'd rather just store probabilities for most things rather than fuzzy
values, it seems more useful (at least for datamining applications
anyway). Note that you can do the same thing using first-order pln,
like so

Inheritance
conceptnode foo
conceptnode bar

foo <tv>
|=
bar <tv>

i.e. find the TV of a conceptnode. and the conceptnode would be
equivalent to a (specific) evaluationlink, but has a probability not a
fuzzy strength.

[Jade O'Neill]

ProcedureEvaluationRule isn't implemented, but what it's supposed to
do is run a Combo/scheme/c++/python/haskell procedure, and then record
an evaluationlink or executionlink, as in

evaluationlink predicateName someArguments <fuzzy tv returned by the
procedure itself>
or
executionlink schemaNodeName inputArguments outputArguments <maybe no
tv at all? ask ben>

[Ben Goertzel]

On Sat, Mar 15, 2014 at 9:05 AM, Jade O'Neill <jadi...@gmail.com> wrote:
> I don't see why there needs to be an extra superclass called
> "RulesThatDontInheritFromASuperClassButHaveNothingInCommon".

on the face of it, I agree w/ that ... I'm not sure what was Cosmo's
motivation though, he may have had something particular in mind...

[Ben Goertzel]

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

.. ben

[Jade O'Neill]

for now the pln rules just create a given type of link using the
formula's output tv, and the interpretation is assumed. so that would
have to be changed to create a fuzzy or probabilistic tv specifically

[Linas Vepstas]

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

[Ben Goertzel]

Hmmm..

First a general statement of design intention. The underlying
concept is that PLN should be able to reason about any data in the
Atomspace, not only about data specially prepared for PLN. Of
course, if someone wrote a different logic with truth value types PLN
cannot comprehend, then PLN could not reason correctly about these
Atoms, without modification. But insofar as possible, we'd like PLN
to be able to deal with all the Atoms in the Atomspace.

Now onto the particular point...

In PLN, an EvaluationLink simply signifies a predicate that takes some arguments
The default assumption of a crisp or fuzzy truth value for such a
predicate is made...

So e.g.

EvaluationLink <.2>
isHuman
Fido

means that Fido satisfies isHuman to degree .2, whereas

EvaluationLink <1>
isHuman
Cosmo

just means that Cosmo is human...

As I understand it, what you're doing is giving an EvaluationLink a
CountTV. But I don't understand the semantics. Can you give a
specific example?

Are you perhaps doing something like this?

(1)

EvaluationLink <CountTV: c>
BeforeInSentence
WordNode: cat
WordNode: animal

where c indicates the number of times a word-instance corresponding to
"cat" has occurred in the same sentence as, but before, the number of
times a word-instance corresponding to "animal"?

In PLN syntax as currently used, the closest we'd come to this is

(2)

AverageQuantifier
$X, $Y
AND
Inheritance $X (WordNode: cat)
Inheritance $Y (WordNode: animal)
Evaluation BeforeInSentence $X $Y


which averages over all ($X,$Y) known to the system, the degree to
which the given AndLink is true...

One could easily create a CountQuantifier similar to AverageQuantifier, so that

(3)

CountQuantifier
$X, $Y
AND
Inheritance $X (WordNode: cat)
Inheritance $Y (WordNode: animal)
Evaluation BeforeInSentence $X $Y


would have semantics identical to my posited example (1) above....
I.e. its truth value is equal to the number of occurrences of the
quantified predicate being true, rather than the probability of the
quantified predicate being true for a random argument...

And one could create a CountedRelationshipLink, so that

(4)

CountedRelationshipLink R (L1, .., Lk)

is defined as equivalent to

CountQuantifier
$X1 , ..., $Xk
AND
Inheritance $X1 L1
...
Inheritance $Xk Lk
Evaluation R (L1, .., Lk)

...


From your point of view, in terms of your current work, you wouldn't
care about the equivalence (4), but would simply replace your
EvaluationLinks with CountedRelationshipLinks....

But the relationship (4) would let PLN reason about your
CountedRelationshipLinks in a logically consistent way...

However, the above may be irrelevant, as my (1) above may represent a
mis-guess of what you're doing ;)

-- Ben

[Ben Goertzel]

> Are you perhaps doing something like this?
>
> (1)
>
> EvaluationLink <CountTV: c>
> BeforeInSentence
> WordNode: cat
> WordNode: animal
>
> where c indicates the number of times a word-instance corresponding to
> "cat" has occurred in the same sentence as, but before, the number of
> times a word-instance corresponding to "animal"?

That was garbled. I meant

***

where c indicates the number of times a word-instance corresponding to

"cat" has occurred in the same sentence as, but before, a

word-instance corresponding to "animal"?

***

[Cosmo Harrigan]

Actually, according to the documentation, the atom type system does support multiple parent types:

https://github.com/opencog/opencog/blob/master/opencog/atomspace/README#L57

I tried it, by changing the atom_types.script to contain:

// Basic Links

ORDERED_LINK <- LINK

UNORDERED_LINK <- LINK

PROBABILISTIC_LINK <- LINK

FUZZY_LINK <- LINK

INHERITANCE_LINK <- ORDERED_LINK, PROBABILISTIC_LINK

And then:

> from opencog.atomspace import *

> is_a(types.InheritanceLink, types.OrderedLink)

True

> is_a(types.InheritanceLink, types.ProbabilisticLink)

True

> is_a(types.InheritanceLink, types.UnorderedLink)

False

> is_a(types.InheritanceLink, types.FuzzyLink)

False

Would this be a good idea?

Cosmo

[Jade O'Neill]

Wow, you should definitely do it then.

On Mon, Mar 17, 2014 at 3:45 AM, Cosmo Harrigan

[Linas Vepstas]

On 15 March 2014 20:41, Ben Goertzel <b...@goertzel.org> wrote:

As I understand it, what you're doing is giving an EvaluationLink a
CountTV.  But I don't understand the semantics.  Can you give a
specific example?

Are you perhaps doing something like this?

(1)

EvaluationLink <CountTV: c>
    BeforeInSentence
    WordNode: cat
    WordNode: animal

where c indicates the number of times a word-instance corresponding to
"cat" has occurred in the same sentence as, but before, the number of
times a word-instance corresponding to "animal"?

More or less yes.  Some remarks: 

--  "the cat" would be far, far more likely than "cat animal".  

-- I plan to extend the above to more complex structures; so that, instead of the WordNodes above, there would be links of some sort, details TBD.   Any advice on what link types to use for this embedding would be useful (naively, they'd be EvaluationLinks too, so that it would be this hierarchical structure.)

-- There's not one or two 'BeforeInSentence' relations, there are millions of relations; part of the learning algo is to automatically cut down these millions to a much much smaller number.  (Instead of thinking 'BeforeInSentence', think 'link-grammar link type'; initially, there are tens of millions of link types)

-- I don't use all three fields of the count-tv; I currently use just two; besides the raw count, I also store log probability, or a relative entropy, depending on the situation.  Or I could invent another truth value that has a slot for entropy ... which would leave open the two basic strength-confidence TV slots for PLN ... but what values should be placed in the strength-confidence slots?  I'm interested in the relative frequencies of observing various patterns; how would these map to truth-hood and confidence?

In PLN syntax as currently used, the closest we'd come to this is

(2)

AverageQuantifier
    $X, $Y
    AND
       Inheritance $X (WordNode: cat)
       Inheritance $Y (WordNode: animal)
       Evaluation BeforeInSentence $X $Y


which averages over all ($X,$Y) known to the system, the degree to
which the given AndLink is true...

One could easily create a CountQuantifier similar to AverageQuantifier, so that

(3)

CountQuantifier
    $X, $Y
    AND
       Inheritance $X (WordNode: cat)
       Inheritance $Y (WordNode: animal)
       Evaluation BeforeInSentence $X $Y


would have semantics identical to my posited example (1) above....
I.e. its truth value is equal to the number of occurrences of the
quantified predicate being true, rather than the probability of the
quantified predicate being true for a random argument...

And what is the point of using this far more complex structure? What does it allow/achieve that (1) doesn't?

(3) has a much higher computational complexity: it requires far more atoms to store a word-pair, and is far harder to discover (as a frequent operation is to find all word-pairs of a given form).

And one could create a CountedRelationshipLink, so that

(4)

CountedRelationshipLink R (L1, .., Lk)

is defined as equivalent to

CountQuantifier
    $X1 , ..., $Xk
    AND
       Inheritance $X1 L1
       ...
       Inheritance $Xk Lk
       Evaluation R (L1, .., Lk)

...


From your point of view, in terms of your current work, you wouldn't
care about the equivalence (4), but would simply replace your
EvaluationLinks with CountedRelationshipLinks....

But the relationship (4) would let PLN reason about your
CountedRelationshipLinks in a logically consistent way...

But what would PLN conclude?  How would PLN make use of the truth value?   My counts currently range from 1 to several billion (a cpu-weeks worth of grinding on text goes through several billion words) and the corresponding relative entropies range from -20 to +20 or so.   I don't see how PLN would have a clue what any of this might mean.

--linas

[Cosmo Harrigan]

On Sat, Mar 15, 2014 at 9:05 AM, Jade O'Neill <jadi...@gmail.com> wrote:
> I don't see why there needs to be an extra superclass called
> "RulesThatDontInheritFromASuperClassButHaveNothingInCommon".

Perhaps not; I was just trying to think of how to best organize the rules into groups, something like what Ben described:

[Ben Goertzel]

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.....

>> CountQuantifier
>> $X, $Y
>> AND
>> Inheritance $X (WordNode: cat)
>> Inheritance $Y (WordNode: animal)
>> Evaluation BeforeInSentence $X $Y
>>
>>
>> would have semantics identical to my posited example (1) above....
>> I.e. its truth value is equal to the number of occurrences of the
>> quantified predicate being true, rather than the probability of the
>> quantified predicate being true for a random argument...
>
>
> And what is the point of using this far more complex structure? What does it
> allow/achieve that (1) doesn't?

Welll.... it makes explicit the relationship between the observed
statement about word-classes, and the particular word-instances making
up those classes.

Of course you could make that relationship explicit in some other way...

> (3) has a much higher computational complexity: it requires far more atoms
> to store a word-pair, and is far harder to discover (as a frequent operation
> is to find all word-pairs of a given form).

I don't think it's much harder to discover, but I agree it uses more Atoms...

I am not arguing that you should avoid using the more concise form
you've adopted. I'm just agreeing w/ your suggestion that you should
give it a different link type, to avoid confusion ...

Whether/when there is value in converting your
CountedRelationshipLinks or whatever into some other format for PLN to
reason on, is a different issue...

> But what would PLN conclude? How would PLN make use of the truth value?
> My counts currently range from 1 to several billion (a cpu-weeks worth of
> grinding on text goes through several billion words) and the corresponding
> relative entropies range from -20 to +20 or so. I don't see how PLN would
> have a clue what any of this might mean.

We have used PLN previously (a long-ago version) to do statistical text analysis

PLN would first of all deal with these counts by normalizing them into
probabilities
(in a pure NLP application, perhaps using a universe size equal to the
number of words
in the corpus analyzed. Otherwise, PLN contains an "optimal universe
size" formula
that guesstimates the normalization constant to use to normalize
counts into probabilities.)

The probabilities of conjunctions of words are not that useful in
themselves. But of course,
they can be used to derive various conditional probabilities, e.g. stuff like

P(Cat occurs in sentence S | animal occurs in sentence S)

P(Cat occurs in S to the right of animal | animal occurs in S)

P(Cat is linked to eat with an O link in a parse of S | cat and eat occur in S)

etc etc.

Intensional similarity can be used to find words that have similar
properties. Clustering could then be used to form classes of words
with similar intensional similarities, etc. etc.

I'm just mentioning a few simple examples; of course PLN could do many
things with this kind of data...

PLN intensional similarity is pretty similar to relative information;
it defines C to be a property of A with degree

[ P(C|A) - P(C) ]^+

and then rates entities as similar if they have similar properties...

One could tweak it to use log probabilities just as well; I doubt that
would make a big difference in practice...

So if one wanted, one could do the whole apparatus of our
language-learning proposal using PLN.... But I don't think that's a
critical point.... PLN doesn't do clustering, so it's not the sole
tool for implementing the language-learning proposal.... I see you
like entropies better than probabilities; but I suspect that whether
one is mainly manipulating probabilities or log-probabilities isn't
really the key point in getting language learning to work...

ben

[Ben Goertzel]

> So if one wanted, one could do the whole apparatus of our
> language-learning proposal using PLN....

Hastily/poorly phrase, sorry...

I meant, one could use PLN as the basic framework for implementing the
learning aspects of language-learning proposal; of course lots of other pieces
are needed like a parsing algorithm and a clustering algorithm etc.

>But I don't think that's a
> critical point.... PLN doesn't do clustering, so it's not the sole
> tool for implementing the language-learning proposal.... I see you
> like entropies better than probabilities; but I suspect that whether
> one is mainly manipulating probabilities or log-probabilities isn't
> really the key point in getting language learning to work...
>
> ben

[Linas Vepstas]

On 17 March 2014 07:06, Ben Goertzel <b...@goertzel.org> wrote:

We have used PLN previously (a long-ago version) to do statistical text analysis

they can be used to derive various conditional probabilities, e.g. stuff like

P(Cat occurs in sentence S | animal occurs in sentence S)

P(Cat occurs in S to the right of animal | animal occurs in S)

P(Cat is linked to eat with an O link in a parse of S | cat and eat occur in S)

I'm just mentioning a few simple examples; of course PLN could do many
things with this kind of data...

PLN seems to consist of two or three distinct things, mashed together.

1) A certain set of numeric formulas specifying how to combine truth values

2) An algorithm for doing backward/forward inference on ...

3) certain specific hypergraphs (primarily EvaluationLinks, but also  others, incl. InheritanceLinks, etc.)

I'm not sure how the code is written, but I'm thinking that 1, 2 and 3 could be/should be distinct from one-another, so that a capable programmer could change any one of these parts.

For me, #2 is the most interesting part; the structures, and the way I assign truth values to them are different, so #1 and #3 aren't s interesting.

--linas

[Ben Goertzel]

Hi,

> PLN seems to consist of two or three distinct things, mashed together.
>
> 1) A certain set of numeric formulas specifying how to combine truth values
>
> 2) An algorithm for doing backward/forward inference on ...
>
> 3) certain specific hypergraphs

True

>(primarily EvaluationLinks, but also
> others, incl. InheritanceLinks, etc.)

Inheritance and Implication are at least as primary as Evaluation to PLN...

> I'm not sure how the code is written, but I'm thinking that 1, 2 and 3 could
> be/should be distinct from one-another, so that a capable programmer could
> change any one of these parts.
>
> For me, #2 is the most interesting part; the structures, and the way I
> assign truth values to them are different, so #1 and #3 aren't s
> interesting.

There is nothing terribly special in the current PLN implementation of
#2, which was
written by Jade around 5 months ago...

I have suggested porting PLN's #2 to some sort of generic OpenCog rule
engine, as was
recently discussed in another thread

The deepest idea regarding PLN inference control is not yet
demonstrated -- it's the use of
ECAN importance spreading to avert combinatorial explosion. Cosmo and
Scott plan to
start experimenting with this "any week now" .... This aspect of
inference control, if it works,
would not be specific to PLN but would also work with other choices
for #2 and #3

#1 and #3 can be decoupled mathematically, but not so cleanly
decoupled in the current code.
For instance suppose one wanted to experiment with PLN vs NARS (Pei
Wang's inference engine)
on InheritanceLinks.... Does one then create NARSTruthValue objects,
distinct from PLNTruthValue
objects? This is OK but the current code doesn't allow us to specify
which kind of TV object goes
with a link upon its creation. Or do we differentiate between

InheritanceLink
+ PLNInheritanceLink // with a PLNTV automatically
+ NARSInheritanceLink // with a NARS TV automatically

??

Many design options exist, I'm not sure the best one. But anyway no
such system is systematically
implemented in the code right now...

ben