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

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

More about definitional rules:  complex concepts

In the previous article[3] I discussed definitional rules; this is a continuation of that discussion.  Any business providing services will of necessity develop concepts (with associated terms) to describe those services and the provision of them.  For example the term return journey has a quite specific meaning, expressed by the following definitional rule statement:

RS182. A return journey is by definition a journey in which:
• the
origin city of the first or only return flight of that return journey is the same as the destination city of the last or only outgoing flight of that return journey and
• the destination city of the last or only return flight of that return journey is the same as the origin city of the first or only outgoing flight of that return journey.

On reflection, this is probably a superior alternative to the approach adopted in an earlier article in this series, in which the individual components of the concept were defined (as in the following rule statements):

RS83. The origin city of the return flight of a return journey is by definition the same as the destination city of the outgoing flight of that return journey.
RS84. The destination city of the return flight of a return journey is by definition the same as the origin city of the outgoing flight of that return journey.

Comparison of these rule statements with RS182 reveals that RS83 and RS84 are not quite correct as they stand, as they do not take account of the fact that there can be more than one outgoing flight or return flight.  If these rule statements were to be retained, the following rewordings would be required:

RS83. The origin city of the first or only return flight of a return journey is by definition the same as the destination city of the last or only outgoing flight of that return journey.
RS84. The destination city of the last or only return flight of a return journey is by definition the same as the origin city of the first or only outgoing flight of that return journey.

Another concept that has quite a specific meaning, due to the constraints imposed by airline reservation systems, is signified by the term flight booking.  In particular, all passengers specified in a flight booking travel on all flights specified in the booking, depart from the same port(s), and travel to the same port(s).

Thus we can define flight booking using the following definitional rule statement:

RS183. A flight booking is by definition a booking for travel by one or more passengers on one or more flights such that all of those passengers depart from and travel to the same port(s) on all of those flights.

Again this is probably superior to the approach, adopted earlier, of defining an individual component of the concept (as in the following rule statement):

RS85. The set of passengers booked on each flight specified in a flight booking confirmation is by definition the same as the set of passengers booked on each other flight specified in that flight booking confirmation.

Definitional or operative rule statements?

Does the existence of definitional rule statements obviate the need for corresponding operative rules?  It could be argued that if RS182 (or RS83 and RS84) exist, there is no need for the corresponding operative rule statements RS184 and RS185, similarly if RS183 (or RS85) exists, there is no need for the corresponding operative rule statement RS186.

RS184. The origin city of the first or only return flight of a return journey must be the same as the destination city of the last or only outgoing flight of that return journey.
RS185. The destination city of the last or only return flight of a return journey must be the same as the origin city of the first or only outgoing flight of that return journey.
RS186. The set of passengers booked on each flight specified in a flight booking confirmation must be the same as the set of passengers booked on each other flight specified in that flight booking confirmation.

I have even had it put to me that, if the data entry form has been designed in such a way as to prevent different cities being specified as the origin city of the first or only outgoing flight and the destination city of the last or only return flight, or different passengers on different flights, there is no need for operative rule statements such as RS184 to RS186.  That, I think, puts the cart before the horse.  The rules come first and forms should be designed to enforce as many rules as possible.  The fact that a form enforces a rule does not mean that the rule no longer needs to be documented.

The question still remains:  do we need the corresponding definitional rule statements as well as the operative rule statements?  If your focus is solely on documenting an online booking form, then only the operative rule statements are required.  If your focus is on documenting the concepts and terms used by the organisation and the meanings of those concepts and terms, then definitional rule statements are a means of doing that, as described in the previous article.[3]

The role of the time dimension in rules

And now for something completely different!  Time can play various roles in rules.

Rules governing when something happens

Firstly, there are rules that govern when some event, activity, or process is obliged or permitted to occur (or prohibited from occurring).  For example we’ve already encountered rules that govern check-in and boarding times, such as RS96, RS102, and RS100 (reproduced here):

RS96. Each passenger must check in no later than 30 minutes before the departure time of the first or only outgoing flight specified in each flight booking confirmation if that flight is domestic.
RS102. Online check-in for a flight may occur only during the 24 hours before the departure time of that flight.
RS100. Each passenger must board the flight for which that passenger has checked in no later than 15 minutes before the departure time of that flight.

Rules governing statements about when something is to happen

