Re: [opencog-dev] Re: Pattern mining from PLN inference histories

['Nil Geisweiller' via opencog]

Shujing, in

<OPEMCOG_ROOT>/opencog/learning/PatternMiner/types/atom_types.script

you've defined

PATTERN_LINK <- UNORDERED_LINK

but such a link type already exist in

<ATOMSPACE_ROOT>/opencog/atoms/base/atom_types.script

Nil

On 06/19/2017 12:01 PM, Nil Geisweiller wrote:

Actually patterns involving scopes require quote links. Let me consider the following pattern (the simplest of that sort I could find):

;Pattern: Frequency = 6
(ExecutionOutputLink (stv 1.000000 1.000000)

(GroundedSchemaNode "scm: conditional-full-instantiation-formula" (stv 1.000000 1.000000))

   (ListLink (stv 1.000000 1.000000)
     (EvaluationLink (stv 1.000000 1.000000)
       (PatternVariableNode "$var_1" (stv 1.000000 1.000000))
       (ListLink (stv 1.000000 1.000000)
         (PatternVariableNode "$var_2" (stv 1.000000 1.000000))
         (PatternVariableNode "$var_3" (stv 1.000000 1.000000))
       )
     )
     (ImplicationScopeLink (stv 1.000000 1.000000)
       (VariableList (stv 1.000000 1.000000)
         (TypedVariableLink (stv 1.000000 1.000000)
           (VariableNode "$X" (stv 1.000000 1.000000))
           (TypeNode "ConceptNode" (stv 1.000000 1.000000))
         )
         (TypedVariableLink (stv 1.000000 1.000000)
           (PatternVariableNode "$var_4" (stv 1.000000 1.000000))
           (TypeNode "ConceptNode" (stv 1.000000 1.000000))
         )
       )
       (EvaluationLink (stv 1.000000 1.000000)
         (PatternVariableNode "$var_1" (stv 1.000000 1.000000))
         (ListLink (stv 1.000000 1.000000)
           (VariableNode "$X" (stv 1.000000 1.000000))
           (PatternVariableNode "$var_4" (stv 1.000000 1.000000))
         )
       )
       (EvaluationLink (stv 1.000000 1.000000)
         (PatternVariableNode "$var_1" (stv 1.000000 1.000000))
         (ListLink (stv 1.000000 1.000000)
           (PatternVariableNode "$var_4" (stv 1.000000 1.000000))
           (VariableNode "$X" (stv 1.000000 1.000000))
         )
       )
     )
     (EvaluationLink (stv 1.000000 1.000000)
       (PatternVariableNode "$var_1" (stv 1.000000 1.000000))
       (ListLink (stv 1.000000 1.000000)
         (PatternVariableNode "$var_3" (stv 1.000000 1.000000))
         (PatternVariableNode "$var_2" (stv 1.000000 1.000000))
       )
     )
   )
)

Let me

1. wrap it in a SatisfyingSetScopeLink
2. attempt to add a meaningful TV
3. remove the non-zero confidences elsewhere
4. add the required quotes

