Hi Nil and Ben,
The Variablenodes of the same name in different clauses in a PLN corpus do
not really have to mean the same thing, therefore even they are of the same
name, still should not be considered as connected. And vice versa ,
different variable node names in different clauses could still mean the
same thing. For example:
*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")
)
)
)
*Clause 3:*
(ExecutionOutputLink
(GroundedSchemaNode "scm: bc-deduction-formula") ;
(ListLink
(InheritanceLink
(VariableNode "$W") ;
(ConceptNode "D") ;
) ;
(InheritanceLink
(VariableNode "$Z") ;
(VariableNode "$B-FFFF")
)
(InheritanceLink
(VariableNode "$B-FFFF")
(ConceptNode "D")
)
)
)
*Clause 4:*
(ExecutionOutputLink
(GroundedSchemaNode "scm: bc-deduction-formula") ;
(ListLink
(InheritanceLink
(VariableNode "$M") ;
(ConceptNode "P") ;
) ;
(InheritanceLink
(VariableNode "$N") ;
(VariableNode "$B-FFFF")
)
(InheritanceLink
(VariableNode "$B-FFFF")
(ConceptNode "P")
)
)
)
(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.
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")
)
)
)
*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")
)
)
)
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")
)
)
)
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.
*2*. The original variablenodes in a clause should not be abstracted as
normal PatternVariableNode, but they have to be turned into unique name for
middle process, because there could be even more confusing sistuation like
clause 5 and clause 1, where the (VariableNode "$B-6266d6f2") and
(VariableNode "$X") are just swopped, but they are acutally the same
clause, this will be too confusing.
*Clause 5:*
(ExecutionOutputLink
(GroundedSchemaNode "scm: bc-deduction-formula")
(ListLink
(InheritanceLink
(VariableNode "$B-6266d6f2")
(ConceptNode "D")
)
(InheritanceLink
(VariableNode "$B-6266d6f2") ;
(VariableNode "$X") ;
)
(InheritanceLink
(VariableNode "$X")
(ConceptNode "D")
)
)
)
*3*. After turn each original variablenode into uniqu variablenode, extract
patterns in the format of Pattern 3, and then turn all the orignal
variablenode back from PatternVariableNode backs to variablenodes, and then
unify the variable names in the order of their appearance, so as to get
pattern 4.
*4*. (optional), if it is necessary, the output format can also be turned
into Pattern 5, denpends on if need to distinguish the variablenodes that
reprent the orignal variablenodes or not.
*Pattern 5:*
(ExecutionOutputLink
(GroundedSchemaNode "scm: bc-deduction-formula")
(ListLink
(InheritanceLink
(VariableNode "$var1")
(VariableNode "$var3")
)
(InheritanceLink
(VariableNode "$var1")
(VariableNode "$var2")
)
(InheritanceLink
(VariableNode "$var2")
(VariableNode "$var3")
)
)
)
*5*. (optional), if it is necessary, TypedVariableLinks can be added to
specify the original variablenodes:
(TypedVariableLink
(VariableNode "$var1")
(TypeNode "VariableNode")
)
Is this process OK?
One more question:
Is GroundedSchemaNode also to become variablenode? or doesn't make much
sense to consider it as variablenode?
Thanks,
Shujing
On Thu, Jun 1, 2017 at 11:00 PM, Shujing Ke <[email protected]> wrote:
> Ok : )
>
> On Thu, Jun 1, 2017 at 5:17 PM, 'Nil Geisweiller' via opencog <
> [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]>> 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]>> 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_Example
>>> s#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]>>> 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_Example
>>> s#patterns_in_PLN_inference_histories>
>>> <http://wiki.opencog.org/w/Pat
>>> tern_Miner_Prospective_Examples#patterns_in_PLN_inference_histories
>>> <http://wiki.opencog.org/w/Pattern_Miner_Prospective_Example
>>> s#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].
>> 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/ms
>> gid/opencog/babb8f59-9817-f9f3-218b-2975cca792d3%40gmail.com.
>> For more options, visit 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/CALpD4-Jg0iFDd8-%3Dhxx%2BPmpAosDN1GPknuQ9QnzY5PLPYGM_Eg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
