- From: Ed Barkmeyer <edbark@nist.gov>
- Date: Thu, 26 Jan 2006 14:00:56 -0500
- 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 UTC