What is this series of articles about?

This is the twenty-fifth article in a series in which I describe a practical method of developing unambiguous natural language rule statements.  I've developed this method for a large Australian government agency that has selected the Business Rules Approach and the Object Management Group's Semantics of Business Vocabulary and Business Rules (SBVR)^[1] as representative of best rules practice.

The story so far

We've been looking at some of the rules governing airline passenger activities (such as booking flights, checking, and boarding) and airline operations.  So far we've created a set of rule statements, the fact types on which the rules are based, and some rule statement templates and sub-templates for generating rule statements.

We've also been developing a taxonomy of rules as well as a rule statement development method based on selection of the appropriate template and sub-template(s) for each type of rule.  The taxonomy, templates and sub-templates are listed in the [sidebar] along with all valid rule statements and supporting fact types.

The font and colour conventions used in these articles reflect those in the SBVR.^[2]  In addition, any technical terms (particularly those drawn from the field of linguistics) are rendered in a bold italic font.

Generic and specific fact types

While the vast majority of fact types we've collected so far deal with the specifics of airline travel, some of them (reproduced here) would be equally applicable to other industries, since they deal with properties, categories, relationships, documentation, or features of persons, organisations, addresses, payments, or time periods, which may be found in the ecosystem of most (if not all) industries.  For example:

1. FT118, FT121, FT144 – FT146, and FT99 – FT101 are a sample of those that cover properties and documentation of persons;
   
   
2. FT147 deals with just one of the many properties of organisations;
   
   
3. FT44 – FT47 and FT61 – FT63 are a sample of those that cover components of addresses;
   
   
4. FT22 and FT23 are a sample of those that cover categories of payments;

These can therefore be described as generic fact types, by contrast with all but one of the remainder, which are specific fact types, in this case specific to the airline industry.  Note that I say “specific to the airline industry” rather than specific to a particular airline.  In practice I find that the vast majority of fact types that model the business of any one organisation operating in a particular industry apply equally to other players in the same industry.  Of course, an organisation may choose to use different terms for some concepts (for example, some organisations prefer the term locality name to placename), and different terms are used in different countries (I deliberately used postal code as a neutral term for what is known as zip code in the US and postcode in Australia).

However FT177 (reproduced below) is different again in that it uses the term attribute rather than the name of any particular attribute.  To a data modeller, age, height, and date of birth are attributes of the entity class person, to be included in one or more data models of a business dealing with persons, whereas attribute will not appear in any data models per se, but may arise in discourse about the metamodel behind the data models.

For want of a better name, I refer to fact types such as this as fundamental fact types to distinguish them from generic and specific fact types.  By the way, I am conscious that some might prefer to word FT177 as attribute is different from attribute and still others might prefer attribute is different than attribute; this is a matter of taste.  What is important is that one and only one of these wordings should be used within one organisation for this fact type, those derived from it (such as FT169 and FT173 – FT175), and of course any rule statements based on such fact types.

What other fundamental fact types are there?  FT182 is an obvious candidate, which can be used, along with FT177, for attributes of any type.

By contrast, FT183 – FT185 can only be used for quantitative attributes.  Note with these that I have used quantity on the “right hand side” rather than repeat quantitative attribute.  This is because a quantitative attribute can be compared with another quantitative attribute (as in RS25), a suitable numeric literal (as in RS24), or indeed an expression (see RS87 reproduced later in this article).  The term quantity signifies a generic concept that covers quantitative attributes as well as numeric literals (see FT186).

Of course, FT178 – FT181 from the previous article^[3] aren’t wrong as they stand, but the formulations here are more precise, and of course FT187 documents that quantitative attributes are a specific type of attribute.  Don’t be alarmed by the apparent conflict between FT186 and FT187: the real world is full of such instances of “multiple inheritance” whereby a class of objects is a subclass of more than one superclass (e.g., man is a category of adult person and man is a category of male person).

As we saw in Article 23,^[4] many rules deal with the time dimension; in Article 24^[3] we encountered the following fundamental fact types covering relationships between time periods and time points.

Other such fact types are:

Of course FT164 can be derived from FT192 and FT193:

Rule statement RS87 is one of many that use fact types like this (in this case FT190):

Styling of verb phrases expressing comparisons

