Writing Natural Language Rule Statements — a Systematic Approach Part 19: Some Definitional Rules in Detail

Graham   Witt
Graham Witt Consultant / Author Read Author Bio || Read All Articles by Graham Witt
About this series of articles

While my first series of articles on writing natural language rule statements[1] explored a wide variety of issues in a rather organic and hence random manner, this series takes a more holistic and systematic approach and draws on insights gained while writing my recently-published book on the same topic.[2]  Rule statements recommended in these articles are intended to comply with the Object Management Group's Semantics of Business Vocabulary and Business Rules (SBVR) version 1.0.[3]

The story so far

In previous articles in this series (see the "Language Archives" sidebar) we have looked at standardised rule statements for various types of operative rules:[4]  data rules,[5] activity rules,[6] and party rules.[7]  Each specific type of rule statement has a common formulation, which we have discussed in both a relatively informal way and by way of rule statement patterns.

In this article, we will look at the various forms that rule statements for definitional rules[8] can take.  You may recall that, in the previous article in this series,[9] I proposed that such statements should be distinguished from operative rule statements by the former's use of the phrase "by definition" after the subject of the rule statement.  First though let's review the various types of definitional rule.

Types of definitional rule

Definitional rules can be categorised as:

  1. formal term definitions, which define business terms formally.

  2. categorisation scheme enumerations, which define members of categorisation schemes.

  3. category transition constraints, which define constraints on the transitions between categories in a categorisation scheme.

  4. valid value definitions, which define the valid values of measures.

  5. standard format definitions, which define standard formats for data items.

  6. data calculation rules, which define algorithms or formulae for named quantities or conversion factors between units.

  7. complex concept structure rules, which define constraints on the components of complex concepts.

Formal term definitions

A formal term definition defines a particular business term in a formal manner:

  1. A formal intensional definition defines the subject business term using an intensional definition: one that cites both a hypernym (a term that signifies a superset of the set signified by the original term) and the characteristics that distinguish members of the set signified by the original term, e.g.,
RS233. A senior passenger is by definition
a passenger whose age is at least 70 years at the time of travel.
RS234. An infant passenger is by definition
a passenger whose age is less than 2 years at the time of travel.
RS235. An employer of a person is by definition
an organisation that employs that person.
RS236. An employee of an organisation is by definition
a person who is employed by that organisation.
RS237. A sister of a person is by definition
a female person who has the same parents as the first person.
  1. A formal extensional definition defines the subject business term by using an extensional definition:  one that lists a complete set of hyponyms (terms that signify subsets of the set signified by the original term), e.g.,
RS238. An immediate family member of a person is by definition
a parent, sibling, spouse, or child of that person.
  1. A symbolic literal definition defines the subject business term using one or more literals, e.g.,
RS239. End of financial year is by definition
June 30.[10]
RS240. A calendar year is by definition
365 days or 366 days from any January 1 to the next December 31.
RS241. Close of business is by definition
5pm.
RS242. Christmas Day is by definition
December 25.

One question that is often put to me is "why do we need formal term definitions?" since the business glossary or fact model should contain the definitions of all terms.  However, there is no redundancy if you consider formal term definitions to be merely renderings of (<term>, <definition>) pairs in the form "A <term> is by definition <definition>."  In fact, an important role for such definitions (whether they reside in the business glossary or fact model or as rule statements) is to reduce redundancy.  For example:

  1. There may be multiple rule statements that refer to the close of business each day, and there is the possibility that that closing time may change.  If each of those rule statements refers explicitly to 5pm, each of them would need to be changed, whereas if each of those rule statements refers to close of business, only rule statement RS241 needs to be changed.

  2. There may be multiple rule statements that restrict parties to transactions to immediate family members of a person, and there is the possibility that the definition of immediate family member might change.  If each of those rule statements refers explicitly to the list of related persons, each of them would need to be changed, whereas if each of those rule statements refers to immediate family member, only rule statement RS238 needs to be changed.

Categorisation scheme enumerations

A categorisation scheme enumeration defines the members of a categorisation scheme that is both mutually exclusive (i.e., no individual object can be a member of more than one category in the categorisation scheme) and jointly exhaustive (i.e., each member of the class with which the categorisation scheme is associated belongs to a category in the categorisation scheme).

One way of expressing this type of rule is in terms of subsets of the categorised term, by way of a rule statement very similar to that of a formal extensional definition (already discussed above), e.g.,

RS243. A person is by definition
either an adult or a minor.
RS244. A payment is by definition
one of the following: a cash payment, a credit card payment, or an electronic funds transfer payment.
RS245. A flight is by definition
either a domestic flight or an international flight.
RS246. A journey is by definition
one of the following: a one-way journey, a return journey, or a multi-stop journey.

