While
not well suited for the task, traditional tools are often used to encode logical
knowledge.Traditional software tools provide two ways of encoding knowledge: one is as facts, or data, in memory; the other is as sequences of instructions coded in a procedural manner in database queries, web scripts or programming languages.
These two types of knowledge, factual and procedural, are natural for a computer because a computer is engineered from memory (facts/data) and a processing unit that executes a sequence of instructions (procedures). It is no accident that database tools and procedural programming languages have been with computers since the earliest days. It is no accident that early commercial use of computers was called 'data processing.'
Consider an airline reservation system. It has factual knowledge about passengers, flights, and bookings stored in a database. It has procedures that manipulate that data, for example to book a passenger on a flight.
This type of automation is well suited to a computer's design.
Logical knowledge is relationships. On paper, logical knowledge might be expressed as rules, or in tables showing conditions and implied results, or as graphs showing connections, or in formats that are particular to a given application area. Logical knowledge often mimics human decision making.
In an airline reservation system, pricing knowledge would be logical. It is a complex set of rules and tables describing relationships between air fare and dates, places, connections, durations, class, frequent flier miles, weekends, holidays, discounts, promotions and who knows what else.
Logical knowledge, unless relatively simple, does not lend itself to easy encoding in a computer.
It doesn’t fit well in a database, because the relationships expressed are more complex than the simple factual relationships databases can encode.
It doesn’t fit well in procedural code because the user is forced to artificially express the independent logical relationships as a sequence of instructions with well-defined flow of control.
Examples of Logical KnowledgePricing — the relationships between price and the factors affecting it, for almost any product of even modest complexity; Regulations — government’s and private organization’s rules and regulations, such as tax codes, insurance rules, legal requirements, benefits, purchasing, and work flow; Configuration — the complex relationships between customer needs and products and components; Support — the relationships between faults and symptoms in diagnostic technical support solutions, or between customer needs, and appropriate products and services; Scheduling — the rules governing broadcast scheduling, radio and TV music scheduling, work scheduling, resource allocation, sports events; Grammars — translation rules between data transfer protocols, program inputs, or natural languages; Scientific — geologic relationships between surface observations and oil below, electric circuit behavior, network modeling, medical diagnosis, and economic modeling. |
While
not well suited for the task, traditional tools are often used to encode logical
knowledge.
In a few cases, the traditional tools are workable. For example, if the relationships are simple enough to be expressed in tables with the same columns, then a database can be used effectively. If the rules fit readily in a decision tree, then that tree can be represented by procedural branching statements.
But logical knowledge of any significance has a variety of factors in the relationships, making them ill-suited for database; and no implied sequence of execution, making them awkward to code procedurally. Different combinations of rules in different sequences are required depending on the input data.
The advantage of using traditional tools is, well, that they are traditional tools. There are a large number of users who are skilled in using them.
The disadvantage of using traditional tools is the procedural code and/or fragmented collections of data tables needed to express the interrelated logical relationships winds up being a rat’s nest of unwieldy, difficult to maintain and highly error prone code.
For some application areas, this might not be a factor. But if the logical knowledge is changing, and it is important to keep up with the changes, then the costs of maintaining the encoding of the logical knowledge becomes prohibitive. More importantly, due to the time consuming and error prone nature of that approach, competitive advantage could well be lost.
There’s If-Then and then there’s If-ThenThe term ‘if-then’ for rules is sometimes confusing because it is used both to describe branching instructions in a procedure, and certain logical relationships. In spreadsheets and procedural code, IF() functions and if-then statements steer the flow of control. As logical relationships, if-then rules have no implied order of execution. |
If
the problem with encoding logical knowledge is the underlying machine, then what’s
needed to do the job right is a machine designed to handle logical knowledge.
Building a hardware machine is not very practical, but software can be used to
build a wide variety of virtual machines.
This is exactly what is done in all of the tools available for business rule systems, expert systems, knowledge base systems, logicbase systems, case-base systems and others.
Each of these tools has a virtual machine architecture with two key components:
For example:
This architecture provides the major benefit that the logical knowledge no longer has to be forced into a format that is ill-served for coding it. Because the logical knowledge is more naturally expressed in a knowledge representation language (e.g. business rules), it is easier to create and maintain. Because it is easier to maintain, it is less error-prone, more reliable, and changes can be incorporated in production software much more rapidly.
In some cases the logical relationships can be maintained directly by those with the knowledge, avoiding the translation step through an intermediate programmer. This further magnifies the benefits.
Artificial IntelligenceThe science of Artificial Intelligence (AI) concerns itself with the engineering and use of virtual machines that work with knowledge that cannot be easily expressed either factually or procedurally. Working with logical knowledge is a large part of AI. The term AI might be somewhat justified considering that human brains, unlike computers, are naturally good at processing logical relationships. |
Unfortunately, there is tremendous variety in the forms of logical knowledge required for different application domains, and accordingly, there are a number of different tools and approaches.
How well a given tool fits a particular application depends on how close the knowledge representation language and reasoning engine match the way the application logic is naturally expressed and used.
For example, pricing knowledge is usually formal and precise, whereas knowledge about technical support has more vagaries in it, and also requires support for natural language questions and answers. Configuration knowledge includes rules for how components are combined and also needs to express the logical relationships of hierarchies of parts.
Both pricing and technical support would have reasoning engines intent on finding a specific solution, but the knowledge for configuring complex products needs to be applied in a building block manner, creating a complex structure as output.
There are numerous general-purpose tools that might fit a given application, or an organization might decide to build a customized tool for their particular application.
A customized tool has the benefit that the knowledge representation can be designed to specifically match the way knowledge for that application is expressed. This often means those with the knowledge can directly maintain the knowledge base without programmer intervention.
A general-purpose tool can be purchased off-the-shelf and might provide a good enough fit for the application.
Spreadsheets are a perfect example of a specialized tool for a specific type of knowledge. In this case the logical relationships are arithmetic formulas linking the contents of the various cells.
The designers of a spreadsheet program first create the pattern of cells and allowable formulas users can use to express relationships. That is the knowledge representation.
They then write a program that knows how to compute the required cells in a spreadsheet. That is the reasoning engine. The reasoning engine determines in what order the cells are calculated, and also computes a value for each of the cell formulas and contents.
The relationships defined in the spreadsheet, such as this cell is equal to the sum of those cells, are then used to compute values for different inputs. The result is financial users can directly enter the types of relationships they deal with in a familiar manner, without requiring a programmer. The underlying spreadsheet engine does the computation for them.
As we all know, spreadsheets are tremendously popular because they let non-programmers encode relationships that are executed by the spreadsheet calculation engine. Of course, they are limited to expressing the sorts of things you can express in an array of related cells and formulae.
There
are many general purpose business rule and expert system products that follow
the same architecture. They provide a knowledge representation for entering logical
relationships as rules, and a reasoning engine that knows how to execute those
rules.
These tools are powerful and are often used to solve the problem of encoding logical relationships.
The degree to which they are successful is related to how close the semantics of the particular logical relationships are to the given tool. When the tool does not fit particularly well, then often, programmers are still needed to code the logical relationships for the tool. This means those with the know-how do not maintain the logicbase directly. On the other hand, this is a better solution than using traditional tools because the programmer is now working with declarative specifications of the logical relationships rather than forcing them into difficult to write and maintain procedural code.
One way to enhance the fit between a reasoning engine and the logical relationships is to offer a multi-layered approach for writing rules and decision tables. This allows those with the know-how to write and test many, if not all, of their rules. The result is quicker initial development and faster, more reliable response to changing conditions.
Hybrid rule engines combine procedural and logical knowledge together in one software tool. This lets users apply procedural knowledge to those parts of the application that are procedural in nature, and logical knowledge to those parts that better modeled with rules or logical relationships.
ARulesXL™ is a rule-based engine, based on logic, that is integrated with Excel™. It is a powerful concept, combining the calculation engine of a spreadsheet with the reasoning engine of a business rules logicbase.
ARulesXL has a knowledge representation language that allows the rules to be written in a very easy to read and understand syntax, in text and decision table formats. One large accounting firm found it was possible to have meetings with people from various disciplines such as, tax, accounting, and law work together on an equity compensation package where all could read and understand the rules being used. This makes it possible for the person with the know-how in an organization to express their knowledge directly on a spreadsheet where the rules can be seen and experimented with.
Knowledge representation in ARulesXL uses a layered approach. This simplist level is decision tables, which specify conditions and values in a row and column format. The next level is general-purpose pattern-matching rules. The advanced level is pure logic which can be used to express the most complex and intertwined logical relationships.
Since procedural and logical knowledge are used to model separate parts of an application, the ARulesXL reasoning engine can run in conjunction with a variety of Web-based and PC-based application environments. This allows rules to be created and maintained in Excel, but then deployed to users over the Web or as part of any other software tool.
These are the primary benefits of using reasoning engines to build and deploy logical knowledge.