Rule Engine Help

[Jenson Joseph <je...@gmail.com>]

Hi,

I'm using a General Rule Reasoner with forward rules and forwardRETE
engine. I am wondering if there is a way to invalidate/rollback the triples
of a rule that uses the 'noValue' builtin when a triple is
introduced invalidating it. It appears to do this for regular rule items,
eg. if an object is no longer an rdf:type a rule requiring it could be
rolled back.

The question is does the same happen for noValue rule items.Currently my
method around this is to look for invalid instances and use the 'remove'
builtin to remove and roll them back but that needs to be done exhaustively
for each 'noValue' instance. If there were a better solution for that that
would be preferable.

Thanks

Re: Rule Engine Help

[Dave Reynolds <da...@gmail.com>]

Hi,

No, there's no better solution I'm afraid.

For clean "monotonic" rules the rule engine should deal changes in the 
data automatically.

However, the noValue builtin is intrinsically non-monotonic and depends 
entirely on the state of the database at the exact time it fires and 
there's no support for rolling back such non-monotonic rules. In 
retrospect it would have been better to develop a separate rule engine 
for these sort of state-dependent rules rather than bolt them on top of 
an engine not designed for them. But that's water under the bridge.

Dave

On 03/12/2020 17:34, Jenson Joseph wrote:
> Hi,
> 
> I'm using a General Rule Reasoner with forward rules and forwardRETE
> engine. I am wondering if there is a way to invalidate/rollback the triples
> of a rule that uses the 'noValue' builtin when a triple is
> introduced invalidating it. It appears to do this for regular rule items,
> eg. if an object is no longer an rdf:type a rule requiring it could be
> rolled back.
> 
> The question is does the same happen for noValue rule items.Currently my
> method around this is to look for invalid instances and use the 'remove'
> builtin to remove and roll them back but that needs to be done exhaustively
> for each 'noValue' instance. If there were a better solution for that that
> would be preferable.
> 
> Thanks
>