Simplifying the PLN rule-set: some possibilities...

[Ben Goertzel]

Cosmo,

The need for conversion rules between Concepts/Predicates and Member/Evaluation seems kind of a bitch...

A while ago Jade and I discussed a conceptually simpler solution, and I wonder if it might be a good time to incorporate it

The basic idea is: There's an obvious redundancy/symmetry in PLN between

ConceptNode : PredicateNode

InheritanceLink : ImplicationLink
SimilarityLink : EquivalenceLink
etc. etc.

The inference formulas are the same for both sides of the :   ...

Mathematically there is a difference between the two sides, e.g.

-- ConceptNode corresponds to a set

-- PredicateNode corresponds to a (fuzzy) indicator function of a set

And in terms of English language and human commonsense ontology there is a difference between entities and properties ..

So the difference between the two sides is not meaningless.  But it's a complication, which sometimes makes inference chains longer than they sensibly seem they should be...

Having PLN deal with {ConceptNodes and their links} and {PredicateNodes and their links} separately seems to lead to a lot of complication.  None of this complication is fundamentally problematic, as the conversions between the ConceptNode universe and the PredicateNode universe are crisp equivalences immediately derivable from the underlying math.  But this conversion to and fro does add complication.   And it leads to multiple PLN rules utilizing the same formulas -- which again is OK but not optimal...

An alternative might be to have PLN, internally, simply view the ConceptNode universe as if it were part of the PredicateNode universe.

That is, when PLN sees

ConceptNode "blah"

it interprets this automagically as

PredicateNode "_is_blah"

When it sees

MemberLink

    A

    ConceptNode "blah"

it interprets this automagically as

EvaluationLink

    PredicateNode "_is_blah"

    A

(where the names beginning with "_is_" are reserved for this purpose, if necessary)

When it sees

InheritanceLink

    ConceptNode "blah"

    ConceptNode "yakk"

it interprets this automagically as

ImplicationLink

    PredicateNode "_is_blah"

    PredicateNode "_is_yakk"

... and so forth...

In other words, PLN internally lives in a universe of PredicateNodes and associated links...

Then when it derives a conclusion, if the conclusion involves PredicateNodes with name starting with "_is_", PLN converts them back into ConceptNodes before sticking them into the Atomspace.

This allows the convenience of having ConceptNodes and associated links in the Atomspace, for cases where they are more intuitive, yet doesn't complicate PLN with a lot of conversions...

A subtlety here is that EvaluationLinks currently tend to have ConceptNodes as arguments, e.g.

(*)
EvaluationLink

    PredicateNode: eat

    ConceptNode: cat

    ConceptNode: mouse

But I guess that's OK, for instance if we had

(**)
EvaluationLink

    PredicateNode: eat

    PredicateNode: _is_cat

    PredicateNode: _is_mouse

we could agree to interpret ** the same way as (*)

We could use SatisfyingPredicate to denote the predicate corresponding to a SatisfyingSet...


Let's look at the Socrates example this way.  Suppose the premises are

Inheritance Socrates man

EvaluationLink
    breathe
    man
    air

Then PLN would see this as

Implication _is_Socrates _is_man

Implication
    _is_man
    SatisfyingPredicate
        Variable $X
        EvaluationLink breathe $X air

and a deduction would then yield

Implication
   _is_Socrates 
   SatisfyingPredicate
        Variable $X
        EvaluationLink breathe $X air

and we'd then need a rule mapping this into

Evaluation breathe Socrates air

i.e. the rule would have input

Implication
   PredicateNode: P
   SatisfyingPredicate
      $X
      ... some function F($X) ...

and output

F(ConceptNode corresponding to P)

ALSO...

I wonder if we might want to introduce a "macro rule" such as

Inheritance A B

Evaluation F A C

|-

Evaluation F B C

(and a similar one for the other arguments of EvaluationLink)

The truth value of this would be calculated  via the other formulas...

... ben

On Wed, Mar 19, 2014 at 5:39 PM, Cosmo Harrigan <notifi...@github.com> wrote:

@bgoertzel who do you envision as the "consumer" of ConceptToPredicateLinks? Which PLN rules would use them as input? I'm trying to figure out if they're just redundant or if they are a valuable shorthand.

—
Reply to this email directly or view it on GitHub.

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

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

[Cosmo Harrigan]

Hi,

On Wed, Mar 19, 2014 at 4:48 AM, Ben Goertzel <b...@goertzel.org> wrote:

The need for conversion rules between Concepts/Predicates and Member/Evaluation seems kind of a bitch...

In fact, I saw a related thread about it between you and Nil back in 2011 ("Is SatisfyingSetLink Necessary?"): 