(SatisfyingSetScopeLink <strength=6/N, count=N>  ;; not sure about N
   (VariableList
     (TypedVariableLink
       (PatternVariableNode "$var_1")
       (TypeNode "PredicateNode")
     )
     (TypedVariableLink
       (PatternVariableNode "$var_2")
       (TypeNode "ConceptNode")
     )
     (TypedVariableLink
       (PatternVariableNode "$var_3")
       (TypeNode "ConceptNode")
     )
     (TypedVariableLink
       (PatternVariableNode "$var_4")
       (TypeNode "VariableNode")
     )
   )
   (Quote
     (ExecutionOutputLink
       (GroundedSchemaNode "scm: conditional-full-instantiation-formula"
       (ListLink
         (EvaluationLink
           (UnquoteLink (PatternVariableNode "$var_1"))
           (ListLink
             (UnquoteLink (PatternVariableNode "$var_2"))
             (UnquoteLink (PatternVariableNode "$var_3"))
           )
         )
         (ImplicationScopeLink
           (VariableList
             (TypedVariableLink
               (VariableNode "$X")
               (TypeNode "ConceptNode")
             )
             (TypedVariableLink
               (UnquoteLink (PatternVariableNode "$var_4"))
               (TypeNode "ConceptNode")
             )
           )
           (EvaluationLink
             (UnquoteLink (PatternVariableNode "$var_1"))
             (ListLink
               (VariableNode "$X")
               (UnquoteLink (PatternVariableNode "$var_4"))
             )
           )
           (EvaluationLink
             (UnquoteLink (PatternVariableNode "$var_1"))
             (ListLink
               (UnquoteLink (PatternVariableNode "$var_4"))
               (VariableNode "$X")
             )
           )
         )
         (EvaluationLink
           (UnquoteLink (PatternVariableNode "$var_1"))
           (ListLink
             (UnquoteLink (PatternVariableNode "$var_3"))
             (UnquoteLink (PatternVariableNode "$var_2"))
           )
         )
       )
     )
   )
)

Nil

On 06/19/2017 11:24 AM, Nil Geisweiller wrote:

Shujing, just please don't set the confidences inside the patten to 1.0 like in

(ExecutionOutputLink (stv 1.000000 1.000000)

(GroundedSchemaNode "scm: bc-deduction-formula" (stv 1.000000 1.000000))

   (ListLink (stv 1.000000 1.000000)
     (InheritanceLink (stv 1.000000 1.000000)
       (PatternVariableNode "$var_1" (stv 1.000000 1.000000))
       (PatternVariableNode "$var_2" (stv 1.000000 1.000000))
     )
     (InheritanceLink (stv 1.000000 1.000000)
       (PatternVariableNode "$var_1" (stv 1.000000 1.000000))
       (PatternVariableNode "$var_3" (stv 1.000000 1.000000))
     )
     (InheritanceLink (stv 1.000000 1.000000)
       (PatternVariableNode "$var_3" (stv 1.000000 1.000000))
       (PatternVariableNode "$var_2" (stv 1.000000 1.000000))
     )
   )
)

this will confuse PLN. The only greater-than-zero confidence should be on the link wrapping the pattern, SatisfyingSetScopeLink or such.

Other than that they look OK. Of course they should be wrapped in an appropriate link and given a meaningful TV. I'm thinking we probably want to use a conditional link, an implication, inheritance, or perhaps context link, as opposed to a SatisfyingSetScopeLink, but we can figure that out slightly later.

Nil

On 06/19/2017 11:05 AM, Nil Geisweiller wrote:

Hi,

sorry, I was trapped in a variadic-template-hole. I managed to escape but not without bringing back a vicious gift. Now everything looks like a variadic template to me.

On 06/14/2017 04:32 PM, Shujing Ke wrote:

3)GroundedSchemaNode and TypeNode are not considered to become VariableNodes. Seems it doesn't make a lot of sense to make them into variables. Also, if they become Variables, there are errors because the atom core will check the types and get the opencog::SyntaxException below: Unexpected contents in TypedVariableLink Expected type specifier (e.g. TypeNode, TypeChoice, etc.), got PatternVariableNode

and
    ExecutionOutputLink must have schema! Got (PatternVariableNode ...

These errors should go away if you quote them.

4)In current stage, both VariableNode and PatternVariableNode are used to distinguish the Variables generated by Pattern Miner and the original Variables. We can unfiy them later if need.

As soon as these variable are scoped it can be unified. I don't mind to retain PatternVariableNode if it has a specific semantics, otherwise it should go.

*2. About pattern gram*

Actually in this application, only 1-gram patterns are wanted. In previous applications, like mining from DBPedia and conceptnet, n-gram pattern contains n Links, but the Link is relatively small, like one EvalutionLink or Inheritance Link. For example:

  EvaluationLink
          PredicateNode "Country"
          ListLink
                "var_1"
                 "USA"
  EvaluationLink
          PredicateNode "Language"
          ListLink
                "var_1"
                 "English"

