RE: [RIF] [UCR]: What is the RIF (revisited) --> disjunctive conclusions

From: Piero A. Bonatti [mailto:bonatti@na.infn.it] 



 

On Wednesday 08 February 2006 18:20, Vincent, Paul D wrote:

> Another way of looking at this / let me infer: the commercial
inference

> engines that do not support "disjunctive conclusions" prove, by the
fact

> of their use in commerce, that this feature is not a requirement for

> rule use, and is therefore not a requirement for rule interchange.

 

the use in commerce is never equal to affordable technology. cobol has
been 

used for far longer than it should have, and better approaches were
delayed 

(at the cost of several expensive failures) precisely because many
people 

forget that current commercial applications are not the state of the
art, but 

rather the state of the market...

 

production rules are the cobol of decision support systems and semantic
web.  

surely in the area of trust management those who built systems based on
RETE 

had quite bad results compared to other approaches

 

Yes - I guess my "stake in the ground" is that RIF will be more useful
to the state of the market (initially) and thence should allow the
subset of "rules" that are widely used in commercial systems.

 

> 

> There may be applications and engines that require it - Perhaps
someone

> could point out the use cases, hopefully commercial, that require this

> feature?

> 

 

I understand that your organization's business has to do with decision
support 

systems in financial applications.  so you may appreciate the following 

example.  company C wants to sell part of the companies it controls.
the 

constraints are: (i) after the transaction, C should still be able to
produce 

whatever it cares to produce; (ii) companies should actually be sold,
i.e. C 

should not control them anymore after the transaction

 

you *need* disjunctions in the head to encode this problem - without
this 

feature the encoding is exponential. still the problem is of natural
interest 

and it would be nice to solve it with a rulebase

 

The overriding requirement in commercial applications is the KISS
principle: ie keep it simple. The rule you specify here is indeed a
candidate for RIF, probably under the human-readable rules aspect (as
this sort of business goal is so rarely specified as a rule today - see
the OMG / BRGroup Business Motivation Model as one effort in this
direction). I'm pretty sure that this rule is not defined as such in any
Fair Isaac financial software system. Indeed, its quite difficult to
relate this rule to a business process (the "sell part of business"
process is more likely to be a workflow than a set of automated rules).

 

more generally, problems that admit multiple solution - to be chosen by
a 

human - benefit from some extension (disjunctions or alternative,
equivalent 

stuff).  if you want your system to suggest the alternatives, possibly
ranked 

with a preference value, then you're often going to have a hard time
with 

production rules, that are biased towards determinism (even priorities
don't 

help much in that case)

 

Agreed - this is typically (in commerce) handled by planning and
optimization engines, or constraint based reasoning. However, following
the KISS principle, a number of systems are implemented in production
rules to produce a "good fit solution" rather than an optimal, or list
of, solution(s).

 

another example is data integration, especially the (extremely
interesting!) 

"local as view" approach - see for example the INFOMIX effort 

(http://www.mat.unical.it/infomix).  again, with production rules you'd
have 

a hard time...

 

I could not see any detail on rule representation / execution on a quick
overview of INFOMIX's web site, but for sure production rules can be
(/are) used very successfully in data consolidation problems. If you
consider the ETL tools, they are effectively processing specific (and
unfortunately, often hard-wired) rules.

 

Dieter says this is still food for PhD students.  I don't agree - these
ideas 

are closer to pre-competitive solutions than some companies would like
to 

admit.  so I have to insist that a standard that can't handle this kind
of 

extra features is likely to become obsolete earlier than expected

 

moreover, I don't see why crafting a syntax and a meaning for richer
rules 

such as disjunctive rules should complicate RIF's task so much.  so what
is 

the real reason for keeping them out of the RIF?

 

None. I have no problem with RIF eventually supporting the superset of
possible rule types!

 

piero