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

Re: [UCR] RIF needs different reasoning methods

From: Bijan Parsia <bparsia@isr.umd.edu>
Date: Wed, 8 Mar 2006 08:52:46 -0500
Message-Id: <25505f9db26e6d695f57a9d23e19d93e@isr.umd.edu>
Cc: public-rif-wg@w3.org
To: Francois Bry <bry@ifi.lmu.de>

Francois,

On Mar 8, 2006, at 5:09 AM, Francois Bry wrote:

> Dear All,
>
> In a former email, I argued that in my opinion the RIF  should make it
> possible (1) to distinguish between different kinds of rules 
> ("deduction
> rules", "normative rules" and "reactive rulers")

Part of my confusion is that, in that email, it seemed as if these 
rules were all semantically equivalent...i.e., that the ONLY 
distinguishing factor was the proof theory employed (and that all the 
proof theories were supposed to be sound and complete for those 
semantics).

> and (2) to specify
> different kinds of rule processing methods-- while having a single
> delcarative semantics.
[snip]

If the only motivation (from observable behavior) is performance 
(another thing I gleaned from your email), then why *is* it important 
to specify the *method* rather than just specify an engine 
known-to-be-fast-for-my-ruleset?

One possibility I thought of is that, e.g., in several systems (JESS 
and Jena, for example), you can indicate that some rules are to be 
evaluated using the backward chainer, rather than a forward chainer. 
Presumably, if one is sticking to the declarative bit, it makes no 
difference to the semantics, but can have a dramatic effect on 
performance. Such performance hints seem like a reasonable thing to 
preserve, though I would rather not constrain implementors who think 
they can do better without the hints (i.e., those writing nice, 
sophisticated optimizers)!

> The reasons for this view are that today's pratice, especially the rule
> processors used in databases and business rules, require such
> distinctions (between kinds of rules) and specificiations (of rule
> processing methods). A RIF not having these distinctions (between kinds
> of rules) and specificiations (of rule processing methods) would be 
> more
> difficult to deploy and therefore have less chances to be accepted by
> practioners.

Now this is a totally different reason, afaict. In fact, it almost 
sounds like a *marketing* (or pragmatics) point. (By which I don't mean 
to denigrate it, it could be a reasonable point.) By which I mean, if 
you aren't going to allow observable behavioral differences (i.e., the 
*semantics* of all these kind of rules is the same and proof theories 
are required to conform to those semantics), then I don't think these 
distinctions are substantive and probably don't need to be indicated 
*in the exchange*. If they *are* subtantive, then I need a example 
where the rules 1) have the same (declarative?) semantics, 2) have an 
behavioral difference depending on whether they are marked as one kind 
of rule rather than another, and 3) have a *further* behavioral 
difference (other than performance) based on the specified (sound and 
complete) proof theory. It's not *hard* to meet the 2 and 3 criteria, 
but *then* I would expect some difference in the semantics of the rules 
(by which I mean a complete specification of the semantics; it occurs 
to me that perhaps you are marking out some distinction between 
"declarative" and "procedural" semantics, and not requiring the latter 
to be equivalent to the former...which is *fine*, by not how I read 
what you've said; hence my puzzlement!)

Cheers,
Bijan.
Received on Wednesday, 8 March 2006 13:52:54 GMT

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