Semantics and Business Rules

The Business Rules Group is a community of practice that has formed to promote and exchange best practices as they relate to applying rule-based architectures to business systems. The Business Rules Group defines business rule as follows:

Business rule

"A business rule is a statement that defines or constrains some aspect of the business. It is intended to assert business structure or to control or influence the behavior of the business."^[41]

From a semantic perspective, we would say that a business rule is a declarative statement, made at the metadata level, that can be evaluated or asserted at the instance level. The reason for saying that it is at the metadata level is discussed later in this chapter, under "How Semantics and Business Rules Amplify Each Other."

It also generates new data. Sometimes this new data is trivial, as in a rule that validates an input field to determine its likely validity. This might be implemented by a rule that says that zip codes must be five digits long. Presented with a two-digit zip code, this rule would create a piece of data (an error number) that states, "Data supplied does not match our pattern and is likely not valid; please reenter."

However, many rules do much more complex evaluation and creation of data. The calculation of your net paycheck could be the product of a cascade of business rules.

Two of the biggest advocates of the business rules approach are Ron Ross^[42] and Barbara vonHalle.^[43] In the following I will use their terminology and juxtapose it, where appropriate, with the equivalent terminology from the database domains and the AI domains.

Categorizing Business Rules

Business rules have been categorized several different ways. Generally, the first division is between those that primarily prevent things from occurring in some sets of circumstances and those that cause new actions to occur. The general terms inhibitors and exciters map to the different domains, as shown in Table 8.1.

Table 8.1: TERMS FOR RULE TYPES.

	Inhibitors	Exciters
Database	Constraints	Triggers
Business rules/Ron Ross	Verifiers	Evaluators
Business rules/Barbara	Constraints	Enablers, computations and inferences
Von Halle
Artificial intelligence	Guards, truth maintenance	Production rules
	Systems
RuleML (XML)	Schema	Tranformers

For now let's consider only two types of rules: those that prevent or impede operations and those that enable, allow, or perform operations. Next we'll examine how rules are composed and organized. To do this, we need to take a semantic detour and ask, What do rules consist of?

Semantic Evolution of Business Rules

Rule-based systems have been evolving in their use of semantics. In the early days of AI, rules were expressed in terms of semantics that were made up at the instance level. Early AI systems said things such as "Daisy is a pet" and "Pets must be dogs, cats, or birds" and elsewhere might say "Veterinarians take care of domestic animals." But this doesn't resolve anything. Is a domestic animal a pet? Do we need to know if Daisy is a dog, a cat, or a bird? As rule bases grew, resolving these slight (and often not obvious) discrepancies became harder and harder.

Ontologies can help resolve these semantic ambiguities. However, it appears that starting with the semantics and the ontologies and then working toward the rules seems to be more productive than starting with the rules and trying to work out which ones apply to which circumstances.

To put it another way, the business rules movement tends to go through four stages, as shown in Figure 8.16. This seems to be a healthy progression: We start with the expression of the meaning and intent (rather than with the technology), and then gradually make it more and more formal. Michael Uschold describes a similar progression in the adoption of rule-based approaches in Ontologies: Principles, Methods and Applications.^[44]

Figure 8.16: Evolution of rule usage.

In the informal rule identification stage, organizations have heard of business rules and ask teams to "identify" the rules in their application. This typically takes the form of changing the design specification to have a separate section for the rules and then discussing these with users.

Formal rule definition is the stage where organizations begin to use the models, categorizations, and tools as described by Ross and Von Halle. This is the point at which the semantic model tends to enter the picture as a prerequisite, and the rules are expressed formally enough that designers can reason about them. Rules that are in conflict, or situations where there are gaps or ambiguity as to which rule to apply, can be discovered. This is also the stage where some organizations begin to use tools to extract the rules from their existing systems.

Code generation requires tools such as Aion^[45] or Blaze^[46] that can convert the formally expressed rules into code, which can be directly executed. Computer aided software engineering (CASE) tools did some of this, but the rules were primarily at the presentation level rather than the business logic level. Scientio^[47] has been working on a rules engine based on RuleML, an XML expression for rules.

In the final stage, executing rules directly, the rules are expressed as data and are changeable at run time. There are many compelling reasons to do this. A recent survey of large organizations found that 8% changed prices on a minute-by-minute basis. Organizations that do this have long ago shifted their pricing algorithms to be data driven, but they have typically done this in custom systems. There are many other areas where organizations would like to respond to change rapidly (and confidently). The main challenge is the infrastructure that must be built up around security (who can change the rules?) and predictability (what will be the impact of changing this rule?).

Terms and Facts Are the Semantic Basis for Business Rules

Business rule

"A business rule is one and only one of the following: term, fact, or rule."^[48]

Business rule is defined as a term, a fact, or a rule. This appears to be recursive, but I believe the intent was for business rules to be an umbrella term and rule a specific subtype. Let's take a closer look at what terms, facts, and rules are, semantically.

Terms

A term, very loosely, is a vocabulary item. It is something that can be defined in a way that practitioners in a field of endeavor will agree on its meaning. As we will discuss in Chapter 9, techniques exist to create more precise and consistent sets of terms, but for now we can proceed with the idea that there is a set of terms on which the facts and rules will be based (or expressed in terms of).

Facts

Facts, in the business rule world, are expressions about two or more terms. As we will see in the Chapter 14, this maps nicely to an resource description framework (RDF) triple (term, fact, term). Figure 8.17 describes a "fact": A customer places an order.

Figure 8.17: A declared fact.

This sounds good until you realize that we have no basis to know what "places" means. It is just a statement, with no clue about its meaning. This is a different definition of fact than that which is used in the AI community. In most AI-based methodologies, a fact is at an instance level and not at the schema level. Facts are generally "asserted." So at the instance level, we might assert a fact as in Figure 8.18.

         GM placed order 1234. 

Figure 8.18: An asserted fact.

Two things become apparent from this:

1. It is not obvious what "placed" means.

2. It is now obvious that without more information (e.g., what was the order for and who "placed" it), this statement doesn't mean much.

If we accept that the business rule type of fact is "prescriptive," in that it proclaims the type of facts that can be asserted, and the AI type of fact is "descriptive," in that it describes relations as they exist, we can make some headway.

Rules

Business rules, then, are expressed as terms or facts (or other rules). They either express conditions that must be held true ("A customer balance must not exceed $10,000") or they express rules to generate new information or actions ("The order total is the sum of all the order line amounts" or "Shipments will be held until customs releases them").

There are dozens of types of rules: rules for validation, rules for calculation, rules for typing and ordering, and rules for evaluating. I strongly suggest that anyone interested in how these approaches can improve the flexibility of their business systems should pursue the application of business rules.

Meanwhile, as this is a book on semantics, let's consider how rules and semantics work together.

^[41]From http://www.businessrulesgroup.org.

^[42]Ronald G. Ross, The Business Rule Book Classifying, Defining and Modeling Rules, Houston: Business Rule Solutions, LCC, 1997.

^[43]Barbara Von Halle, Business Rules Applied: Building Better Systems Using the Business Rule Approach, New York: Wiley, 2002.

^[44]See http://citeseer.nj.nec/uschold96ontologie.html for further information.

^[45]Aion is now part of Computer Associates; see http://www3.ca.com/Solutions/Product.asp?ID=250 for further information.

^[46]See http://www.blaze-advisor.net/blaze_rules_engine.htm for further information.

^[47]See http://www.scientio.com/ for further information.

^[48]Ron Ross, DAMA International Symposium, San Antonio, April 28–May 2, 2002.