Above is a 2-gram pattern, because each fact in DBPedia is just one EvaluationLink. This two Links are connected via the variablenode "var_1". But in the pln corpus case, each ExecutionOutputLinks is big, it contains a lot of Links in it. It seems we don't really want the patterns that contains multiple ExecutionOutputLinks in one single pattern; but we want to find the common abstract patterns of each single ExecutionOutputLink. So it is actually just 1-gram.

I'm confused, is it a 2-gram because the pattern is the conjunction of 2 EvaluationLinks, or because each pattern pattern has 2 links in them (EvaluationLink and ListLink)?

BTW, I think you could use AndLink root links to denote conjunctions of patterns, like in the pattern matcher, so for instance the pattern above would be

SatifyingSetScopeLink
   Variable "var_1"
   AndLink
     EvaluationLink
       PredicateNode "Country"
       ListLink
         "var_1"
         "USA"
     EvaluationLink
       PredicateNode "Language"
       ListLink
         "var_1"
         "English"

In case you want to represent a pattern of AndLink you could local quote it, like

SatifyingSetScopeLink
   Variable "var_1"
   LocalQuoteLink
     AndLink
       EvaluationLink
         PredicateNode "Country"
         ListLink
           "var_1"
           "USA"
       EvaluationLink
         PredicateNode "Language"
         ListLink
           "var_1"
           "English"

like in the pattern matcher. What do you think?

*3. The interestingness evaluation is different from previous application*s Our interestingness evalution is based on surpringness measure, which includes Surpingness_I and Surpringness_II: Surpingness_I : how difficult the actual frequency of a n-gram pattern can be infered from all its (n-1)-gram to 1-gram subpatterns' frequency. Surpingness_II : how difficult the actual frequency of a n-gram pattern can be infered from all its (n+1)-gram super patterns' frequency. But in the pln corpus, we only mine 1 gram, and I guess the interesting patterns here you want to identify is the patterns of "the max degree of abstraction" , for example: pattern1: (x and y are friends) (x is musician) (y is musician) (z is musician) (z and y are friends)->(x and z are friends) pattern2: (x and y are friends) (x is var_job) (y is var_job) (z is var_job) (z and y are friends)->(x and z are friends) If pattern 1 occurs 10 times; pattern 2 also occurs 10 times, it means that pattern 2 only be right when var_job = musician, which means the abstraction to be pattern 2 is no sense. So patten 1 is already the max degree of abstraction in this case. If my unerstand is right, then I will need to write a new interestingness evalution for this, because it is different from the surpringness measure.

That sounds right but I think I need to understand better how the pattern miner algorithm operates. I'll look into that soon.

*4. Unify the link order in unordered Links*