Related to these are rules governing dates or times of events specified in requests for something to happen.  Again we’ve already encountered rules that govern the departure date and return date specified in flight booking requests (RS19 and RS20, reproduced here) and the departure times of flights specified in flight booking confirmations (there are many of these, of which RS87 and RS90, also reproduced here, are just a sample). 

How do these differ from the three rules reproduced above?  The difference is subtle but significant:  the intention of both classes of rule is to prevent something happening later than can be safely accommodated (and, in the case of RS102, earlier than is appropriate).  The difference with the rules reproduced below is that they deal with a person’s stated intention:  to fly on a particular day at a particular time.  These rules prohibit someone from stating the intention to do something that is impossible, impractical, prohibited, or in the past, whereas those reproduced above simply prohibit someone from doing such a thing.

RS19.  The departure date specified in each flight booking request must be no earlier than today.
RS20.  The return date (if any) specified in each flight booking request must be no earlier than the departure date specified in that flight booking request.
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.
RS90. The arrival time of each outgoing flight other than the last specified in each flight booking confirmation that specifies more than one outgoing flight must precede the departure time of the next outgoing flight specified in that flight booking confirmation by at least the minimum domestic transit time for the port at which those flights connect if no outgoing flight specified in that flight booking confirmation is international.

Rules governing statements about when something happened

If a system provides for recording of events after they have occurred, that system should similarly prohibit someone from stating that something has happened that is impossible, impractical, prohibited, or in the future.  For example, an airline may provide a facility whereby, if a flight previously made does not appear in your frequent flier statement, you can ask for that flight to be added, in which case the following rule would apply:

RS187. The departure date specified in each flight credit request must be earlier than today.

A digression:  the use of ‘today’

Two rule statements in this article use the word ‘today’.  What does ‘today’ mean in these rule statements?  It is not, of course, the day on which the rule statement is authored, but the day on which the stated rule is applied to each transaction. 

What if there is a requirement to retrospectively test transactions for compliance with rules?  If today I check a flight booking request made yesterday against RS19, it may have quite legitimately specified yesterday as the departure date but that is earlier than today.  To avoid confusion, some practitioners (myself included) prefer not to use ‘today’ but instead refer to the date on which the transaction occurs, as in RS188 (an alternative to RS19) and RS189 (an alternative to RS187):

RS188. The departure date specified in each flight booking request must be no earlier than the date on which that flight booking request is made.
RS189. The departure datespecified in each flight credit request must be earlier than the date on which that flight credit request is made.

Recording the history of a changing attribute or relationship

There is frequently a requirement to record the history of a changing attribute or relationship.  This is done for an attribute by recording the value of that attribute during each of a series of time periods.  For example, the status of a member of a frequent flier program may change over time, and the airline may record not only the current status of each member but previous statuses and the time periods in which those statuses applied.  A record of a changing relationship is maintained by recording the time period(s) with which each pair of entities is associated.  For example, each trackable aircraft component (such as an engine, tire, rudder assembly, etc.) may be installed on different aircraft over time.

The time periods in such records are generally represented using start and end dates (or effective and expiry dates).  There is an implicit rule that governs all such time periods, namely that the start date cannot be later than the end date.  Such a rule can be expressed as if it governs the start date, as in RS190, or as if it governs the end date, as in RS191.

RS190. The start date specified in each frequent flier member status record must be no later than the end date specified in that frequent flier member status record.
RS191. The end date specified in each frequent flier member status record must be no earlier than the start date specified in that frequent flier member status record.

Do we need both of these rule statements?  In fact not only do we not need both but it is incorrect to specify both rule statements, since a quality criterion of the rule book is that no two rules duplicate each other.  So we need only one of them, but each of them is equally correct, so which do we choose?  I’ve heard it suggested that the rule governing the end date should be retained in favour of the rule governing the start date, because users normally enter the end date after the start date.  But what if a transaction containing a valid start date/end date pair is subsequently updated by changing the start date to be later than the end date?  We need a rule to govern the start date too.

This dilemma is best resolved by a rule statement, such as RS192, which governs the combination of start date and end date.

RS192. The combination of start date and end date specified in each frequent flier member status record must be such that that start date is no later than that end date.

In fact, a start date and associated end date are not really separate data items but components of a complex data item defining a time period.

Other rules governing records of history