The sharp-eyed among you may have noticed that the styling of the verb phrases be less than, be equal to, and be earlier than in the renderings of RS24, RS25, and RS87 in this article differs from that used in earlier articles, namely be less than, be equal to, and be earlier than.  This is a deliberate change to align the constrained natural language described in these articles with the SBVR.  In this month’s sidebar all verb phrases expressing comparisons have been restyled as verb phrases in line with the SBVR.  Of course the styling of words and phrases in a rule statement has no semantic implications, but it does help to clarify the anatomy of each rule statement and its relationship to the underlying fact types.  Note that no, like the other logical operators and and or, continues to be rendered as a keyword.

An improved formulation for a particular rule statement type

Another improvement I would like to make is in the handling of rule statements that govern optional singular data items (those that, if specified, may only be specified once).  RS15 is an example:

This, however, suggests that there is an obligation to specify a frequent flier membership (there is none) rather than a prohibition against specifying more than one frequent flier membership.  The following alternative formulation overcomes this problem:

However, while this was a constraint applied by at least one airline in the early days of online reservation systems, most if not all now allow for different frequent flier membership numbers to be specified for different passengers in a multi-passenger booking (which of course can only be done at the conformation stage, when the individual passengers are listed).  This requires a brand new rule statement:

RS201 (and the revised formulation of RS15) require the following new template:

This is based on RT20 (see sidebar) with the only changes being:

1. the substitution of more than <positive integer> in place of {a|an} in the third line;
2. the addition of the fourth line to allow for phrases such as for any one passenger in RS201.

Subforms and complex data items in data rules

The main difference between RS201 and the revised formulation of RS15 is of course the inclusion of the phrase for any one passenger.  Rules governing the data in a form may cover:

1. data fields that appear only once in the form (such as departure date in a flight booking request), or
2. data fields that form part of a subform in that form that can be repeated (such as the subform in a flight booking confirmation that allows for information about each passenger to be supplied).

While the passenger details subform in a flight booking confirmation allows for up to 9 passengers to be listed (this is a limitation of the international reservation network) another variety of subform caters for complex data items such as addresses, which consist of multiple subordinate data items.  If there is more than one address field in a form (many forms allow for a person to supply residential and postal addresses), the subordinate data items will most likely have the same names in each complex data item (as in RS202 and RS203).  Even if there is only provision for one address, it is often better to refer to the address as well as the subordinate data item; for example, RS202 would be appropriate even if the residential address were the only address being captured.

While RT38 as it stands (reproduced above) caters for RS202, a small enhancement (see below) is required to support RS203.

This template supports alternative wordings of RS40 – RS45 (see sidebar) allowing us to dispense with RT39 (which was needed for the original wording of these rule statements).

A similar enhancement can be made to other data cardinality rule statement templates, as follows (each with an example of a rule statement that can be generated from that template):

Where to now?

In this series so far, we have wandered through the landscape of natural language rule statements on a journey of discovery.  The downside of this is that the big picture has been hard to see: many readers have asked me whether there is a resource that sets out the big picture.

Starting with the next article, I will be adopting a different approach, in which I first set out the big picture then deal with specific aspects of natural language rule statement authoring.

In preparation for that, I’ve done some rearrangement (in this month’s sidebar) of:

• the taxonomy of rules,
• the “metarules” (determining which rule statement template should be used for each type of rule), and
• the rule statement templates themselves in the sidebar.

Of course, if you’re impatient to see the big picture, you might like to have a look at my book “Writing Effective Business Rules” (published by Elsevier), which should be available by the time this article is published.

References

[1]  Semantics of Business Vocabulary and Business Rules (SBVR), v1.0.  Object Management Group (Jan. 2008).  Available at http://www.omg.org/spec/SBVR/1.0/PDF  

[2]  The font and colour conventions used in this and other well-formed rule statements and fact types in these articles reflect those in the SBVR, namely underlined teal for terms, italic blue for verb phrases, orange for keywords, and double-underlined green for names and other literals.   Note that, for clarity, less than well-formed rule statements will not use these conventions.  

[3]  Graham Witt, "A Practical Method of Developing Natural Language Rule Statements (Part 24)," Business Rules Journal, Vol. 12, No. 12 (Dec. 2011), URL:  http://www.BRCommunity.com/a2011/b630.html  

[4]  Graham Witt, "A Practical Method of Developing Natural Language Rule Statements (Part 23)," Business Rules Journal, Vol. 12, No. 10 (Oct. 2011), URL: http://www.BRCommunity.com/a2011/b620.html.

# # #