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 data rule,^[4] which fall into three broad categories:

1. data cardinality rules:  rules that require the presence or absence of a data item and/or place a restriction on the maximum or minimum number of occurrences of a data item), e.g., RS16

2. data content rules:  rules that place restrictions on the values contained in a data item or set of data items (rather than whether or not they must be present and how many there may or must be), e.g., RS61

3. data update rules:  rules that either prohibit update of a data item or place restrictions on the new value of a data item in terms of its existing value, e.g., RS131

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.

For the next few articles, we will be looking at rules other than data rules, starting with process rules.  But before we look at them, I would like to discuss complex data types, which provide a useful means of keeping rule statement proliferation under control.

Complex data types:  an example

Many websites, user interfaces or messaging environments require various addresses to be specified.  For example, an online ordering site will require a delivery address and a billing address (although these may be the same).  These addresses will generally be subject to the same data rules, e.g.,

An alternative method of expressing these rules is by:

1. defining a complex data type such as Street Address and specifying just once each rule with which instances of that data type must comply
   
   
2. defining the individual complex data items (Delivery Address and Billing Address) in terms of the complex data type (Street Address).

The following rule statements illustrate this alternative method:

Note that this method uses only seven rule statements rather than ten; furthermore, each of the rule statements RS144 – RS148 is simpler than the corresponding original rule statements (RS134 – RS143).  A recent business rules project involved at least ten transaction types, specifying between them a total of sixteen address data items.  The standard address data structure in this project was more complex, requiring nine rule statements for each address.  Using the original method, 144 rule statements were required (16 x 9) whereas the alternative method required only 25 rule statements (16 + 9).

The rule statements governing the complex data type (RS144 – RS148) are of the same types as those they replace (RS134 – RS143), in this case 4 mandatory data item rule statements and 1 value set rule statement, differing only in the use of the verb include rather than specify.  The rule statements that define complex data items in terms of complex data types (RS149 – RS150) are data item format rules.

Of course, while a delivery address must be a street address, a billing address can be any postal address:  a street address or a post office box address.  Post office box addresses differ from street addresses in that a post office box number is required rather than a street number and name.  There are two ways to define these requirements:

1. Define the complex data type Post Office Box Address in addition to Street Address, allow a Delivery Address to be only a Street Address, and allow a Billing Address to be a Street Address or a Post Office Box Address, using the following rule statements in addition to RS144 – RS148:

2. Define the complex data type Postal Address in addition to Street Address, allow a Delivery Address to be only a Street Address, and allow a Billing Address to be any Postal Address, using the following rule statements in addition to RS144 – RS148:

Note that a Postal Address is either a Street Address or a Post Office Box Address.

Other complex data types

Most websites, user interfaces or messaging environments require personal names to be specified.   For example, when booking travel or taking out travel insurance, the name of each passenger must be stated.  Each name must include a Title (e.g., Mr, Ms, Dr), a First Given Name, and a Family Name.^[5]  This can be achieved using either:

1. RS165 – RS167 (which govern the individual components of a personal name to be supplied in a transaction) or

2. RS168 – RS171 (which define Personal Name as a complex data type)

While the second approach uses four instead of three rule statements, it pays off if there are many different transactions in which personal names are required; each additional transaction requires one additional rule statement rather than three.

Other complex data types are:

1. An Effective Time Period or Lifespan is made up of a start date (or effective date) and an end date (or expiry date).
   
   
2. A Share Fraction, such as 1/3 or 2/7, is made up of a numerator and a denominator.^[6]

Impact on rule statement patterns

The rule statement patterns defined in earlier articles in this series require only minor adjustment:

1. the addition of include as an alternative to specify
   
   
2. the recognition that data rule statements can govern complex data types as well as transactions.

The revised patterns are:

To be continued...
The next article in this series will take a look at process rules.

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  

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

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

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

[5]  Many websites ask for First Name and Last Name rather than First Given Name and Family Name.  If the only purpose is to reproduce the person's name in full (e.g., "Mr Graham Witt") this is sufficient, but "last name" is often a surrogate for family name.  For example, correspondence may be addressed "Dear Mr Witt".  This is OK if the customer's culture is one in which the family name comes last, as in the English-speaking world, but not if that culture is one in which the family name comes first, as in many Asian and Eastern European cultures.  Of course, a customer from such a culture may realise the business's intent and reverse their family name and first given name, but there is no guarantee that every such customer will do so, and data quality is compromised.  Inclusion of a Patronymic data item provides for more inclusive capture of personal names, as it covers those cultures, such as Icelandic, in which patronymics (e.g., Jónsson or Jónsdóttir) are used instead of family names.  

[6]  Where an asset has shared ownership, vulgar fractions must be used rather than percentages since the shares resulting from dividing something equally between 3 or 7 parties (or indeed any number of parties that is not a power of 2 multiplied by a power of 5) cannot be expressed exactly as a percentage or decimal fraction.  

# # #