Where the history of a changing attribute or relationship is recorded, various rules may govern those historic records:

  1. There is usually a temporal data non-overlap constraint, a requirement that the time periods specified in the records relating to a given person or thing do not overlap each other, e.g.:
RS193. The time period specified in each frequent flier member status record must not overlap the time period specified in any other frequent flier member status record for the same frequent flier membership.
  1. There is usually also a temporal data completeness constraint, a requirement that the time periods specified in the records relating to a given person or thing are contiguous and between them completely span some other time period (in this case, the total period of membership of the member), e.g.:
RS194. Each day within the membership period specified in each frequent flier membership record must be within the time period specified in exactly one frequent flier member status record for the frequent flier membership recorded in that frequent flier membership record.

Note that the ‘exactly one’ determiner in this rule statement implies the corresponding non-overlap constraint.  If a non-overlap constraint does not apply but the completeness constraint does apply, the determiner ‘at least one’ should be used instead.

  1. There is usually also a temporal data inclusion constraint, a requirement that the time periods specified in the records relating to a given person or thing do not fall outside some other time period (in this case, the total period of membership of the member), e.g.:
RS195. Each day within the time period specified in each frequent flier member status record must be within the membership period specified in the frequent flier membership record for the frequent flier membership with which that frequent flier member status record is associated.
  1. A less obvious requirement raised in [4] arises from the fact that it is theoretically possible to create two records with two contiguous time periods and all other content identical.  For example, if Member #123 was assigned a new status both on 1 January 2010 and 5 April 2011, there should be a single status record for Member #123 that covers the period 1 January 2010 to 4 April 2011. 

There is, of course, nothing to stop us recording this situation using two otherwise identical Frequent Flier Member Status records covering the periods 1 January 2010 to 4 April 2010 and 5 April 2010 to 4 April 2011.  However, to do so causes a variety of problems, e.g., a query as to which members changed status in April 2010 would erroneously include Member #123.  Creation of such multiple records can be prevented by requiring (in this case) that a new status record only be created for a change of status, as in ‎RS196.  Date, Darwen, & Lorentzos refer to the presence of such multiple records as “circumlocution”; given the fact that these constraints require a temporal state of affairs to be recorded using a single record rather than multiple records, I refer to them as temporal single record constraints.

RS196. Each status specified in a frequent flier member status record must be different to the status specified in the latest of the earlier frequent flier member status records for the same frequent flier membership.

Time-dependent attributes

There are rules that govern time-dependent attributes or make permission dependent on a time-dependent attribute.  For example, we’ve already encountered various rules that make permission or obligation dependent on a passenger’s age, such as the following:

RS63. Each flight booking confirmation must specify exactly one escorting party at the destination city specified in that flight booking confirmation if every passenger specified in that flight booking confirmation is less than 12 years of age at the time of travel.
RS154. A person may travel alone only if that person is more than 2 years of age.
RS155. A person may obtain travel insurance only if that person is less than 71 years of age.

Note that RS154 and RS155 do not yet have the qualifying clause “at the time of travel”.  What are the implications of omitting that qualifying clause ?  Consider RS155:  someone approaching their 71st birthday and intending to travel after that birthday could apply for travel insurance to cover that journey.  Since the age restriction is based on assessment of the increased risk of claims from older passengers, the insurance company will base the acceptability of writing a policy on the age of the intending traveller at the intended time of travel; the fact that he or she is less than 71 years of age at the time they apply for the insurance is immaterial.

In fact, any rule statement referring to a time-dependent attribute should qualify the term signifying that attribute so as to make clear when the value of that attribute is to be tested by the rule, so RS154 and RS155 should be rewritten as follows:

RS154. A person may travel alone only if that person is more than 2 years of age at the time of travel.
RS155. A person may obtain travel insurance only if that person is less than 71 years of age at the time of travel.

To be continued...
In the next article, we will look at some templates to support time-related rules and revisit the way fact types provide a foundation for rule statements.

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 22)," Business Rules Journal, Vol. 12, No. 8 (Aug. 2011), URL:  http://www.BRCommunity.com/a2011/b611.html  return to article

[4]  Date, C. J., Darwen, H., & Lorentzos, N. A. (2003). Temporal Data and the Relational Model. San Francisco, CA, USA: Morgan Kaufman. return to article

# # #

Standard citation for this article:


citations icon
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

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
 Silvie  Spreeuwenberg
 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.