On Mon, Jan 9, 2017, at 05:31 PM, Dave Reynolds wrote:
>
> Great that this works for you but the design centre for Jena Rules was
> deductive closure not event-condition-action (ECA) or reactive rules.
One of the things I think about is why production rules haven't
had a bigger impact in the industry and one of the big problems is
a lack of unity. Some of that is as simple as there is no "C
language" for rules, but part of the reason it is is that people
are not thinking from the viewpoint that I might want to apply (at
least some of) the same rules to deductive closure, ECA, SMT
solving, backwards chaining reasoning, and other modes of
execution. I see a need to separate "rules" from "schemes" that
define how the rules are applied.
Associated with that some issues I have are:
* the structure of "common sense knowledge" is "this is true unless..."
and there are many ways to implement this in various inference engines
that aren't compatible. Most of them involve manipulation of the order
in which rules fire in time. Like the many ways to map relational
structures to objects with Java-style inheritence, none of them are
entirely satisfying.
* a "road less traveled" is the subdivision of the knowledge base into
subsets (like the named graphs in RDF) which can also be used to control
the sequence of events (and implement overriding, the "deletion" of
facts by not copying them to a target graph, and other fun things.) In
the case of Jena Rules this would look like an expansion of the matching
patterns to quads which I can't imagine would be that difficult
>
> If one wanted primarily ECA type rules for event processing then you
> would look at the various Complex Event Processing designs and see what
> it would take to build one. Commercially there's lots (Oracle, SAP,
> Tibco et al all have one) not sure what there is that's open source
> other than Drools Fusion and I'm not sure how that relates to the rest
> of Drools.
Drools Fusion is a collection of features that are part of Drools
Expert. Part of that is support for the Allen Algebra, and part of it
is support for "garbage collecting" events once they can no longer cause
rules to fire, and the rest of it is the underlying rule engine's
support for truth maintainance, negation, etc.
> Or if one wanted something more like normal forward inference rules but
> with more control over the non-monotonic aspects of handling retractions
> then that would take you towards a full production rules engine and thus
> drools. I suspect it would make more sense to just build a jena/drools
> bridge than reinvent that wheel. There's a *lot* of years of engineering
> in the drools RETE+++ implementation.
It's an interesting idea.
The manual for the Jena Rules Engine complains about error handling for
Jena Rules but the situation with error handling in Drools is much
worse. Inspired by Inform7 I started writing a "Colossal Cave" sort of
game in Drools and did not get that far because (i) it took me far too
long to figure out why I was getting syntax errors, and (ii) no way I
could expect a junior programmer, never mind a subject matter expert,
to do the same.
In comparison I don't find it painful at all to deal with syntax errors
in Jena Rules, I might have to look at the Java source code sometimes,
but that is not like understanding what goes wrong between Drools and
ECJ.
It seems like it ought to be possible though to put jena objects
directly into Drools and write some kind of code generator that turns
java rules + annotations into Drools rules.