https://groups.google.com/forum/#!msg/opencog/d4q-N4AgO38/-O6UNjm5vPkJ

Based on my initial reading of this, it would seem that having PLN do such mappings internally is almost equivalent in terms of algorithms and effort as explicitly implementing the conversions as PLN rules that output to the atomspace; in which case, I think we are better off continuing to output them to the atomspace. That way, they are explicitly represented, can be debugged, all representations are kept in one place, and the name attribute of the atoms isn't used to encode a macro.

On the other hand, if you thought the underlying atomspace representations needed to change, that would probably lead to different conclusions.

Thanks,

Cosmo

 

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

The underlying Atomspace representations are OK, they don't *need* to change...

It would be possible, though, to get rid of ConceptNode and associated link types from the Atomspace altogether, and represent sets only by PredicateNodes....

I am not sure if this would be better....  It would reduce the number of Atom types, and would not alter the representational capability of the system...

[Linas Vepstas]

Hi,

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

The basic idea is: There's an obvious redundancy/symmetry in PLN between

ConceptNode : PredicateNode

InheritanceLink : ImplicationLink
SimilarityLink : EquivalenceLink
etc. etc.

Not obvious if you are not  a PLN insider.   The remainder of the email does make it more or less 'obvious'  Can I convince someone to convert the bulk of this email into a wiki page?

--linas

[Linas Vepstas]

Reducing the number of link and node types would be great, as the sheer number and variety of them continues to be a stumbling block for both beginners and initiates.

From what I can tell, this proposal does not replace simpler graphs by more complex graphs, and that is good.  viz, although two graphs may be 'equivalent', the simpler one should be preferred.

The previously requested wiki page is still useful: it would explain why there are no links of certain kinds.

Aside from the three types mentioned in this email chain, what others are there?

--linas

[Joel Pitt]

FYI, The AtomSpace had a type hierarchy, and if I remember correctly it wasn't limited to a strict tree structure (e.g. you could have multiple parent types).

In the case presented, I'd create a parent type that can be used by PLN when the specific type is irrelevant to calculations (e.g. PLNNode, which both ConceptNode and PredicateNode are children of).

My graph library has a proper type hierarchy that includes the expected properties (e.g. tv type, attention value for only atoms that need it), but I'm not sure I'll continue to support multiple type inheritance. Still could potentially change it if there is a valid use case though.

--

[Ben Goertzel]

Hi Linas,

I will put the wiki page you mention on my TODO list.  I don't have time this week to write a wiki page about the PLN link types, or to write a long email on the topic, but I agree it would be useful..

Or maybe Cosmo or Amen or Alex can help with this, after their current push to get some more PLN functionality working..

ben
.

[Ben Goertzel]

Cosmo,

I understand why you wouldn't want to make a change of this kind to PLN right now, as you're trying to get some basic functionalities working in a hurry, and this would be a non-trivial change that would slow things down compared to just implementing some additional rules...

On the other hand, I think that the change I suggested would decrease the size of the average PLN inference tree considerably, which would ease inference control a bit, make inference chains easier to inspect/debug/visualize, and be generally worthwhile.

So I think it's worth further reflection...

-- Ben

On Wed, Mar 19, 2014 at 8:29 PM, Cosmo Harrigan <cosmo.h...@singularityu.org> wrote:

[Cosmo Harrigan]

Hi,

On Wed, Mar 19, 2014 at 6:04 PM, Ben Goertzel <b...@goertzel.org> wrote:

Cosmo,

I understand why you wouldn't want to make a change of this kind to PLN right now, as you're trying to get some basic functionalities working in a hurry, and this would be a non-trivial change that would slow things down compared to just implementing some additional rules...

On the other hand, I think that the change I suggested would decrease the size of the average PLN inference tree considerably, which would ease inference control a bit, make inference chains easier to inspect/debug/visualize, and be generally worthwhile.

 

So I think it's worth further reflection...

Certainly.

Do you think it might be a good idea to simplify the underlying representations used in the atomspace (after this current goal is reached)? Eliminating ConceptNode in favor of PredicateNode also seems to be what Nil had suggested before (here: https://groups.google.com/d/msg/opencog/d4q-N4AgO38/gT65NnMHSroJ).

Thanks,

Cosmo

[Ben Goertzel]

It might be a good idea to simplify the representations that are
habitually used for representing commonsense knowledge, yeah...

There is really no need to have both

ConceptNode: cat
PredicateNode: isCat

in the Atomspace, it just clutters and complexifies things

On the other hand, to the extent that a ConceptNode represents a set
with members, this is a mathematical construct that the Atomspace
should be able to represent...

But we do have SetLink, which embodies the notion of a crisp set....
And it's not clear that we need a node to represent a fuzzy set (as
ConceptNode currently does), when we have PredicateNode that
represents the membership function of a fuzzy etc...

