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

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

From: Ed Barkmeyer <edbark@nist.gov>
Date: Wed, 08 Feb 2006 16:07:06 -0500
Message-ID: <43EA5D7A.4030104@nist.gov>
To: "Vincent, Paul D" <PaulVincent@fairisaac.com>
CC: public-rif-wg@w3.org

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. 
> ...
> [I see from
> http://lists.w3.org/Archives/Public/public-rif-wg/2005Dec/0045.html the
> rule 
> 
> "every student with major in Computer Science must have a minor in
> Mathematics or in Physics"
> But in an operational s/w system this could be viewed as a constraint,
> but what is there to infer?]

In a certain sense, this is an excellent example of Francois' point about 
"what the rule means to ME".

As written, this rule involves a disjunctive consequent.  But in practice, 
this rule may operate as a data consistency test, which is effectively the 
contrapositive, e.g.:
   Default (usually NAF semantics): NOT (valid-major ?student);
  (valid-major ?student) <- (AND (has-major ?student ComSci)
    (OR (has-minor ?student Physics) (has-minor ?student Math)));
  (error 'InvalidProgram ?student)<-(NOT (valid-major ?student));
We can live with disjunctive consequents when they become antecedents.

If this rule is supposed to direct some kind of action, the disjunction is 
paralyzing.  (Or I place a probability of success on each minor and pick a 
random number.)

But it can also be viewed as a guidance rule, an Enabler:
   (forall ?minor)(prohibit select-minor ?minor);
   (permit (select-minor Physics)) <- (has-major ?student ComSci);
   (permit (select-minor Math)) <- (has-major ?student ComSci);
   (require (select-minor ?minor)) <- (has-major ?student ComSci);

The point is that a "business rule" taken out of an interpretation context can 
be highly ambiguous.  If the context is data set validation, or guidance 
(prohibition, permission, obligation), or action direction, or directed 
inference, you get different rulesets, and the apparent syntax of the rule is 
rewritten to match the syntax for the interpretation context.

This leads me to a related concern:

Existing rules authoring systems usually target specific "execution" systems 
and disallow rule expressions the target system can't process.  So if the RIF 
allows more than they can accept, they won't use the "extensions" and may 
reject rulesets (or specific rules) as "valid RIF" but "invalid for XXX".  The 
tool enforces a discipline on the user to express his intent in ways 
consistent with the (expected) tool capabilities.

RIF (and other things like SBVR) will enable the construction of authoring 
tools that don't target specific execution systems -- they produce RIF, for 
input to "any conforming system".  And those tools will probably support the 
entire scope of RIF expressiveness.  If we allow the user to express rules 
that nearly no current engine can process, someone will do just that, even in 
cases when he could have captured his intent with readily processable rules! 
And an authoring tool divorced from all engines is not in a position to 
enforce a stronger discipline, UNLESS RIF gives it the discipline rules.

So, if we are going to go beyond Dave Reynolds' "least common denominator", we 
would be well advised to identify explicit "dialects" or "subsets of 
expressiveness" that constitute "capability levels" or "conformance classes".
The "lingua franca" can support trade in grain and dyes and wine, but we have 
to officially recognize that there are wine merchants who will speak ships and 
money and wine, but won't be able to converse about grain, even though some 
merchants can do it all.

-Ed

-- 
Edward J. Barkmeyer                        Email: edbark@nist.gov
National Institute of Standards & Technology
Manufacturing Systems Integration Division
100 Bureau Drive, Stop 8263                Tel: +1 301-975-3528
Gaithersburg, MD 20899-8263                FAX: +1 301-975-4482

"The opinions expressed above do not reflect consensus of NIST,
  and have not been reviewed by any Government authority."
Received on Wednesday, 8 February 2006 21:07:15 GMT

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