Re: [UCR] RIF needs different reasoning methods

François,

I am trying to follow your requirements, and I want to understand whether I 
have it right.

you wrote:

>>What is the nature of that support? I mean, pragmatically speaking,
>>what needs to be done to enable such support?
> 
> To make it possible to distinguish between different fragment of RIF:
> 
> 1. declatratibe RIF rules, themselvbes distinguished into 1.1 deduction
> rules and 1.2 normative rules
> 2. reactive rules

That is, you want 3 kinds of RIF rules:

a) "deduction rules", generally having the semantics
    FROM <antecedent> CONCLUDE <consequent assertion>
where the <consequent assertion> is to be recorded in the KB for future use.

b) "normative rules", generally having the semantics
    WHEN <antecedent> REQUIRE <consequent assertion>
where the <consequent assertion> must (at the point of this evaluation) 
already be recorded in the KB; otherwise the KB is inconsistent.  An 
alternative semantics is that the <consequent assertion> must be free of 
direct contradiction in the KB.  In either case, this may be interpreted to 
require backward chaining.  But it might also be implemented by explicitly 
concluding <consequent assertion> and testing for consistency.

c) "reactive rules", generally having the semantics
    WHEN <antecedent> PERFORM <action>
where the relationship between the <action> and the KB is either none, or not 
considered to be significant to the evaluation of the ruleset, or ?

 From your example, I also understand that in some cases, (c) may be a 
substitute for (b), whence the term "enforcement rule".  That is, if the 
would-be normative rule is:
   WHEN B1 REQUIRE B2
the "enforcement rule" might be phrased:
   WHEN B1 AND B2-contradiction PERFORM <remedial-action>.
So there may be a subclass of "reactive rule" that is explicitly "remedial 
rules" or "enforcement rules" or "compensatory rules" that have a known 
relationship to the related KB elements.

(I am deliberately using datalog notions here, because I am at a loss to 
understand these categories more generally.  But I think you may have some 
more general interpretations in mind.)

If I understand you correctly, the syntax of these three kinds of rules may be 
very similar, but they must be distinguishable.  Further, do I understand that 
you intend to permit the receiving engine to interpret one of these rules with 
one of the other semantics, where that re-interpretation is consistent with 
its own reasoning algorithms?

I do agree that one might exchange the (b) form and allow some interpretation 
of the (c) kind.  The issue, of course, is whether the semantics permit or 
prohibit the creation of an "inconsistent" KB.  It seems also that it would be 
reasonable to interpret (b) as (a) or (a) as (b), where that interpretation is 
consistent with the rest of the reasoning algorithm, so long as it doesn't 
wreck the expected use of the RIF interchange.

It strikes me that we may get very close to implementation issues in defining 
the semantics of rulesets (as the interchange between Bijan and François 
suggests) or we may get perilously close to distinguishing the purpose of the 
exchange.

(BTW, it seems to me that in a distributed rules evaluation scenario, the idea 
of an overall-inconsistent KB has to be supported.  What agent A "knows" may 
not be 100% consistent with what agent B "knows".  So each KB can be locally 
consistent, while the overall KB is not.  In fact, I'm reasonably sure this 
sort of thing plagues the intelligence community.)

Your scenario includes all of these notions.  I just want to be sure I am 
taking home the intended lesson.

Thanks,
-Ed

-- 
Edward J. Barkmeyer                        Email: edbark@nist.gov
National Institute of Standards & Technology
Manufacturing Systems Integration Division
100 Bureau Drive, Stop 8263                Tel: +1 301-975-3528
Gaithersburg, MD 20899-8263                FAX: +1 301-975-4482

"The opinions expressed above do not reflect consensus of NIST,
  and have not been reviewed by any Government authority."

Received on Monday, 6 March 2006 20:19:43 UTC