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