In current stage, I haven't unify the order of Links in unordered Links in the corpus, like AndLink. For example: In the AndLink below in the corpus, the 3 EvaluationLinks are possible to be in a different order for different instances, which will affect the structure of the AndLink, but they actually should be order independent. So if this sistuation does exist in the pln corpus other other applications in future, I may need to unify the order of the input Links to be a unique order (just like the pattern isomorphic problem I solved before in pattern miner), but I am not sure I can find a way to make all of them have an a unique order; the worse case, we have to generate all the possible combinations for each unorderedLink in its patterns.

                   AndLink
                     EvaluationLink
                       (PredicateNode "are-friends")
                        ListLink
                         (ConceptNode "John")
                         (VariableNode "$Y-37aad5ea")
                     (EvaluationLink
                       (PredicateNode "is-musician")
                       (VariableNode "$Y-37aad5ea")
                     (EvaluationLink
                       (PredicateNode "is-musician")
                       (VariableNode "John")

Yes, this is gonna be needed, although for now it can wait I think. Regarding how to solve it, I afraid you're gonna have to consider all permutations, like the unifier and pattern matcher do.

Nil

Thanks,
Shujing

On Mon, Jun 5, 2017 at 9:09 AM, Nil Geisweiller <ngeis...@googlemail.com <mailto:ngeis...@googlemail.com>> wrote:

    Hi Shuijing,

    that is where CHandle could be useful. If there are equal it means
    they are bound to the same scope, and thus should be considered the
    same. In practice you won't find many patterns with persistent
    original variables because these variables will have different
    scopes at most of the time, thus they will likely be replaced by
    pattern variables.

    So for example if you get the 2 groundings

    > (ExecutionOutputLink
    >     (GroundedSchemaNode "scm: bc-deduction-formula") ;
    >     (ListLink
    >       (InheritanceLink
     >         (VariableNode "$X") ; <- bound to scope-1
    >         (ConceptNode "D") ;
    >       ) ;
    >       (InheritanceLink
     >         (VariableNode "$X") ; <- bound to scope-1
     >         (VariableNode "$B-6266d6f2") <- bound to scope-1
     >       )
     >       (InheritanceLink
     >         (VariableNode "$B-6266d6f2") <- bound to scope-1
    >         (ConceptNode "D")
    >       )
    >     )
    > )



    > (ExecutionOutputLink
    >     (GroundedSchemaNode "scm: bc-deduction-formula") ;
    >     (ListLink
    >       (InheritanceLink
     >         (VariableNode "$X") ; <- bound to scope-2
    >         (ConceptNode "D") ;
    >       ) ;
    >       (InheritanceLink
     >         (VariableNode "$X") ; <- bound to scope-2
     >         (ConceptNode "A")
     >       )
     >       (InheritanceLink
     >         (ConceptNode "A")
    >         (ConceptNode "D")
    >       )
    >     )
    > )

    You will produce the pattern


    > (ExecutionOutputLink
    >     (GroundedSchemaNode "scm: bc-deduction-formula") ;
    >     (ListLink
    >       (InheritanceLink
     >         (VariableNode "$pattern-var1") ;
    >         (ConceptNode "D") ;
    >       ) ;
    >       (InheritanceLink
     >         (VariableNode "$pattern-var1") ;
     >         (VariableNode "$pattern-var2")
     >       )
     >       (InheritanceLink
     >         (VariableNode "$pattern-var2")
    >         (ConceptNode "D")
    >       )
    >     )
    > )

    The type of $pattern-var1 would be VariableNode (as you suggest
    below), and the type of $pattern-var2 would be Node, cause it's the

least abstract union type of VariableNode (for the original variable (VariableNode "$B-6266d6f2")) and ConceptNode (for (ConceptNode "A")).

    But perhaps you don't need worry about typing pattern variables for
    now, unless you're code already takes care of it.

    See more below.

    On 06/05/2017 12:06 AM, Shujing Ke wrote:

        *Clause 1:*
        (ExecutionOutputLink
             (GroundedSchemaNode "scm: bc-deduction-formula") ;
             (ListLink
               (InheritanceLink
                 (VariableNode "$X") ;
                 (ConceptNode "D") ;
               ) ;
               (InheritanceLink
                 (VariableNode "$X") ;
                 (VariableNode "$B-6266d6f2")
               )
               (InheritanceLink
                 (VariableNode "$B-6266d6f2")
                 (ConceptNode "D")
               )
             )
        )


        *Clause 2:*
        (ExecutionOutputLink
             (GroundedSchemaNode "scm: xxxxx-formula") ;
             (ListLink
               (AAALink
                 (VariableNode "$X") ;
                 (ConceptNode "R") ;
               ) ;
               (BBLink
                 (VariableNode "$X") ;
                 (VariableNode "$Y")
               )
               (CCCLink
                 (VariableNode "$Y")
                 (ConceptNode "R")
               )
             )
        )
        (VariableNode "$X") exist in both clause 1 and 2, but they do
        not really
        have to mean the same thing, so they should not connect.

Again, if they are bound to the same scope then they should mean the

    same thing. That would be the case if both clauses belong to the
    same large scoped tree, and you're trying to find patterns inside
    this tree. Not probable but possible.


        clause 1 and 3 have the  common pattern 1,2 and 3; clause 1 and
        4 have
        the common pattern 3:
        *
        Pattern 1:*
        (ExecutionOutputLink
             (GroundedSchemaNode "scm: bc-deduction-formula")
             (ListLink
               (InheritanceLink
                 (PatternVariableNode "$var1")
                 (ConceptNode "D")
               )
               (InheritanceLink
                 (PatternVariableNode "$var1")
                 (VariableNode "$B-6266d6f2")
               )
               (InheritanceLink
                 (VariableNode "$B-6266d6f2")
                 (ConceptNode "D")
               )
             )
          )


    My suggestion is: only bind pattern variables to the pattern scope

(like SatisfyingSetScopeLink) and let the original variable unbound.

    That way you don't need to introduce a new PatternVariableNode type
    to make the distinction between pattern variables and original
    variables treated as constant. However prefixing the pattern
    variable names by "pattern", as you did further below, is a good
    idea for human readability.


        *Pattern 2:*
        (ExecutionOutputLink
             (GroundedSchemaNode "scm: bc-deduction-formula")
             (ListLink
               (InheritanceLink
                 (PatternVariableNode "$var1")
                 (ConceptNode "D")
               )
               (InheritanceLink
                 (PatternVariableNode "$var1")
                 (PatternVariableNode "$var2")
               )
               (InheritanceLink
                 (PatternVariableNode "$var2")
                 (ConceptNode "D")
               )
             )
          )

        *Pattern 3:*
        (ExecutionOutputLink
             (GroundedSchemaNode "scm: bc-deduction-formula")
             (ListLink
               (InheritanceLink
                 (PatternVariableNode "$var1")
                 (PatternVariableNode "$var3")
               )
               (InheritanceLink
                 (PatternVariableNode "$var1")
                 (PatternVariableNode "$var2")
               )
               (InheritanceLink
                 (PatternVariableNode "$var2")
                 (PatternVariableNode "$var3")
               )
             )
          )


    Pattern 3 is more abstract than pattern 2. Would you not want to
    return the least possible abstract patterns with the greatest

support (or greatest given fitness)? But it's another issue anyway...

        Acutally, I guess the expected pattern here is Pattern 3, but
        the exact
        expected format of it is Pattern 4:
        *Pattern 4:*
        (ExecutionOutputLink
             (GroundedSchemaNode "scm: bc-deduction-formula")
             (ListLink
               (InheritanceLink
                 (VariableNode "$var1")
                 (PatternVariableNode "$pattern_var1")
               )
               (InheritanceLink
                 (VariableNode "$var1")
                 (VariableNode "$var2")
               )
               (InheritanceLink
                 (VariableNode "$var2")
                 (PatternVariableNode "$pattern_var1")
               )
             )
          )


    Again, just have $pattern_var1 scoped to the SatisfyingSetScopeLink
    of the pattern, and let $var1 and $var2 free. Again these patterns,
    with original variables, are gonna be unlikely (in my use cases
    anyway), but they might be meaningful in some situations.


        Which means in the process of pattern miner, I probably should
        do this:
        *1*. Do not consider any VariableNodes  are connected with each
        other
        out of a clause, even they have the same name.


    Again, only assume that variables with different scopes are not
    connected to each others.

        *5*. (optional), if it is necessary, TypedVariableLinks can be
        added to
        specify the original variablenodes:
        (TypedVariableLink
            (VariableNode "$var1")
            (TypeNode "VariableNode")
        )


    Yes, only if var1 is a pattern variable, not if it is an original
    variable, and this type declaration would be inserted in the
    variable declaration of the pattern scope (like

SatisfyingSetScopeLink). If it is an original variable let it as is,

    it's unlikely anyway, so even if it turns out to be problematic we
    can worry about that later.


        Is this process OK?

        One more question:
        Is GroundedSchemaNode also to become variablenode?


    Possibly, as Ben said.

    Nil


        Thanks,
        Shujing

On Thu, Jun 1, 2017 at 11:00 PM, Shujing Ke <shujin...@gmail.com

        <mailto:shujin...@gmail.com>

<mailto:shujin...@gmail.com <mailto:shujin...@gmail.com>>> wrote:

             Ok : )

On Thu, Jun 1, 2017 at 5:17 PM, 'Nil Geisweiller' via opencog <opencog@googlegroups.com <mailto:opencog@googlegroups.com>

        <mailto:opencog@googlegroups.com
        <mailto:opencog@googlegroups.com>>> wrote:

                 On 06/01/2017 04:59 PM, Shujing Ke wrote:

                     Oh, another question: is to mine patterns that
        contains at
                     least one ExecutionOutputLink, or to mine patterns
        that only
                     contains ExecutionOutputLinks and the Links inside
                     ExecutionOutputLinks?


                 I'd say all of them, at any depth. The corpus I gave
        you is not
                 gonna contain any useful pattern anyway, it's just an
        exercise
                 at this point.

                 Nil


                     On Thu, Jun 1, 2017 at 3:52 PM, Shujing Ke
                     <shujin...@gmail.com <mailto:shujin...@gmail.com>
        <mailto:shujin...@gmail.com <mailto:shujin...@gmail.com>>
                     <mailto:shujin...@gmail.com
        <mailto:shujin...@gmail.com> <mailto:shujin...@gmail.com
        <mailto:shujin...@gmail.com>>>>
                     wrote:

                         OK, I will try to mine EOLs first. Thanks : )

                         Shujing

