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 <
shuj...@gmail.com
> <mailto:
shuj...@gmail.com>> wrote:
>
> Ok : )
>
> On Thu, Jun 1, 2017 at 5:17 PM, 'Nil Geisweiller' via opencog
> <
ope...@googlegroups.com <mailto:
ope...@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
> <
shuj...@gmail.com <mailto:
shuj...@gmail.com>
> <mailto:
shuj...@gmail.com <mailto:
shuj...@gmail.com>>>
> it, send an email to
opencog+u...@googlegroups.com
> <mailto:
opencog%2Bunsu...@googlegroups.com>.
> <mailto:
ope...@googlegroups.com>.
> <
https://groups.google.com/group/opencog>.
> <
https://groups.google.com/d/msgid/opencog/babb8f59-9817-f9f3-218b-2975cca792d3%40gmail.com>.
> <
https://groups.google.com/d/optout>.
>
>
>