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/2298f94e-1747-350c-b6ba-9a881c8c608d%40gmail.com.
For more options, visit https://groups.google.com/d/optout.