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

Re: [RIF][UCR] Suggestion for new Abstract UC

From: Ed Barkmeyer <edbark@nist.gov>
Date: Thu, 26 Jan 2006 14:00:56 -0500
Message-ID: <43D91C68.9020305@nist.gov>
To: W3C RIF WG <public-rif-wg@w3.org>

Francois Bry wrote:

> John Hall wrote:
> 
>> I'd like to propose a new category of use case: "Interchange of 
>> Human-oriented Business Rules". A RIF is needed for interchange 
>> between tools that support rules of this kind.
>>
>> An example of a human-oriented business rule is (from the EU-Rent case 
>> study used in SBVR):
>>    "A EU-Rent car must not be handed over to a driver who appears to 
>> be intoxicated."
>>
> In my humble opinion, there are two opposite ways to achieve a language 
> for "Human-oriented Business Rules".
> 
> The first approach is to start with a natural language, say English, and 
> to derive from specifications (like the example John gives) a rule in a 
> formal language. This is the natural language processing approach. ...
> 
> The second approach is to start with a formal language, and to
> derive from specifications (like eg: forall x y not (hand-over-to(x, y) 
> & intoxicated(x)) a rule in a so-called "controlled" natural language 
> (eg the rule in English John mentions.). ...
> 
> I believe that the W3C RIF WG should consider now the second approach 
> and keep the first approach for a future agenda -- maybe in a few 
> decades or so. A controlled English syntax for RIF would perfectly 
> fit in the second work phase of the W3C RIF WG.

And Stan Devitt supported this.

Regrettably, I think Francois and Stan are rejecting "requirements" that no 
one has suggested.

I also agree that the RIF WG should specify an XML representation of a formal 
language for rules.  And I don't think there is any reason for the RIF WG 
*ever* to specify the form in which Rules Engines communicate with humans or 
to specify any kind of "controlled natural language".

But I want to separate this issue from what I understand to be the value of 
John Hall's proposed use case.

As I understand it, the issue that John Hall's use case addresses is the 
exchange of rules
  - between "Business Rule Management" systems,
  - between Business Rules Management systems and "rules execution engines",
  - between Business Rules Management systems and "rules rewriting systems".

While many apparently believe that the representation used in those exchanges 
would be some kind of "controlled natural language", I don't.  At most, such a 
representation may be of use in the first bullet, but surely not in the other 
two.  For the whole set of exchanges, the representation used must be formal 
logic!  The exchange representation used to communicate with "business people" 
is on the *other* side of the business rules systems, just as the 
representation on the other side of the rewriting system is Java or OCL.

That said, the question is:  What (additional) requirements would these 
exchanges place on the RIF?  And that is what I would expect the use-case to 
elucidate.

John's example suggests two requirements for "generalizations":
  - "query" predicates appearing in the antecedent that may not have machine 
realization
  - "actions" appearing in the consequent that may not have machine(-only) 
implementations.

In my experience, both of these ideas also exist in workflow management 
systems and appear in the interactions between the WfMS and its associated 
rules engine.  And that constitutes a significant part of the *market* for 
rules engines.

Moreover, both of these ideas can *look like* "attached procedures", for which 
the rules engine only *presumes* machine implementation.  All the engine 
really requires is that the query/action has a machine interface that is 
somehow consistent with the representation of the "attached procedure" 
invocation in the rule syntax.  The implementation behind that interface is a 
black box.  And our "formal model" of attached procedures isn't going to go 
beyond that.  So I don't see external procedures that are possibly 
human-implemented as being obviously out-of-scope.

Example:  The U.S. Postal Service has a system for processing incoming mail 
that sorts out pieces that have bar-codes into one channel, and feeds the 
others to OCR equipment that reads and recognizes addresses and prints bar 
codes onto the pieces on-the-fly.  For pieces the OCR system cannot recognize, 
it sends the images to a sorting center staffed by human experts who key the 
postal codes in time to beat the mailpiece to the bar-code printer.  Only 
those that don't make it go to the "manual-handling" channel.  The human 
actions are integrated into an automated rules-managed process in real-time, 
with a peak rate of 600,000 mailpieces per hour and a "manual-handling" rate 
of less than 1%.  Lesson: The nature of the implementor of an external query 
function is irrelevant.

Can we just agree that:
  The Human-Oriented Rules use case will demonstrate the requirements for 
formal rule exchanges between "business rule management" systems and other 
software systems.

And then see what we get?

-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 Thursday, 26 January 2006 19:01:03 GMT

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