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 <[email protected]
<mailto:[email protected]>> wrote:
Ok : )
On Thu, Jun 1, 2017 at 5:17 PM, 'Nil Geisweiller' via opencog
<[email protected] <mailto:[email protected]>> 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
<[email protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>>
wrote:
OK, I will try to mine EOLs first. Thanks : )
Shujing
On Thu, Jun 1, 2017 at 7:25 AM, Nil Geisweiller
<[email protected]
<mailto:[email protected]>
<mailto:[email protected]
<mailto:[email protected]>>> 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>>
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
<[email protected]
<mailto:[email protected]>
<mailto:[email protected]
<mailto:[email protected]>>
<mailto:[email protected]
<mailto:[email protected]>
<mailto:[email protected]
<mailto:[email protected]>>>> 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>>>
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 [email protected]
<mailto:opencog%[email protected]>.
To post to this group, send email to [email protected]
<mailto:[email protected]>.
Visit this group at 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>.
For more options, visit 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 [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/6c8ec5b1-c0d7-823c-8c6d-5b4bbd314c17%40gmail.com.
For more options, visit https://groups.google.com/d/optout.
