Re: [UCR] RIF needs different reasoning methods

On Mar 6, 2006, at 11:02 AM, Francois Bry wrote:

> Dear Bijan,
>> It's declaring their expressive profile? I mean, is it (anything like)
>> the OWL species? Or the KIF conformance profiles?
>>     <http://logic.stanford.edu/kif/dpans.html#12.3>
> They don't.

Er...sorry, this doesn't scan for me. Do you mean that what you want is 
not like these? How so?

>> Well, if they give the same answers....isn't everything else just an
>> implementation detail?
> Well, one might call 'implementation detail' everything that goes 
> beyond
> theoretical considerations.

Well, if you are primarily concerned with correctness, I guess so. But 
let's say you are concerned with responsiveness...why would you bother 
to specify which proof procedure was in place instead of a 
responsiveness parameter. Why do you *care* if the system in question 
is using "constructive reasoning" if it is correct and meets your 
performance needs? Contrariwise, it's not clear that just knowing that 
a system uses "constructive reasoning" will meet the performance needs. 
Bad implementation, implementations tuned for other things, and so on 
can make an enormous difference to actual performance.

Again, I think there is worth in having an expressiveness lattice which 
is informed both by theoretical considerations (including the worst 
case complexity of sound and complete or otherwise proof procedures), 
field experience (e.g., certain features are popular), and current 
implementation considerations. I'm just unclear why it makes sense, in 
general, absent procedural issues, to specify in one's exchange format, 
the specific proof procedure used (unless, the proof procedure is 
either not sound or incomplete and the results of that particular 
procedure is regarded as canonical; and are we really going there?) Why 
is it helpful in the *exchange*? How does it help the exchange? I don't 
get the scenarios where just the expressiveness will *go wrong*.

(I can see having comments, "we've tested this set on Jess versions 
blah and blah, and KAON, and RDF Gateway, and whatever and it runs like 
a pig on all of them except X. The next version of Jess, we're told, 
should handle this with acceptable performance". But what do we need to 
do to support that? Nothing I think.)

>  In my opinion, the capability to specify
> different kinds of rules

Is there disagreement here?

> and/or different kind of reasoning is essential

Well, isn't the question of how to specify this and what exactly to 
specify just the issue?

> for the RIF to be well received in practice.
>
>> This doesn't mean it's not worth identifying important fragments and
>> profiles (though that can be quite the painful game...hard to get 
>> right).
> It is not hard if one considers what business rules in practice are.

Well, since I'm still not getting it, it's not ALL that easy either :)

For example:

"""Reactive rules like the following are generated that ensure an
efficient, event-driven enforcement of the above declarative rule:""""

This just seems to be implementation. If I can be efficient enough for 
your needs, why would you care if I'm "event-driven" in my enforcement?

(I mean, what is this enforcement other than the update of a view? If 
not, how can they be generated from the declarative rule?)

Now, perhaps there are other semantic issues with reactive rules....ah 
yes, negation is non-mon....but does that mean that they only 
approximate the "declarative" rule, or should it be non-mon as well? Or 
perhaps you want to be able to specify it under difference semantics on 
different occasions (but then, we're back to reactiveness being 
implementation).

Still puzzled, sorry.

Cheers,
Bijan.

Received on Monday, 6 March 2006 20:09:29 UTC