On Thu, Jun 1, 2017 at 7:25 AM, Nil Geisweiller

                         <ngeis...@googlemail.com
        <mailto:ngeis...@googlemail.com>
                     <mailto:ngeis...@googlemail.com
        <mailto:ngeis...@googlemail.com>>
                     <mailto:ngeis...@googlemail.com
        <mailto:ngeis...@googlemail.com>
                     <mailto:ngeis...@googlemail.com
        <mailto:ngeis...@googlemail.com>>>> wrote:

                             Hi,

                             On 06/01/2017 01:32 AM, Shujing Ke wrote:

                                 Hi, Nil and Ben,

I studied the corpus. Is each BindLink one

                     instance of
                                 inference? So


                             Yes.

that each BindLink should be considered as

                     primitve / atomic
                                 -  one pattern should be one BindLink;
        any Links
                     inside a

BindLink should not be mined separatly,

        right?
                     For example,


                             No they can and should be mined separately
        as well.
                     Specifically

what we are interested in are the structures of

                             ExecutionOutputLink (EOL). The third
        argument of an
                     inference
                             BindLink is systematically gonna be an EOL
        wrapping
                     other EOLs,
                             and we are mostly interested in mining
        these EOLs. But
                             ultimately mining the whole BindLink might
        be useful
                     too. We may
                             want to do both, but for starter only mine
        patterns
                     with an EOL
                             as root link.



                                         (InheritanceLink
                                           (VariableNode "$X")
                                           (PatternVariableNode "var1")
                                         )
                                         (InheritanceLink
                                           (VariableNode "$X")
                                           (VariableNode "$B-6266d6f2")
                                         )
                                         (InheritanceLink
                                           (VariableNode "$B-6266d6f2")
                                           (PatternVariableNode "var1")
                                         )

                                 This is a pattern that may be mined by
        patten
                     miner from the