So maybe we could kill ConceptNode and associated links and just leave
the higher-order PLN links. I'm not seeing why not to, at the
moment, but I should think about it slightly more...

The first-order links are needed to derive the higher-order links and
their associated formulas, on a theory level, but that doesn't mean
they're needed in the code...

-- Ben

[Linas Vepstas]

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

Hi Linas,

I will put the wiki page you mention on my TODO list.  I don't have time this week to write a wiki page about the PLN link types, or to write a long email on the topic, but I agree it would be useful..

Or maybe Cosmo or Amen or Alex can help with this, after their current push to get some more PLN functionality working..

I would like it better it Amen, Cosmo or Alex wrote this *before* their current push.  Being forced to write things down, and explain them clearly, has the side-effect of clarifying one's own understanding of what is going on.   With a clearer understanding, one often gets a flash of the right way to structure the code,  which means that the code that needs to be written can often get written faster, better and with less bugs.

So, don't be penny-wise and pound-foolish on important topics like this.

--linas

[Cosmo Harrigan]

What is the precise atomspace syntax for these terms from predicate logic?

- function/relation

- constant (a 0-ary function)

My understanding is that a function application should be expressed as a SchemaNode inside an ExecutionLink, where the first argument is the SchemaNode, the second argument is a tuple of inputs contained in a ListLink, and the third argument is the output contained in a SetLink. The SetLink would contain the extension (the satisfying set) of the predicate. However, I'm wondering why SchemaNode hasn't came up so far in the discussion of these redundancies. How does it fit in? Isn't that output an alternative representation of a ConceptNode?

Thanks,

Cosmo

[Ben Goertzel]

Yeah,

f(x) = y is

ExecutionLink
SchemaNode: f
x
y

I suppose.... and,

ExecutionOutputLink f x

has value

y

(i.e. if one has

ExecutionOutputLink
SchemaNode: f
VariableNode $X

then that construct is interpreted as

y = f($X)

depending on the value of $X

Of course PredicateNode and SchemaNode are redundant, as one could
replace PredicateNode with SchemaNodes that output TruthValues, i.e.

EvaluationLink <.8,.9>
PredicateNode: eat
cat
mouse

could be represented as

ExecutionLink <1>
SchemaNode: eat
ListLink cat mouse
TruthValueNode <.8,.9>

In the end, after all, we can represent everything with functions and
applications...

So the choice of Atom types is a balance between minimalism and convenience...

-- Ben

[Linas Vepstas]

FYI,

The current code & wiki documentation ignore ExecutionOutputLink, and instead use GroundedSchemaNode to indicate that y will be generated as a side-effect of touching the link.

i.e.  ExecutionLink

           SchemaNode f

           x y

means y = f(x)

and 

  ExecutionLink

      GroundedSchemaNode f

      x

means "call f in scheme or python to generate y"

Perhaps it would be cleaner to avoid the second form, use ExecutionOutputLink instead, and get rid of the now-un-needed GroundedSchemaNode  ?

--linas

[Cosmo Harrigan]

Hypothetically, if ConceptNode were removed, what would replace it as a compact representation of a set?

[Ben Goertzel]

Well if we really want a mathematical set there is SetLink

But for everyday concepts we could use PredicateNode instead, e.g.
isCat instead of Cat ...

ben

[Cosmo Harrigan]

Oh, I see. There is a lot of documentation as well as sections of the forthcoming EGI book that refer to ExecutionOutputLink / ExOutLink. I think it would be helpful to make this functionality work in that way.

Would that indeed remove the need for GroundedSchemaNode?

[Linas Vepstas]

Hi,

On 26 March 2014 22:28, Cosmo Harrigan <cosmo.h...@singularityu.org> wrote:

Oh, I see. There is a lot of documentation as well as sections of the forthcoming EGI book that refer to ExecutionOutputLink / ExOutLink. I think it would be helpful to make this functionality work in that way.

Would that indeed remove the need for GroundedSchemaNode?

As far as I know, what I said below is the only use of GroundedSchemaNode in the code.  It shouldn't be hard to do: twiddle a small block of code to use the new types.  This has a unit test, so should be safe.  Then do a grep across the entire code base to find all users of GroundedSchemanode -- there's some in embodiment -- no unit tests, so if you missed a spot, you might not know about it.

I've no opinion one way or the other.  Perhaps ExOutLink is less confusing for the beginner.

--linas

[Cosmo Harrigan]

But, for example, I think GroundedSchemaNode is also meant to be used to represent virtual agent control procedures and procedures learned from MOSES. Wouldn't it still be needed?

[Linas Vepstas]

I'm quite unclear as to what its "meant" to do, or who is meant to do it, or when.  I think you are asking about point D below.

I'm merely stating that:

A) Currently, the only use I'm aware of in the code base is that, *if* you hand the pattern matcher an ExecutionLink with a GroundedSchemaNode, it will call the designated function in python or scheme (or C++, too, maybe, if properly declared!? I forget.) and that function can do anything at all --control some agent, whatever.

