A Practical Method of Developing Natural Language Rule Statements (Part 25)

Graham   Witt
Graham Witt Consultant / Author Read Author Bio || Read All Articles by Graham Witt
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;
FT118.  person is of age
FT121.  person has height
FT144.  person has date of birth
FT145.  person has Australian passport
FT146.  person has citizenship
FT99.  passenger presents passport
FT100.  passport bears likeness of passenger
FT101.  passport specifies expiry date
FT147.  organisation has trading name
FT44. postal address includes address line
FT45. postal address includes placename
FT46. postal address includes postal code
FT47. postal address includes country name
FT61.  postal authority allocates place name
FT62.  postal authority allocates postal code
FT63.  postal authority is of country
FT22. credit card payment is a category of payment
FT23. electronic transfer payment is a category of payment

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.

FT177.  attribute is different to attribute

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.

FT169.  status is different to status
FT173.  speed is different to speed
FT174.  altitude is different to altitude
FT175.  heading is different to heading

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

FT182.  attribute is the same as attribute

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).

FT183.  quantitative attribute is less than quantity
FT184.  quantitative attribute is more than quantity
FT185.  quantitative attribute is equal to quantity
RS24.  The number of passengers specified in each flight booking request must be no less than one.
RS25. The number of passenger names specified in each flight booking confirmation must be equal to the number of passengers specified in the flight booking request that gives rise to that flight booking confirmation.
FT186.  quantitative attribute is a category of quantity

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).

FT178.  status is a category of attribute
FT179.  speed is a category of quantitative attribute
FT180.  altitude is a category of quantitative attribute
FT181.  heading is a category of quantitative attribute
FT187.  quantitative attribute is a category of attribute

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.

FT158.  time period overlaps time period
FT160.  time period is defined by start date
FT161.  time period is defined by end date
FT164.  day is within time period

Other such fact types are:

FT188.  time period is earlier than time period
FT189.  time period is later than time period
FT190.  time point is earlier than time point
FT191.  time point is later than time point
FT192.  time point is within time period

Of course FT164 can be derived from FT192 and FT193:

FT193.  day is a category of time point

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

RS87. The departure time of the first or only outgoing flight specified in each flight booking confirmation that is made online must be no earlier than 3 hours after the booking confirmation time of that flight booking confirmation.

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:

RS15.  Each flight booking request must specify at most one frequent flier membership.

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:

RS15.  A flight booking request must not specify more than one frequent flier membership.

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. A flight booking confirmation must not specify more than one frequent flier membership for any one passenger.

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

RT48.  {A|An} <term 1> {<qualifying clause>|}
must not <verb phrase>
more than <positive integer> <term 2>
{<
preposition> {any one|the} <term 3>|} {(if any)|}
{{
if|unless} <conditional clause>|}.

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.

RS202. Each enrolment must include exactly one placename in the residential address.
RS203. Each enrolment must include exactly one placename in the postal address (if any).
RT38.  Each <term 1> {<qualifying clause>|}
must <verb phrase>
<
cardinality> <term 2>
{<
preposition> {each|the} <term 3>|}
{{
if|unless} <conditional clause>|}.

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

RT38.  Each <term 1> {<qualifying clause>|}
must <verb phrase>
<
cardinality> <term 2>
{<
preposition> {each|the} <term 3> {(if any)|}|}
{{
if|unless} <conditional clause>|}.

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).

RS40. Each flight booking confirmation must include at least one address line in the postal address (if any).
RS41. Each flight booking confirmation must include exactly one placename in the postal address (if any).
RS42. Each flight booking confirmation must include exactly one postal code in the postal address (if any).
RS43. Each flight booking confirmation must include exactly one country name in the postal address (if any).
RS44. Each flight booking confirmation must include exactly one first name in each passenger name.
RS45. Each flight booking confirmation must include exactly one last name in each passenger name.

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):

RT16. Each <term 1> {<qualifying clause>|}
must {({if|unless} <conditional clause>)|} specify
{<preposition> {each|the} <term 2> {(if any)|}|}
whether
{{
or not|} {it|{the|that} <term 3 >} <verb phrase 1>
    {<
article> <term 4 >|}|
{
it|the <term 5 >} <verb phrase 2> <or-list>}.
RS204. Each flight booking confirmation must specify for each passenger whether or not that passenger has a special meal requirement.
RT20.  {A|An} <term 1> {<qualifying clause>|}
must not <verb phrase>
{a|an} <term 2>
{<preposition> {any|the} <term 3> {(if any)|}|}
{{if|unless} <conditional clause>|}
.
RS205. Each flight booking confirmation must not specify a frequent flier membership for any infant passenger.

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  return to article

[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.  return to article

[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  return to article

[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. return to article

# # #

Standard citation for this article:


citations icon
Graham Witt , "A Practical Method of Developing Natural Language Rule Statements (Part 25)" Business Rules Journal Vol. 13, No. 2, (Feb. 2012)
URL: http://www.brcommunity.com/a2012/b638.html

About our Contributor:


Graham   Witt
Graham Witt Consultant / Author

Graham Witt has over 30 years of experience in assisting organisations to acquire relevant and effective IT solutions. NSW clients include the Department of Lands, Sydney Water, and WorkCover while Victorian clients include the Departments of Sustainability & Environment, Education & Early Childhood Development, and Human Services. Graham previously headed the information management and business rules practice in Ajilon's Sydney (Australia) office.

Graham has developed specialist expertise in business requirements, architectures, information management, user interface design, data modelling, relational database design, data quality, business rules, and the use of metadata repositories & CASE tools. He has also provided data modelling, database design, and business rules training to various clients including NAB, Telstra, British Columbia Government, and ASIC and in the form of public courses run by Simsion Bowles and Associates (Australia) and DebTech (USA).

He is the co-author, with Graeme Simsion, of the widely-used textbook "Data Modeling Essentials" and is the author of the newly published book, "Writing Effective Business Rules" (published by Elsevier). Graham has presented at conferences in Australia, the US, the UK, and France. Contact him at gwitt@pacific.net.au.

Read All Articles by Graham Witt
Subscribe to the eBRJ Newsletter
In The Spotlight
 Ronald G. Ross
 John A. Zachman
';
The Issue Is THE ENTERPRISE By John A. Zachman Jan. 2017 | Vol. 18, Iss. 1

Online Interactive Training Series

In response to a great many requests, Business Rule Solutions now offers at-a-distance learning options. No travel, no backlogs, no hassles. Same great instructors, but with schedules, content and pricing designed to meet the special needs of busy professionals.