!! warning: long and probably boring !!
Just wanted to commit some thoughts to archives before
I forget this.
Haven't seen this in print anywhere, but I'm not claiming
it's necessarily new. Just an epiphany on my part.
========================================
Normal RETE:
Most things are using a Lisp/cambridge-prefix notation to
specify both facts and patterns.
A pattern basically represents some flavor of relationship
between two of the operands. A symbol followed by a '?'
simple represents a place-holder, to be matched against
facts.
patterns:
;; The parent of x? is y?
(parent-of c? p?)
;; a? is equivelent to b?
(eq x? y?)
;; The name of p? is n?
(name p? n?)
Facts are simply patterns with some/all placeholders
filled. They are presented to the system in lisp
notation, as are the patterns. So, it becomes a
fairly easy way to match a fact to a pattern.
pattern: (parent-of c? p?)
facts:
(parent-of bob bill)
(parent-of bob ann)
(parent-of billy bill)
(parent-of billy ann)
pattern: (name p? n?)
facts:
(name bob robert)
(name bill william)
(name billy william)
(name anne ann)
A rule is specified by a series of patterns, where all
placeholders that share a name must be the same variable
for all occurrences of that placeholder, across all patterns.
rule:
;; Match any child who has the same name
;; as his/her parent.
(parent-of child? parent?)
(name child? childs-name?)
(name parent? parents-name?)
(eq parents-name? childs-name?)
This effectively becomes a relational JOIN, where each
type of pattern is a table and each placeholder is a
column in that table.
None of this is New Material. It just took me a while
to visualize it.
Anyhow, RETE adds the concept of a piece-wise, step-based
JOIN architecture using a directed acyclic graph.
========================================
RETE Object Oriented (aka ROO):
We live in an OO world, us Java programmers. Converting
objects into Lisp facts is kinda odd. Specifying all
relationships between objects and their data as Lisp
patterns is likewise odd.
This is because each public method of a class is effectively
a fact/pattern.
(parent-of person? parent?)
Person?.getParent() // == parent?
(name person? name?)
Person?.getName() // == name?
(eq a? b?)
a?.equals( b? )
Thus, we see, that 'this' is effectively one of our columns in all of
the tables, as it's the 'root' of the relation. Each method can
result in a new table of relations, which typically is just 2
columns, first being the 'this' column, which contains the
object itself, and the 2nd being the return value of the method.
There's the special case of the 2nd column being a constant literal,
which can be optimized for in the pattern matching.
Person?.getName() = "Bob"
Since we're not bound to lisp, a natural-language pattern language
can be used.
The above rule to select anyone who has the same name as their
parent can be specified in fewer than 4 obvious patterns.
;; (parent-of individual? parent?)
Individual(Person)? Parent is Parent(Person)?
;; (name individual? ind-name?)
;; (name parent? parent-name?)
;; (eq ind-name? parent-name?)
Individual(Person)? Name is Parent(Person)? Name
By providing various verb clauses, such as
is
is not
is greater than, etc
includes
does not include
We're effectively introducing implicit patterns, made up of
predefined functions:
(eq lhs? rhs?)
(not-eq lhs? rhs?)
(gt lhs? rhs?)
(includes lhs? rhs?)
(not-includes lhs? rhs?)
========================================
Anyhow, it's mostly the revelation regarding the fact that
the object itself represents a column in the method-derived
pattern table.
Signing off...
-bob
_______________________________________________
drools-interest mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/drools-interest
