Hi,
On 03/09/18 13:05, Nouwt, B. (Barry) wrote:
Hi all,
We are using Apache Jena's GenericRuleReasoner in our project with backward chaining to selectively apply rules relevant to answer a particular SPARQL question. We learned that backward chaining in Jena's GenericRuleReasoner currently only supports single headed backward rules. However, we are facing quite some limitations due to this single-headedness and would like to know whether there have been or are attempts to overcome this limitation.
No, there have been no such attempts to my knowledge. Single headed
rules are the norm. The forward engine provides multi headed as a
convenience because that's slightly more efficient in the forward case
than having N single-headed rules but in the backward case there would
be no such saving.
Currently we split N-headed forward rules to N single-headed backward rules,
but this limits the amount of bound variables (from the initial SPARQL query)
available in a single rule's body. This is an important requirement in our use
case.
This is the way I would do it. I don't understand what you mean by the
limitation. If you are replicating the rules bodies then each body has
all the variables.
So, could someone with knowledge about the internals of the backward chaining
process in the GenericRuleReasoner shed some light on whether it would (in
principle) be possible to support multi-headed backward rules in Apache Jena's
GenericRuleReasoner. We are even considering/investigating whether we can
implement this feature ourselves.
If someone wanted to do this I would advise them to do it by a syntactic
transformation of the sources rules in the way you are already doing,
not by messing with the engine.
If you *really* wanted engine support then I guess one way to do this
would be to allow goals which can bind more values than are available in
a triple. So you could have things like (pseudo rule code only):
head1(A) <- intermediate(A,B,C...X,Y,Z)
head2(X,Y) <- intermediate(A,B,C...X,Y,Z)
head3(Z) <- intermediate(A,B,C...X,Y,Z)
intermediate(A,B,C...X,Y,Z) <- ... body clauses ...
Extending the backward rule engine to allow for general tuple goals and
terms (but hide non-triple terms from the jena interface) is probably
possible but a pretty substantial amount of work.
Syntactically it might be possible to use the "Functor"
hack^h^h^h^hmachinery supported in the rule engines. But adding
match/unification over functors would probably end up being as much work
as generalizing the engine to non-triples.
Probably easier to find an alternative general purpose backward rule
engine and wire it up to jena.
Dave
