Going on 5 years ago, I wrote part 1. Now, finally, it’s time for the rest of the story.
Here is a graphic on how various reasoning technologies fit the practical requirements for reasoning discussed below:
This proved surprisingly controversial during correspondence with colleagues from the Vulcan work on SILK and its evolution at http://www.coherentknowledge.com.
The requirements that motivated this were the following: Continue reading “Requirements for Logical Reasoning”
Well this is a blast from the past… I was working on “the next post” about how Watson, Google, and the semantic web threaten the major BRMS systems when I found myself rewriting that what matters about Rete Algorithm-based production rule systems is that the order of the rules does not matter. It occurred to me that I must have written that a dozen times or more in my career so I did a Google and found this old paper has been on-line at the Free Library On-Line since 2006! I recall writing this in the early nineties and the owner of an AI magazine telling me he carried it with him for the better part of a year (and printing it in his magazine, I think). Some of you may enjoy reading it again!
1. WHAT IS AN EXPERT SYSTEM?
An expert system is a program that includes expertise.
2. WHAT IS EXPERTISE?
Expertise is knowledge that enables an individual, group or program to perform an intellectual task better than that task can be performed without the expertise.
3. HOW IS EXPERTISE ENCODED WITHIN A PROGRAM?
Expertise, being knowledge, falls into a few general categories.
Some knowledge is declarative knowledge which doesn’t do anything but which represents truth or state. Such knowledge can be stored in a standard database.
Some knowledge is algorithmic and can therefore be flow charted. Such knowledge can be expressed as a routine in any procedural programming language. Not everything a person or organization knows can be easily translated into data structures and flow charts, however.
4. SO FLOW-CHARTABLE ALGORITHMS SHOULD BE CODED PROCEDURALLY?
Yes, if the flow chart is actually produced, if it is not extraordinarily complex, and if there is no reason to believe that the flow chart is incorrect or incomplete. After all, procedural languages and flow charts are isomorphic, anything that can be expressed in one can be expressed using the other. However, if it is hard to produce a flow chart, it will be even more difficult to produce a working program using a procedural language.
In the spring of 2012, Vulcan engaged Automata for a knowledge acquisition (KA) experiment. This article provides background on the context of that experiment and what the results portend for artificial intelligence applications, especially in the areas of education. Vulcan presented some of the award-winning work referenced here at an AI conference, including a demonstration of the electronic textbook discussed below. There is a video of that presentation here. The introductory remarks are interesting but not pertinent to this article.
Background on Vulcan’s Project Halo
From 2002 to 2004, Vulcan developed a Halo Pilot that could correctly answer between 30% and 50% of the questions on advanced placement (AP) tests in chemistry. The approaches relied on sophisticated approaches to formal knowledge representation and expert knowledge engineering. Of three teams, Cycorp fared the worst and SRI fared the best in this competition. SRI’s system performed at the level of scoring a 3 on the AP, which corresponds to earning course credit at many universities. The consensus view at that time was that achieving a score of 4 on the AP was feasible with limited additional effort. However, the cost per page for this level of performance was roughly $10,000, which needed to be reduced significantly before Vulcan’s objective of a Digital Aristotle could be considered viable.
If you are considering the use of any of the following business rules management systems (BRMS):
- IBM Ilog JRules
- Red Hat JBoss Rules
- Fair Isaac Blaze Advisor
- Oracle Policy Automation (i.e., Haley in Siebel, PeopleSoft, etc.)
- Oracle Business Rules (i.e., a derivative of JESS in Fusion)
you can learn a lot by carefully examining this video on decisions using scoring in Ilog. (The video is also worth considering with respect to Corticon since it authors and renders conditions, actions, and if-then rules within a table format.)
This article is a detailed walk through that stands completely independently of the video (I recommend skipping the first 50 seconds and watching for 3 minutes or so). You will find detailed commentary and insights here, sometimes fairly critical but in places complimentary. JRules is a mature and successful product. (This is not to say to a CIO that it is an appropriate or low risk alternative, however. I would hold on that assessment pending an understanding of strategy.)
The video starts by creating a decision table using this dialog:
Note that the decision reached by the resulting table is labeled but not defined, nor is the information needed to consult the table specified. As it turns out, this table will take an action rather than make a decision. As we will see it will “set the score of result to a number”. As we will also see, it references an application. Given an application, it follows references to related concepts, such as borrowers (which it errantly considers synonomous with applicants), concerning which it further pursues employment information.
On the heels of IBM’s acquisition of Lombardi comes Progress Software’s acquisition of Savvion. The salient similarities are that IBM is adding BPM applications to its middleware stack as is Progress, at least with regard to its enterprise service bus offerings. More interesting is the relationship between Progress’ complex event processing software and Savvion’s BPM. Also of note is the vendor-provided integration of JBOSS Rules within Savvion versus the unrealized potential of IBM’s Ilog with respect to Lombardi.
We’ve written several times about the artificial distinction between CEP and BPM, their inevitable convergence, and the immature integration of business rules with business process management and event processing that inhibits knowledge-driven governance and decisioning. Continue reading “Rule and event-driven business process M&A”
In preparing for my workshop at the Business Rules Forum in Las Vegas on November 5th, I have focused on the following needs in reasoning about processes, about events, and about or over time:
- Reasoning at a point within a [business] process
- Reasoning about events that occur over time.
- Reasoning about a [business] process (as in deciding what comes next)
- Reasoning about and across different states (as in planning)
Enterprise decision management (EDM) addresses the first. Complex event processing (CEP) is concerned with the second. In theory, EDM could address the third but it does not in practice. This third item includes the issue of governing and defining workflow or event-driven business processes rather than point decisions within such business processes.
Business applications of rules have not advanced to include the fourth item. That is to say, business has yet to significantly leverage reasoning or problem solving techniques that are common in artificial intelligence. For example, artificially intelligent question and answer systems, which are being developed for the semantic web, can do more than retrieve data – they perform inference. Commercial database and business intelligence queries are typically much less intelligent, which presents a number of opportunities that I don’t want to go into here but would happy to discuss with interested parties. The point here is that business does not use reasoning much at all, let alone to search across the potential ramifications of alternative decisions or courses of action before making or taking one. Think of playing chess or a soccer-playing robot planning how to advance the ball on goal. Why shouldn’t business strategies or tactical business decisions benefit from a little simulated look-ahead along with a lot of inference and evaluation?
Even though I have recently become more interested in the fourth of these areas, I expect the audience at the business rules forum to be most interested in the first two points above. There will also be some who have enough experience with complex business processes, which are common in larger enterprises. These folks will be interested in the third item. Only the most advanced applications, such as in biochemical process planning, will be interested in the fourth. I don’t expect many of them to attend!
The notion of enterprise decision management (EDM) is focused on point decision making within a business process. For enterprises that are concerned with governing business processes, a model of the process itself must be available to the business rules that govern its operation. I’ve written elsewhere about the need for an ontology of events and processes in order to effectively integrate business process management (BPM) with business rules. Here, and in the workshop, I intend to get a little more specific about the requirements, what is lacking in current standards and offerings, and what we’re trying to do about it. Continue reading “Time for the next generation of knowledge automation”
I had the pleasure of visiting with some fine folks at Cycorp in Austin, Texas recently. Cycorp is interesting for many reasons, but chiefly because they have expended more effort developing a deeper model of common world knowledge than any other group on the planet. They are different from current semantic web startups. Unlike Metaweb‘s Freebase, for example, Cycorp is defining the common sense logic of the world, not just populating databases (which is an unjust simplification of what Freebase is doing, but is proportionally fair when comparing their ontological schemata to Cyc’s knowledge). Not only does Cyc have the largest and most practical ontology on earth, they have almost incomprehensible numbers of formulas describing the world. Continue reading “Cyc is more than encyclopedic”
Does your business have logic that is more or less complicated than filing your taxes?
Most business logic is at least as complicated. But most business rule metaphors are not up to expressing tax regulations in a simple manner. Nonetheless, the tax regulations are full of great training material for learning how to analyze and capture business rules.
For example, consider the earned income credit (EIC) for federal income tax purposes in the United States. This tutorial uses the guide for 2003, which is available here. There is also a cheat sheet that attempts to simplify the matter, available here. (Or click on the pictures.)
What you will see here is typical of what business analysts do to clarify business requirements, policies, and logic. Nothing here is specific to rule-based programming. Continue reading “Harvesting business rules from the IRS”