The difference between these rule statements and formal extensional definition statements is because the categories listed in these rule statements are mutually exclusive (whereas those in formal extensional definition statements do not have to be).

Another way of expressing this type of rule is in terms of allowed values of a category attribute, e.g.,

RS247. The gender of a person is by definition
either male or female.
RS248. The status of an employee is by definition
one of the following: probational, permanent, or temporary.

One use of categorisation scheme enumeration statements of the second type (e.g., RS247 and RS248) is as a Source of Truth for value set rules, such as:

RS249. The status specified in each employee record update
must be one of the following: probational, permanent, or temporary.

This situation (the co-existence of RS248 and RS249) prompts the question "do we need both?"  I find that if there are multiple rules governing specification of a category attribute in different circumstances, verifying value set rule statements against a single categorisation scheme enumeration statement such as RS248 is easier and less error-prone than comparing with other value set rule statements, particularly as some of the latter may demand only a subset of the possible categories.

An important function of categorisation scheme enumeration statements of the first type (e.g., RS243 – RS246) is to support quality assurance of rule statements.  For example, since domestic flight and international flight are the only subtypes of flight, "for a domestic flight or international flight" is redundant in:

RS250. A flight booking request for a domestic flight or international flight
must specify exactly one departure date.

By contrast, since return journey and multi-stop journey are not the only subtypes of journey, "for a return journey or multi-stop journey" is not redundant in:

RS251. A flight booking request for a return journey or multi-stop journey
must specify exactly one return date.

Further, since one-way journey, return journey, and multi-stop journey are the only subtypes of journey, RS252 is logically equivalent to RS251:

RS252. A flight booking request for other than a one-way journey
must specify exactly one return date.

Category transition constraints

A category transition constraint specifies allowed or disallowed transitions between categories or statuses.  For example, if we only allow the values never married, married, widowed, and divorced for the marital status attribute,[11] only the following transitions are possible:

  • never married to married but not vice versa
  • married to widowed and vice versa
  • married to divorced and vice versa.

This state of affairs could be expressed using the following rule statements:

RS253. A transition of the marital status of an employee from married to never married
    is by definition impossible.
RS254. A transition of the marital status of an employee from never married to widowed
    is by definition impossible.
RS255. A transition of the marital status of an employee from never married to divorced
    is by definition impossible.
RS256. A transition of the marital status of an employee from widowed to never married
    is by definition impossible.
RS257. A transition of the marital status of an employee from divorced to never married
    is by definition impossible.

The inference to be drawn from this set of statements is that any other transitions are possible.  Alternatively, of course, one could list the five possible transitions, with the inference that any other transitions are impossible.

A better alternative is to define the circumstances in which transition to or from a particular status is possible, as in the following rule statements:

RS258. A transition of the marital status of an employee to never married
    is by definition impossible.
RS259. A transition of the marital status of an employee to widowed
    is by definition possible only if the marital status of that employee is married.
RS260. A transition of the marital status of an employee to divorced
    is by definition possible only if the marital status of that employee is married.

Constraints such as this document our understanding of the real world in which the organisation operates rather than the data it uses to record that real world.  For example, if we record the marital status of employees, you might think that there is a state transition constraint (as described in Part 12[12] in this series) corresponding to each of the rule statements RS258 – RS260.

However, data may be incomplete or not up to date.  This means that:

  • an additional unknown data value is required, and
  • a direct transition from never married to widowed or divorced is possible for employees who have not notified their employers that they have married but have then notified those employers of their subsequent change of status.

Therefore, while there is a state transition constraint (RS132) corresponding to RS258, there are no state transition constraints corresponding to RS259 or RS260.

RS132. The marital status of an employee
may be updated to never married
only if the marital status that is currently recorded for that employee
     is unknown.

Valid value definitions

A valid value definition defines the valid values of a particular measure, as a range or (occasionally) as a list of discrete values, e.g.,

RS261. pH is by definition
at least 0 and at most 14.

One use of this type of definitional rule statement is as a Source of Truth for range rules, such as:

RS262. The pH specified in each water sample analysis must be at least 0 and at most 14.

While 0 – 14 is the absolute range of possible values for pH, reasonable ranges for water samples from the environment are considerably narrower:  for example, 4.3 – 6.3 for precipitation (rain water), 6 – 8 for "streams" (rivers and other inland watercourses), 7.5 – 8.4 for seawater.  This presents us with a dilemma, since the occasional sample may exhibit pH values outside these ranges, so rule statements such as the following are not strictly correct:

