On 10/01/17 19:31, Paul Houle wrote:
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.
This is possibly getting off topic for jena-dev but can't resist
pointing out the RIF-CORE is a subset of both RIF-BLD (i.e. backward) or
RIF-PRD (i.e. forward production) and so is executable by either sort of
engine.
Indeed monotonic non-hybrid JenaRules can be run by either the forward
or backward engine.
The cost of this is that the shared subset is small and "pure" so
doesn't support all the negation and non-monotonic actions you might want.
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.
The frame problem has been a known hard problem for quite a few decades
:) Though I do seem to remember that at around the time RIF was
finishing a Darpa funded consortium developed a rather sophisticated
rule system that had a really good model of default knowledge. Can't
recall the details and haven't tracked its progress.
* 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
In principle a quad version of the jena forward engine would indeed be
doable. Though the jena forward engine is a primitive beast and there's
design choices in there I would not make again.
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.
Interesting, especially given how primitive the syntax and error
handling for Jena rules is.
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.
Yes, should be possible and would allow people to use Drools as an
engine for Jena rules and to experiment with extensions that made use of
the richer drools language.
None of this is anything I personally have time to look at but seems
tractable.
Dave
