Re: [UCR] RIF needs different reasoning methods

François,

I wrote:

>>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.

you wrote:

> Basically yes. But "to be recorded in the KB for future use" is not the
> only way to proceed. This is called "materialization". This is only one
> of the possible approaches. Another one is to re-evaluate the rules by
> need. THis second approach might be preferable in two cases: when
> re-evaluating is more efficient than storing and when some data (e.g.
> facts or A-boxes) the deduction rule refer are updated.

I agree that materialization is an implementation strategy.
You are correct that there are multiple semantically equivalent strategies, 
assuming that the ruleset attaches no semantic significance to explicit 
ordering (and related "meta-rules" ideas).  I really meant to contrast 
"directed inferencing" ("deduction rules") with "directed consistency testing" 
("normative rules").

>>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; 
> 
> again, replace "recorded in the KB" by "implied by the KB" and this is
> fine with me.

Yes.  This would seem to represent a test that some other inference rules have 
also been satisfied, but in most cases, it represents a test that the 
corresponding assertions are present or absent.  (Materialization may make 
assertion and inference indistinguishable.)

It should also be noted that you only need normative rules if you have 
constraints on the syntax that prevents the contrapositive from being stated 
as a "deductive rule".  E.g.
   WHEN p(x) REQUIRE q(x)
is
   IF NOT q(x) CONCLUDE NOT p(x)
but "NOT q(x)" may be an invalid antecedent or "NOT p(x)" may be an invalid 
consequent.

Alternatively, you need normative rules only if that is the only notion of 
"consistency" the Rules engine enforces.  (This is a property derived from 
their database origins.)

>>c) "reactive rules", ...
>
> Not really so. The reactive rule should consider instances, so as to
> reduce the evaluation costs. If a normative rule says
>   all x p(x) => q(x) or r(x)
> and r(y) is removed, then the reactive rule to be evaluated is:
> ON remove r(y) CHECK (p(y) => q(y))
> Note that y is bound by the event "remove r(y)".

Thank you for this clarification.  I completely misunderstood "reactive rules".

It seems to me that identifying "all x p(x) => q(x) or r(x)" as a "normative 
rule", however, is sufficient.  I would expect the semantics of "normative 
rule" to imply that an engine should reevaluate the rule whenever an inference 
asserts a new p(x) or contradicts a q(x) or r(x).  So why would I need
  "ON remove r(y) CHECK (p(y) => q(y))"?
This seems to be a direction for some specific implementation strategy.
(Technically, "remove r(y)" does not "contradict" r(y), unless r has NAF 
semantics.  But it clearly requires the proof of "q(y) or r(y)" to be 
redeveloped.)

Further, I am concerned about the semantics of "remove".
I assume that we are here considering remove to be a well-defined "action" on 
the KB, as distinct from an "Event" that would take us into the land of 
Event-Condition-Action rules.  And even so, the "remove" action requires RIF 
semantics to include explicit non-monotonic behaviors (as distinct from purely 
implicit non-monotonic behavior associated with "time of evaluation").  Does 
some Use Case make "remove" a clear requirement?

Otherwise, this is a pure implementation strategy for managing "change" in the 
KB.  And it is very dependent on a notion of "postulates" -- assertions that 
CANNOT be deduced -- and on having a concept of "difference in state" and on 
other elements of the implementation strategy (materialization, ordering, 
etc.).  I agree that this is what production rule engines do, but I would 
worry about standardizing much of this.

>>If I understand you correctly, the syntax of these three kinds of
>>rules may be very similar,
> 
> yes. Especially the "condition" or "rule antecedent" parts.
> 
>>but they must be distinguishable.
> 
> Some other parts, especially "events" like "remove r(y)" are specific to
> reactive rules.

OK.  But what I meant was that I cannot determine whether
  IF <antecedent> THEN <consequent>
is a "deductive rule" or a "normative rule" from such a syntax, when the 
consequent is an "assertion".  To distinguish them, I would need two keywords, 
e.g. THEN and CHECK.

>>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?
> 
> No. I was not referring to different semantics. I was speaking of
> different reasoners - for the same semantics.

OK, good.  This is a distinction in rule semantics.  (And I agree.  The 
allowable models will be different.)

>>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.
> 
> Pragmatics suggests that it should permit - marking it as
> "inconsistent". As in DBs.

I agree, but the concept of "inconsistent" now means two things:
- there is an explicit or implied contradiction: p(x) AND NOT p(x), or
- some normative rule has been violated.
I think these are only equivalent if the semantics of the normative rule is 
the contrapositive, or you have NAF semantics for the relevant predicates.
In DBs, the only notion of "consistent" is that the normative rules are 
satisfied.

>>(BTW, it seems to me that in a distributed rules evaluation scenario,
>>the idea of an overall-inconsistent KB has to be supported.  
> 
> I agree!

I think the "rules" world expects this, and deals with the ideas of "repair" 
and "remediation" (although I do *not* suggest these for RIF), whereas for 
"distributed ontologies", much care must be taken to avoid it.

>>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.
> 
> Maybe. If we don't, my thesis is that RIF will remain an interesting
> academic exercise - something I can live with. But could the WG live
> with it?

And if we do, will Dr. FrankenRIF be able to live with his monster?

Regards,
-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 Tuesday, 7 March 2006 20:14:05 UTC