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

From: Piero A. Bonatti [mailto:bonatti@na.infn.it] 
Sent: Thursday, February 09, 2006 5:54 PM
To: Vincent, Paul D; Dieter Fensel; Gerd Wagner; edbark@nist.gov;
public-rif-wg@w3.org
Subject: Re: [RIF] [UCR]: What is the RIF (revisited) --> disjunctive
conclusions

 

On Thursday 09 February 2006 18:23, Vincent, Paul D wrote:

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

 

but you didn't object to what Dave said about taking RIF as a chance to
tackle 

diversity in the less mature semantic web area [today, 14:42], i.e. an
early 

attempt at standardization in a less restricted setting

 

Actually - I don't care much about what I consider the "advanced future"
rules topics unless they are considered compulsory. 

 

>  I'm pretty sure that this rule is not defined as such in any

> Fair Isaac financial software system.

 

is this a good reason for leaving this kind of problems out of scope?

 

Well, if there is no use case for it, then yes I would consider it out
of scope. Anyone can invent potential uses for rules, but is that a
useful exercise for RIF? I suspect not. 

 

> Agreed - this is typically (in commerce) handled by planning and

> optimization engines, or constraint based reasoning. 

 

planning is another excellent target for rule-based systems - I can't
see why 

should we leave it to others

 

Hopefully there will be constraint rules etc as part of RIF. As
commercial uses for these, and the need for interchange, is probably
less than for process automation PR then they may be a lower priority.
Will need to recheck the use cases to see if these are mentioned...

 

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

 

maybe they have to be hardwired because the rule language's
expressiveness is 

poor...

 

ETL tools tend not to use a rule language, AFAIK. Due to the volumes of
data being handled, they tend to be SQL-based, although clearly there is
an expressiveness/performance boundary here too.

 

somehow your message seems to confirm my thesis (?)

 

I hope it helps, at least!

 

piero