Posted on by paul@haleyAI.com

Confessions of a production rule vendor (part 2)

Going on 5 years ago, I wrote part 1.  Now, finally, it’s time for the rest of the story.

The bottom line to this story:

  • It’s time to trade rule technology dating back to the 80’s for state of the art AI.

The dominant rule/policy/decisioning systems are “production rule systems”.  Wikipedia defines a “production rule system” as follows:

  • A production system (or production rule system) is a computer program typically used to provide some form of artificial intelligence, which consists primarily of a set of rules about behavior. These rules, termed productions, are a basic representation found useful in automated planning, expert systems and action selection. A production system provides the mechanism necessary to execute productions in order to achieve some goal for the system.

Note the reference to out-of-favor “expert systems” and the lack of anything about reasoning…

The timeline below, which stops at the point of part 1, is intended to emphasize the following:

  1. 80’s technology dominates business rules, policy automation, and decision management
  2. artificial intelligence (AI) and natural language processing (NLP) have improved dramatically
  3. logical reasoning technology has advanced while production rule technology remains stagnant

It has more specific themes related to deep NLP, knowledge acquisition, and reasoning technology that the most competent AI systems all involve.  Although not critical to the point of this confession, the advances in Prolog technology since XSB, Flora-2, and SILK are notable.[1] More recently, deep learning is being applied to logical reasoning technology (for example see this Google Research).

Let’s pick up the story after this 30+ year timeline:

Part 1 addresses the logical inadequacies of production rule systems.  It also addresses their inability to implement what the community specified in the SBVR standard.  This is further discussed and graphically presented in a subsequent post on requirements for logical reasoning.

At the time of Part 1, I hoped Vulcan would release SILK to the public.   SILK was experimental but promising.  Vulcan’s funding over 5 years led to significant improvements in Flora and XSB, some of which were also incorporated into Cyc.  Among them were a transformation of extended first-order logic into Flora-2 code (which is an extended form of Prolog).  There was also a nice explanation facility, as shown below for a question answered with knowledge captured using the Linguist.[4]

If you take even a cursory look at other articles here, it should be clear that the Linguist can generate sophisticated logic.  So, I was most concerned with the functionality of SILK’s transform.  Unfortunately, Vulcan never released SILK, so this part 2 was delayed until a replacement developed.[5]

By the end of 2013, Coherent Knowledge had formed to develop Ergo, a successor to SILK.  But starting from Flora and XSB meant that much of what had been developed in SILK had to be recreated by a smaller team.  It took Coherent a few years to get to the point that we could target their product, Ergo.

We could not rely solely on our Coherent friends, however.  We had no practical alternative but to develop an alternative.  Now we can translate English into various theorem proving systems and into Flora or XSB (and, of course, Ergo).

For details, see Simply Logical English.

We have already done so for most of those listed here and welcome the opportunity to work with others to make the Linguist work for them.  For example, Intel funded the work that produces OWL and SCONE.

Here is what you need to know:  The Linguist makes it easy to eliminate all ambiguity from completely natural English.

  1. all sources of ambiguity become readily apparent and are easily resolved
    • no linguistic or logical skills beyond mere literacy are required
    • very good for business analysis and knowledge engineers
    • great for linguistic and logic education and experts
    • it’s generally available under a public-use license
  2. Machine translation of English into logic is fast, easy, and reliable.  Doing so by hand is painstaking and error prone.
    • highly skilled experts take time to translate even simple English into logic or rules
    • the resulting “code” is likely to suffer from errors of omission or expression

As for automating the knowledge in a business process, intelligent agent, or QA system, we target any of the following:

  1. Theorem proving yields the most powerful reasoning.
    1. but it typically fails miserably given inconsistent axioms (i.e., rules)
  2. XSB Prolog provides more powerful reasoning than production systems.
    1. it can handle logical inconsistences unlike theorem provers
    2. it is more practical and easier to use than other Prologs
  3. Flora offers more robustness and usability than XSB alone.

Overall, we recommend Flora and XSB.[6]

  • XSB Prolog is commercial, open-source.  It has been used in IBM Watson and by U.S. Customs.
  • Flora-2 is academic, open-source.  It has been used by Vulcan SILK, in SRI’s Sunflower, and others.
[1] All the while, Cyc advances…

[2] The author was Chief Scientist and Doug Lenat of Cyc was scientific advisor

[3] via under-specified semantic representation (USR) resulting from a unification-based grammar (CCG)

[4] Explanations provided by SILK for questions answered using knowledge captured by the Linguist:

[5] Vulcan kindly permitted us to use SILK towards a concept motivated by the Inquire prototype.

[6] at least until there is a modern PTTP with a couple of important features that XSB can now support thanks to Vulcan

2 Replies to “Confessions of a production rule vendor (part 2)”

  1. Pingback: It’s time to trade rule technology for state of the art AI? |
  2. Pingback: Is business logic too much for classical logic? – Commercial Intelligence

Comments are closed.