Writing Natural Language Rule Statements — a Systematic Approach Part 20: More 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 earlier 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 the previous article[8] we looked at the various forms that rule statements for certain types of definitional rule[9] can take.  In this article we will look at the remaining types of definitional rule, as well as patterns for all definitional rule statement types.

Standard format definitions

A standard format definition defines the standard format for data items of a particular type in terms of individual characters and/or component data items, e.g.,

RS269. A valid airline code is by definition
composed of exactly two letters or digits.[10]
RS270. A valid flight number is by definition
composed of a valid airline code followed by up to four digits.

This type of rule statement can be used in conjunction with data item format rule statements[11] (described in Part 11 of this series).[12]  For example, rule statement RS114 in that article constrained a particular phone number data item in a particular transaction:

RS114. The contact phone number (if any) specified in each travel insurance application
must be a valid Australian personal phone number.

In that article it was also stated that all personal phone numbers in Australia — mobile (cell) or landline — are 10 digits in length, and the first digit of each personal phone number is 0, while the second digit is (currently) 2, 3, 7, or 8 for fixed phones and 4 for mobile phones.  This can be documented as in rule statement RS271:

RS271. A valid Australian personal phone number is by definition
composed of:
"0" followed by
"2", "3", "4", "7", or "8" followed by
eight digits.

