W3C home > Mailing lists > Public > public-rif-wg@w3.org > March 2006

Re: [UCR] RIF needs different reasoning methods

From: Francois Bry <bry@ifi.lmu.de>
Date: Tue, 07 Mar 2006 08:52:54 +0100
Message-ID: <440D3BD6.40007@ifi.lmu.de>
To: edbark@nist.gov
CC: public-rif-wg@w3.org

Ed Barkmeyer wrote:
> 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.
Basically yes. But "to be recporded in the KB for future use" is not the
only way to proceed. This is called "matrialization". This is only one
of the possible apporachres. Another one is to re-evaluate the rules by
need. THis second approach might be preferable in two cases: when
re-evaluating is more efficvient than storing and when some data (e.g.
facts or A-boxes) the deduction rule refer are updated.
> 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; 
agin, replace "recorded in the KB" by "implied by the KB" and this is
fine with me.
> 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".
Substitute might be misdleading. I would rather speak of implementation.
> 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>.
Not really so. The reactive rule should consider instances, so as to
reduce the evaluation costs. Id 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)".
> 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 would not suggest that RIF specifieds this. My point is that I would
reocmmend that RIF makes it possible to express such remedial rules, as
you call them.
> 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.
> 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.
> 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 suggestsa that it shoulld permit - markin g it as
"inconsistent". As in DBs.
> 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 exervcise - something I can live with. But could the WG live
with it?
> (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!
> Your scenario includes all of these notions.  I just want to be sure I
> am taking home the intended lesson.
>
It seems to me that very well got the popints I wanted to make. It is
pleasure to read your comments!

Regards,

François
Received on Tuesday, 7 March 2006 07:53:00 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:33:27 GMT