B) It would not be hard to change this to be ExtOutLink + plain SchemaNode.  Its all located in /opencog/execution/ExecutionLink.cc

C) Perhaps PLN is at the point where it would also be interested in invoking code as well. It should almost surely use the same style.

D) I can't imagine what other code base would be interested in triggering ExecutionLinks, outside of the PLN or the PM contexts.   No one else is crawling over the atomspace, looking for execution links, and deciding that they need to be called. Of course, you could write code  to do this, and /opencog/execution/ExecutionLink.h provides a tiny, easy-to-use wrapper that enables this.

E) proceedures learned by moses should almost surely be formatted as scheme, not as combo, before being executed.  Just to avoid complexity. 

--linas

 

[Ben Goertzel]

My intention with defining these types was that ExOutLink would be
used together with GroundedSchemaNode...

I.e.

-- SchemaNode, in general, is for functions taking an input and
producing an output: including those that the system knows how to
execute, as well as those that the system just has general knowledge
about and doesn't know how to execute

-- GroundedSchemaNode is for SchemaNodes corresponding to functions
that the system knows how to execute

Thus, ExOutLink would often be used together with
GroundedSchemaNode... and the former would not obsolete the latter...

-- Ben


On Thu, Mar 27, 2014 at 11:28 AM, Cosmo Harrigan

[Ben Goertzel]

> A) Currently, the only use I'm aware of in the code base is that, *if* you
> hand the pattern matcher an ExecutionLink with a GroundedSchemaNode, it will
> call the designated function in python or scheme (or C++, too, maybe, if
> properly declared!? I forget.) and that function can do anything at all
> --control some agent, whatever.

Right. The intended difference between a GroundedSchemaNode and a
plain old SchemaNode, is that for the latter there is no "designated
function" ...

> C) Perhaps PLN is at the point where it would also be interested in invoking
> code as well. It should almost surely use the same style.

yes

> E) proceedures learned by moses should almost surely be formatted as scheme,
> not as combo, before being executed. Just to avoid complexity.

The textual Combo output format should die...

But, there's no need to convert a procedure learned by MOSES to some
textual form before being executed, is there? Why not just execute
the VertexTree directly?

ben

[Linas Vepstas]

So what's the practical difference between ExOutLink and ExecutionLink?  Why is ExOutLink needed?

--linas

[Linas Vepstas]

On 26 March 2014 23:24, Ben Goertzel <b...@goertzel.org> wrote:

> E) proceedures learned by moses should almost surely be formatted as scheme,
> not as combo, before being executed.  Just to avoid complexity.

The textual Combo output format should die...

But, there's no need to convert a procedure learned by MOSES to some
textual form before being executed, is there?  Why not just execute
the VertexTree directly?

Because the VertexTree doesn't actually hold AtomSpace Atoms, doesn't know anything about them.  Atoms aren't Vertexes.  And v.v.

Now, I can't read Nil's mind, and perhaps he has some plans to make the two interoperate.  But this gives me the willies:  I'm fearful of any tight coupling between these two fairly complex systems.

Put it another way: both Atoms, and Vertexes are somewhat inadequate for the tasks expected of them. Atoms are kind of bloated; Vertexes seem to be sliced&diced in the wrong direction. It be cool if conceptually they were somehow the same thing, but they are currently impossibly far apart.

--linas

[Ben Goertzel]

The original design suggestion was that

1)
ExecutionLinks keep a record of schema executions already done, i.e.
if f has already been evaluated on the input 2 and found to yield 4,
then we would record this data via

ExecutionLink f 2 4

2)
ExOutLink is used to trigger execution e.g. when PLN or some other process hits

ExOutLink f 3

it actually invokes the functional code associated with the
GroundedSchemaNode f , applied to the argument 3. The result of this
invocation could then be recorded via an ExecutionLink

...

However, the current code uses ExecutionLink in the manner that I
originally intended ExOutLink to be used, I think...

[linas]

FYI, 

I copied the intro of this email thread to a wiki page:

http://wiki.opencog.org/w/Idea:_Reduct_for_hypergraphs

that way, if there are further thoughts and developments on this topic, they need not be lost in the mists of the mailing list.

There is also now a 

http://wiki.opencog.org/w/Category:Ideas

that holds all idea wiki pages.

--linas