Note:

  1. Without the separate bulleted lines, RS271 looks like RS272, which is somewhat ambiguous:  one (admittedly implausible) interpretation of RS272 is that the options are "02", "3", "4", "7", or "8" followed by 8 digits.

  2. There is a US punctuation rule that applies to quoted text that would place the commas in the 4th line of RS271 before the closing double quotes, as in RS273.  However, this makes it unclear what characters the allowed strings actually contain (they certainly don't contain final commas!).  Rule statements must be exempt from this punctuation rule in the same way that programming language statements are.
RS272. A valid Australian personal phone number is by definition
composed of "0" followed by "2", "3", "4", "7", or "8" followed by eight digits.[13]
RS273. A valid Australian personal phone number is by definition
composed of:
"0" followed by
"2," "3," "4," "7," or "8" followed by
eight digits.

You might be tempted to ask why we don't replace RS114 and RS271 by RS274.  After all, the fewer rule statements the better!  However, systems typically record phone numbers in numerous places, each of which is subject to the same constraint.  When new phone numbers are issued (or extra digits added, as has happened more than once in Australia in the last 50 years), a dozen or so rule statements like RS274 would be more difficult to maintain than one like RS271.

RS274. The contact phone number (if any) specified in each travel insurance application
must be composed of:
"0" followed by
"2", "3", "4", "7", or "8" followed by
eight digits.

Data calculation algorithms

A data calculation algorithm defines how a particular quantity or amount (whether for operational purposes, such as a fee, or for business intelligence purposes, such as a performance measure) is calculated, e.g.,

RS275. The extension for an order line is by definition
calculated as the product of:
the order quantity for that order line,
the nett unit price for that order line, and
1 minus the discount rate for that order line.
RS276. The year-to-date sales total for a product on a date is by definition
calculated as the sum of the extension for each order line for that product that:
has an order date within the same calendar year as that date and
was not cancelled within the same calendar year as that date.

A frequent complaint from stakeholders in organisations with multiple systems is that the same calculated quantity has different values depending on where you look.  Inevitably in that situation I find that the calculation algorithm has been reinvented for each new system, sometimes more than once within a set of system specifications.  For example, year-to-date sales total may

  1. be based on calendar year (as in rule statement RS276) or financial year.

  2. take into account (as in rule statement RS275) — or not — any discounts on the unit price of goods sold.

  3. exclude (as in rule statement RS275) or include any sales tax or value-added tax payable by the customer.

The principal value of data calculation algorithms is to act as a single reliable Source of Truth of the method by which derived amounts and quantities are calculated in reports and user interfaces. 

Conversion factor definitions

A conversion factor definition defines a conversion factor between two units of measurement, e.g.,

RS277. 1ft is by definition
equal to 12in.
RS278. 1in is by definition
approximately equal to 2.54cm.

These may be of use if a system has to deal with multiple units for the same type of quantity.  For example, real estate registration systems in Australia not only receive land areas in square metres or hectares depending on the size of the land parcel, but also need to deal with parcels last transferred before metrication, the land areas of which are recorded in acres.

Complex concept structure rules

Most concepts that (in data modelling terms) are attributes of entities — such as gender, age and marital status — can be considered as simple in that they have no structure.  However, most business concepts are complex; they have structure.  The components making up the structure of a complex concept include its attributes, its relationships with other concepts, and its sub-structures (such as the order lines of an order or the flights in a booking), which in turn have structure.

A complex concept structure rule defines a particular constraint on one or more components of a complex concept.  These rules are analogous to data rules, as we shall see.

  1. A complex concept cardinality rule defines the number of (or minimum and/or maximum number of) components of a particular type within a particular concept, e.g.,
RS279. A flight has by definition
exactly one destination port.

These correspond[14] to data cardinality rules described in Parts 2 and 3 of this series,[15] e.g.,

RS280. A flight booking
must specify exactly one destination port.

The distinction between these two rules is that while it is impossible for a flight not to have a destination port, it is possible for a flight booking not to specify one (although such an omission has consequences, such as the rejection of that transaction until a destination port has been specified).

  1. A complex concept (in)equality rule identifies components within a particular concept that are necessarily the same or different, e.g.,
RS281. The destination city of a journey is by definition
different to the origin city of that journey.
RS282. 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.[16]
RS283. 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.
  1. A complex concept set constraint imposes constraints on sets of components within a particular concept, e.g., they must be identical or different.
RS284. The set of passengers
    booked on each flight in a flight booking confirmation
    is by definition
the same as the set of passengers
    booked on each other flight in that flight booking confirmation.

The principal value of complex concept structure rule statements is to document our understanding of the data structures underlying complex concepts, as much as anything to ensure that user interfaces and message formats correctly handle those concepts.  For example, if rule statements RS282 and RS283 are not true, a user interface or standard message providing for recording of return journeys must allow for more than two cities.  Similarly, if RS284 is not true, a user interface or standard message providing for flight bookings must allow for the possibility of different passengers on each flight.

Definitional rule statement patterns

Each type of definitional rule statement has a pattern:

P54. 

<formal intensional definition statement> ::=
A <term> {of a <term> |} is by definition
a <term> <qualifying clause>
.

P55. 

<formal extensional definition statement> ::=
A <term> {of a <term> |} is by definition
a <or term list> {of that <term> |}
.

P56. 

<symbolic literal definition statement> ::=
{A |} <term> {of a <term> |} is by definition
<literal> {or <literal> |} {<qualifying clause> |}
.

P57. 

<categorisation scheme enumeration statement> ::=
A <attribute term> {{of | for} a <entity term> |} is by definition
{either {a <term> or a <term> | <literal> or <literal> |
one of the following: {a <or term list> | <or literal list>}
.

P58. 

<category transition constraint statement> ::=
A transition of the <attribute term> {of | for} a <entity term> to <literal> is by definition
{impossible | possible only if <conditional clause>}
.

P59. 

<valid value definition statement> ::=
{The |} <attribute term> {{of | for} a <entity term> |} is by definition
{at least <literal> | at most <literal> | at least <literal> and at most <literal>}
.

P60. 

<standard format definition statement> ::=
A valid <attribute term> {{of | for} a <entity term> |} is by definition
composed of <format definition>
.

P61. 

<data calculation algorithm statement> ::=
The <attribute term> {{of | for} a <entity term> |} is by definition
calculated as <calculation definition>
.

P62. 

<conversion factor definition statement> ::=
<literal> is by definition
{approximately |} equal to <literal>
.

P63. 

<complex concept cardinality rule statement> ::=
A <concept term> <verb phrase> by definition
{exactly | at least | at most} <cardinal number> <component term>
    {{for | in} {the | each} <sub-structure term> |}
.

P64. 

<complex concept (in)equality rule statement> ::=
The <component term> {<prepositional phrase> |} {of | in} a <concept term> is by definition
{the same as | different to}
    the <component term> {<prepositional phrase> |} {of | in} that <concept term>
.

P65. 

<complex concept set constraint statement> ::=
{Each | The} set of <component term>
    {<qualifying clause> |} {of | in} a <concept term>
is by definition
{the same as | different to} the set of <component term>
    {<qualifying clause> |} {of | in}
that <concept term>
.

Note that these patterns (and the others that have been described in previous articles in this series) involve various syntactic components that are yet to be defined in detail:

  1. <qualifying clause>, e.g.,

    1. for that order line

    2. within the same calendar year as that date

    3. booked on each flight in a flight booking confirmation

  2. <or term list>, e.g.,

    1. a parent, sibling, spouse, or child

  3. <literal>, e.g.,

    1. June 30

    2. 365 days

    3. 5pm

    4. male

    5. "0"

    6. 14

    7. 1ft

  4. <conditional clause>, e.g.,

    1. the marital status of that employee is married

    2. has an order date within the same calendar year as that date and
      was not cancelled within the same calendar year as that date

  5. <format definition>, e.g.,

    1. exactly two letters or digits

    2. a valid airline code followed by up to four digits

    3. "0" followed by
      "2", "3", "4", "7", or "8" followed by
      eight digits

  6. <calculation definition>, e.g.,

    1. the product of:
      the order quantity for that order line,
      the nett unit price for that order line, and
      1 minus the discount rate for that order line

  7. <cardinal number>, e.g.,

    1. one

    2. two

    3. four

    4. eight

  8. <prepositional phrase>, e.g.,

    1. of the last or only return flight

    2. of the first or only outgoing flight

All of these syntactic components will be defined in detail in a subsequent article in this series.

To be continued...
Having now covered most if not all of the rule types you are likely to encounter, I shall in the next article move to a discussion of the syntax of rule statements in general and the various syntactic components that can be used to build a rule statement.

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

[9]  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

[10]  The official term for this concept within the airline industry is 'IATA airline designator'.  Note that the majority of airlines use 2-letter codes, but codes with digits have been assigned to some smaller airlines.  return to article

[11]  A statement of a rule that specifies the required format of a data item.  return to article

[12]  Graham Witt, "Writing Natural Language Rule Statements — a Systematic Approach — Part 11:  Data Item Format Rules," Business Rules Journal, Vol. 14, No. 5 (May 2013). URL:  http://www.BRCommunity.com/a2013/b703.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

[14]  Similarly the categorisation scheme enumerations and valid value definitions described in the previous article correspond to value set rules and range rules described in earlier articles in this series.  return to article

[15]  Graham Witt, "Writing Natural Language Rule Statements — a Systematic Approach — Part 2:  Mandatory Data Rules," Business Rules Journal, Vol. 13, No. 8 (August 2012). URL:  http://www.brcommunity.com/a2012/b665.html and
Graham Witt, "Writing Natural Language Rule Statements — a Systematic Approach — Part 3: Other Data Cardinality Rules," Business Rules Journal, Vol. 13, No. 9 (Sept. 2012). URL:  http://www.brcommunity.com/a2012/b669.html  return to article

[16]  Journeys for which this is not the case are referred to as multi-stop journeys rather than return journeys.  return to article

# # #

Standard citation for this article:


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