RS263. The pH specified in each rainwater sample analysis must be at least 4.3 and at most 6.3.[13]
RS264. The pH specified in each stream water sample analysis must be at least 6 and at most 8.
RS265. The pH specified in each seawater sample analysis must be at least 7.5 and at most 8.4.

The SBVR uses the concept of enforcement level (or level of enforcement) as a property of operative rules to distinguish between those that are strictly enforced (cannot be violated without consequence in any circumstance) and those for which violations are allowed (with different enforcement levels defining different actions to be taken in the event of a violation).  While RS262 should be strictly enforced, violations of RS263 – RS265 should be catered for, in such circumstances as extreme environmental conditions, faults in measuring equipment, or errors in analysis.

However, the co-existence of rule statements RS262 – RS265 presents us with a further dilemma.  Each of RS263 – RS265 implies RS262, so if the rule book is to be non-redundant (which it should be) RS262 should be removed.  Yet there still ought to be a rule preventing pH values outside the absolute range from being entered in any circumstance.

In situations such as this, business stakeholders often suggest we replace 'must' by 'should' in rule statements RS263 – RS265.  However, whereas 'must' can be taken to imply that some standard error handling occur when a non-compliant value is supplied, it is not clear what should happen when data doesn't comply with a 'should' rule statement.

My question to stakeholders in such situations is therefore "what should happen if a value outside the relevant reasonable range is supplied?"  Initially the answer is that there should be a message from the system receiving the data, along the lines of "are you sure?"  I then suggest that the user should not simply reply "yes" to the "are you sure?" message, but supply additional information to support the out-of-range value.  This allows verification of this data to be managed with rule statements such as the following:

RS266. Each rainwater sample analysis
must specify an out-of-range reason
if the pH specified in that rainwater sample analysis is less than 4.3 or more than 6.3.
RS267. Each stream water sample analysis
must specify an out-of-range reason
if the pH specified in that stream water sample analysis is less than 6 or more than 8.
RS268. Each seawater sample analysis
must specify an out-of-range reason
if the pH specified in that seawater sample analysis is less than 7.5 or more than 8.4.

These rule statements replace RS263 – RS265, but RS262 is retained.

To be continued...
The next article in this series will look at the remaining types of definitional rule, as well as patterns for all definitional rule statement types.

References

[1]  The first of which is:  Graham Witt, "A Practical Method of Developing Natural Language Rule Statements (Part 1)," Business Rules Journal, Vol. 10, No. 2 (Feb. 2009), URL:  http://www.BRCommunity.com/a2009/b461.html  return to article

[2]  Graham Witt, Writing Effective Business Rules.  Morgan Kaufmann (2012).  return to article

[3]  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/
     The font and colour conventions used in these rule statements 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, these conventions are not used for rule statements that exhibit one or more non-recommended characteristics.  return to article

[4]  A rule that states what must or must not happen in particular circumstances, and which can therefore be contravened, by contrast with a definitional rule.  return to article

[5]  A rule that constrains the data included in a transaction (a form or message) or a persistent data set (e.g., a database record).  return to article

[6]  A rule that constrains the operation of one or more business processes or other activities.  return to article

[7]  A rule that makes a distinction between different parties or the roles they play.  return to article

[8]  A rule that defines a construct created or used by an organisation (or the industry within which it operates), or defines a property of such a construct, and which cannot therefore be contravened, by contrast with an operative rule.  return to article

[9]  Graham Witt, "Writing Natural Language Rule Statements — a Systematic Approach — Part 18:  Operative and Definitional Rules," Business Rules Journal, Vol. 15, No. 1 (Jan. 2014), URL: http://www.BRCommunity.com/a2014/b740.html  return to article

[10]  This is the case in Australia; other dates apply in other countries.  return to article

[11]  I have omitted the de facto and separated values to simplify the discussion, as treatment of these values varies according to jurisdiction.  return to article

[12]  Graham Witt, "Writing Natural Language Rule Statements —a Systematic Approach —Part 12:  Spatial Data Constraints, Data Update Rules," Business Rules Journal, Vol. 14, No. 6 (June 2013), URL: http://www.BRCommunity.com/a2013/b707.html  return to article

[13]  Any rule statement that is marked with an initial dagger is, for one or more reasons, not recommended; in this case a preferred alternative will also be shown.  return to article

# # #

Standard citation for this article:


citations icon
Graham Witt , "Writing Natural Language Rule Statements — a Systematic Approach Part 19: Some Definitional Rules in Detail" Business Rules Journal Vol. 15, No. 2, (Feb. 2014)
URL: http://www.brcommunity.com/a2014/b745.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

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.