PLN corpus under a general purpose. But

        it is
                     not that kind
                                 of expected patterns as descriped in

http://wiki.opencog.org/w/Pattern_Miner_Prospective_Examples#patterns_in_PLN_inference_histories <http://wiki.opencog.org/w/Pattern_Miner_Prospective_Examples#patterns_in_PLN_inference_histories> <http://wiki.opencog.org/w/Pattern_Miner_Prospective_Examples#patterns_in_PLN_inference_histories <http://wiki.opencog.org/w/Pattern_Miner_Prospective_Examples#patterns_in_PLN_inference_histories>>

<http://wiki.opencog.org/w/Pattern_Miner_Prospective_Examples#patterns_in_PLN_inference_histories <http://wiki.opencog.org/w/Pattern_Miner_Prospective_Examples#patterns_in_PLN_inference_histories> <http://wiki.opencog.org/w/Pattern_Miner_Prospective_Examples#patterns_in_PLN_inference_histories <http://wiki.opencog.org/w/Pattern_Miner_Prospective_Examples#patterns_in_PLN_inference_histories>>>

                                 Actually, the particular goal here is
        not to
                     mine any

connected patterns freely, it is to mine a

                     particular type

of patterns - abstraction of BindLinks

        of the same

structures. If two BindLinks have different

                     structures, even
                                 they share one or several Nodes,
        patterns still
                     should not
                                 be extracted from them. For example,

                                 (BindLink
                                     (LinkTypeA
                                            (NodeType_a "someNode1")
                                            (NodeType_b "someNode2")
                                     )
                                     (LinkTypeB
                                            (NodeType_c "someNode3")
                                            (LinkTypeC

(NodeType_c "someNode3") (NodeType_d "someNode4")

                                             )
                                     )
                                 )


                                 (BindLink
                                     (LinkTypeA
                                            (NodeType_a "someNode1")
                                            (NodeType_e "someNode5)
                                     )
                                     (LinkTypeD
                                            (NodeType_e "someNode5")
                                            (NodeType_f  "someNode6")
                                     )
                                 )

                                 This two BindLinks share the same Node
        (NodeType_a

"someNode1"), a common pattern of (LinkTypeA)

                     can be
                                 extracted for mining general patterns,
        but these two
                                 BindLinks have different structures -
        the first
                     BindLink

contains a LinkTypeA , a LinkTypeB and a

                     LinkTypeC; the

second BindLink contains a LinkTypeA and a

                     LinkTypeD. So
                                 despite the ultimate goal of AGI, to
        learning
                     this type of
                                 patterns more effectively, it's better
        to find
                     all the
                                 BindLinks with same structures, and
        then apply
                     some kind of
                                 induction learning algorithm on them.
        What do
                     you think?


                             No we want to extract patterns across
        BindLinks (or
                     EOLs) that

have different structures, what I believe the

                     pattern miner is
                             good at, right?

                             Nil


                                 But I will still give it a try with
        Pattern Miner.



                                 On Tue, May 23, 2017 at 4:06 PM, Nil
        Geisweiller
                                 <ngeis...@googlemail.com
        <mailto:ngeis...@googlemail.com>
                     <mailto:ngeis...@googlemail.com
        <mailto:ngeis...@googlemail.com>>
                     <mailto:ngeis...@googlemail.com
        <mailto:ngeis...@googlemail.com>
                     <mailto:ngeis...@googlemail.com
        <mailto:ngeis...@googlemail.com>>>
                                 <mailto:ngeis...@googlemail.com
        <mailto:ngeis...@googlemail.com>
                     <mailto:ngeis...@googlemail.com
        <mailto:ngeis...@googlemail.com>>

                                 <mailto:ngeis...@googlemail.com
        <mailto:ngeis...@googlemail.com>
                     <mailto:ngeis...@googlemail.com
        <mailto:ngeis...@googlemail.com>>>>> wrote:

                                      Hi,

                                      I've corrected the inferences
        (note that
                     ExecutionLink
                                 are actually
                                      ExecutionOutputLink because the
        "inference
                     trails" are
                                 actually
                                      inferences to be executed rather
        than records).

Also I've attached a file with ~500

                     inferences obtained
                                 from running
                                      the BackwardChainerUTest, can
        generate many
                     more if needed.

                                      Nil

                                      On 05/21/2017 06:17 PM, Ben
        Goertzel wrote:

                                          Nil,

                                          I wrote down our two sketchy
        examples
                     of patterns
                                 to be mined
                                          from PLN

inference patterns, from our F2F

                     discussion last
                                 week, here:

http://wiki.opencog.org/w/Pattern_Miner_Prospective_Examples#patterns_in_PLN_inference_histories <http://wiki.opencog.org/w/Pattern_Miner_Prospective_Examples#patterns_in_PLN_inference_histories> <http://wiki.opencog.org/w/Pattern_Miner_Prospective_Examples#patterns_in_PLN_inference_histories <http://wiki.opencog.org/w/Pattern_Miner_Prospective_Examples#patterns_in_PLN_inference_histories>>

<http://wiki.opencog.org/w/Pattern_Miner_Prospective_Examples#patterns_in_PLN_inference_histories <http://wiki.opencog.org/w/Pattern_Miner_Prospective_Examples#patterns_in_PLN_inference_histories> <http://wiki.opencog.org/w/Pattern_Miner_Prospective_Examples#patterns_in_PLN_inference_histories <http://wiki.opencog.org/w/Pattern_Miner_Prospective_Examples#patterns_in_PLN_inference_histories>>>

<http://wiki.opencog.org/w/Pattern_Miner_Prospective_Examples#patterns_in_PLN_inference_histories <http://wiki.opencog.org/w/Pattern_Miner_Prospective_Examples#patterns_in_PLN_inference_histories> <http://wiki.opencog.org/w/Pattern_Miner_Prospective_Examples#patterns_in_PLN_inference_histories <http://wiki.opencog.org/w/Pattern_Miner_Prospective_Examples#patterns_in_PLN_inference_histories>>

<http://wiki.opencog.org/w/Pattern_Miner_Prospective_Examples#patterns_in_PLN_inference_histories <http://wiki.opencog.org/w/Pattern_Miner_Prospective_Examples#patterns_in_PLN_inference_histories> <http://wiki.opencog.org/w/Pattern_Miner_Prospective_Examples#patterns_in_PLN_inference_histories <http://wiki.opencog.org/w/Pattern_Miner_Prospective_Examples#patterns_in_PLN_inference_histories>>>>

                                          It will be good if you can
        write these
                     out in the
                                 fully explicit
                                          Atomese format that PLN
        actually uses
                     to save its
                                 inference
                                          histories...

                                          thx!
                                          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+unsubscr...@googlegroups.com
        <mailto:opencog%2bunsubscr...@googlegroups.com>
                 <mailto:opencog%2bunsubscr...@googlegroups.com
        <mailto:opencog%252bunsubscr...@googlegroups.com>>.
                 To post to this group, send email to
        opencog@googlegroups.com <mailto:opencog@googlegroups.com>
                 <mailto:opencog@googlegroups.com
        <mailto:opencog@googlegroups.com>>.
                 Visit this group at
        https://groups.google.com/group/opencog
        <https://groups.google.com/group/opencog>
                 <https://groups.google.com/group/opencog
        <https://groups.google.com/group/opencog>>.
                 To view this discussion on the web visit

https://groups.google.com/d/msgid/opencog/babb8f59-9817-f9f3-218b-2975cca792d3%40gmail.com <https://groups.google.com/d/msgid/opencog/babb8f59-9817-f9f3-218b-2975cca792d3%40gmail.com> <https://groups.google.com/d/msgid/opencog/babb8f59-9817-f9f3-218b-2975cca792d3%40gmail.com <https://groups.google.com/d/msgid/opencog/babb8f59-9817-f9f3-218b-2975cca792d3%40gmail.com>>.

                 For more options, visit
        https://groups.google.com/d/optout
        <https://groups.google.com/d/optout>
                 <https://groups.google.com/d/optout
        <https://groups.google.com/d/optout>>.

--
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+unsubscr...@googlegroups.com.
To post to this group, send email to opencog@googlegroups.com.
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/429068b3-05dd-c183-b019-c82bf271c394%40gmail.com.
For more options, visit https://groups.google.com/d/optout.