What is this series of articles about?

This is the twenty-second 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 an online "Book Flights" facility provided by an airline.  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 identifying 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.

Why definitional rules?

I recently received correspondence from a reader in response to some earlier articles in this series.  Rob van Haarst of USoft™ made a number of thought-provoking observations about various aspects of natural language rule statements, including a discussion of definitional (structural) rules.  These have prompted me to explain my thinking with respect to definitional rules, both by comparison with operative rules and by comparison with definitions.

To set the scene, we first need to consider the role of terms and definitions in the enterprise.

Terms and definitions

To operate effectively in its environment, the enterprise needs an agreed term with which to refer to each object of interest.  In turn, each of those terms requires an unambiguous and correct definition.

An unambiguous definition enables a person (or system) to establish consistently for each object encountered or considered whether or not that object is covered by that definition (and is therefore covered by the term thus defined).  For example, if we were to define senior passenger as "a passenger whose age is at least 70 years", it is not clear whether someone whose 70th birthday falls between the date of booking a journey and the journey itself would be classified as a senior passenger.  This definition is therefore ambiguous, whereas "a passenger whose age is at least 70 years at the time of travel" resolves that ambiguity.

A correct definition should not lead anyone to make any false inferences as to whether the term covers a particular object.  For example, if I were to define the term vertebrate as "an animal with four legs" someone unfamiliar with vertebrates could reasonably infer that birds and primates (each with only two legs) and snakes (with none) are not vertebrates.  Similarly, if I were to define the term bird as "an animal that flies" someone unfamiliar with birds could reasonably infer that penguins are not birds but bats are.  The first definition leads to false exclusion, the second to both false exclusion and false inclusion.

Each definition should be either intensional or extensional.  An intensional definition is one that cites both a hypernym (a term that refers to a superset of the set referred to by the original term) and the characteristics that distinguish members of the set referred to by the original term, e.g., "a passenger whose age is less than 2 years at the time of travel" as a definition of infant passenger.  An extensional definition, by contrast, is one that lists a complete set of hyponyms (terms that refer to subsets of the set referred to by the original term), e.g., "a person or organisation" as a definition of party.

Each of these types of definition uses other terms.  Clearly, unless we create circular definitions (in which, for example, we define a in terms of b, b in terms of c, and c in terms of a), we will need at least some axiomatic definitions (those that involve only terms that require no definition).  Ideally, you would create a small number of concepts at the top of your taxonomy of terms, each with an axiomatic definition, and define every other term using an intensional definition.  This removes the risk of circular definitions, which might occur if you were to employ a mix of intensional and extensional definitions.  There are, however, two situations in which extensional definitions are useful:

1. in defining a top-level term that is more difficult to define axiomatically than each of its hyponyms.  The classic example here is the term party, typically used as the hypernym of person and organisation, each of which is likely to be easier to define with an axiomatic definition;
   
   
2. in defining a term that signifies multiple concepts but does not fit into the taxonomy.  A typical example of such a term is immediate family member in that section of the taxonomy of terms that deals with a person’s relatives.  If parent, sibling, and child are hyponyms of blood relative, and spouse is a hyponym of relative by marriage, immediate family member (which covers all 4 of these) is thus a "re-grouping" of the terms in the taxonomy; it can be defined using the extensional definition "(of a person) a parent, sibling, spouse, or child of that person".

Note that in the last example I have started the definition with the phrase "(of a person)".  This is because the terms immediate family member, parent, sibling, spouse, and child are role terms, i.e., their meaning is not absolute but with respect to some other object.

Returning to our case study, how might we define the term flight?  When we consider the attributes and associations of any particular flight, we find that it:

1. operates daily or on the same specific days each week,
   
   
2. operates between the same two ports on each day of operation (possibly with intermediate stops),
   
   
3. departs and/or arrives at each port at the same time of day on each day of operation.

As a result we can define flight as "a service on which passengers can travel between particular ports that operates on the same days each week and that departs and/or arrives at each port at the same time of day on each day of operation".  We can then define international flight and domestic flight (hyponyms of flight) using intensional definitions as follows:

1. international flight:  "a flight in which the origin port and destination port are in different countries",
   
   
2. domestic flight:  "a flight in which the origin port and destination port are in the same country".

It should be clear that the meaning of a rule statement depends on the definitions of the terms used in that rule statement.  Depending on the toolset in use, it may be easy to navigate from rule statements to definitions of terms used.  However, experience has shown that it can be quite useful to have at least some term definitions recorded as definitional rule statements in the same set of rule statements as those using those terms.  The relevant definitions listed so far look like this when recast as definitional rule statements:

The Australian government agency to which I have been consulting has found a particular use for such definitional rule statements in the simplification of other rule statements.  This agency receives a variety of transaction types, and different rules apply to each.  However, it was found that many rules applied to the same three transaction types; for the sake of argument let us call them types T, TP, and CN.  Originally the relevant rule statements were each written using such forms as "Each transaction that is a type T transaction, type TP transaction or type CN transaction must …."  By introducing a new term (type X transaction, say), each of these rule statements could be simplified, e.g., "Each type X transaction must …."  The consensus was that, since type X transaction was an introduced term rather than an existing business term, it should be defined using a definitional rule statement rather than (or as well as) a definition in the structured business vocabulary.

The availability of this option raises such questions as:

1. Should all terms be defined using definitional rule statements?
   
   
2. If a term is defined using a definitional rule statement, should it also be given a definition in the structured business vocabulary?

Another question is whether the phrase 'by definition' adds any value.  I believe it does as it clearly distinguishes a definitional rule statement (which includes that phrase) from an operative rule statement (which includes either 'must' or 'may … only').  Omitting 'by definition' means that definitional rule statements can only be distinguished by the absence of 'must' or 'may … only'.

Whatever decisions your organisation makes, they should be consistent and promulgated to all rule statement and vocabulary creators.

Definitional and non-definitional properties

Each object of interest to an enterprise also has properties and associations of interest.  For example, a person has such properties as age, date of birth, and gender, and associations such as country of birth, citizenship, passport, and frequent flier membership.  While each of these except age is a property (or association) that applies only to persons, none of these would be particularly useful, alone or in combination, in a definition of person.  For example, "a party that has a date of birth" is unlikely to find much favour with business stakeholders as a definition of person.  However, as we have seen, age is a property that is of use in defining various types of passenger, such as senior passenger and infant passenger.

Cardinalities of properties and associations

What is important to record about every property (or association) of a class of objects is:

1. whether that property (or association) applies to all instances of that class of objects,
2. whether an instance of that class of objects can have more than one value of that property (or association).

For example, every person has a date of birth whereas not every person has an Australian passport.  No person can have more than one date of birth or Australian passport (these are thus singular properties or associations), but a person can have more than one citizenship (or none) and an organisation can have more than one trading name (but must have at least one) — these are thus multiple properties or associations.

The fact model does not allow us to record this information since fact types do not record cardinality:

By contrast, the following definitional rule statements record the relevant cardinalities:

Note that the citizenship cardinality (none, one or more than one) is unconstrained, which is why the rule statement for citizenship looks different.

Why is this useful?  When writing a rule statement that refers to such properties (or associations), we know we can use 'the' before a singular property or association, whereas we must use a determiner such as 'each' or 'one of the' before a multiple property or association.  For example, "the date of birth of that person", "at least one trading name of that organisation".  Similarly, after a property that does not necessarily apply to all instances, the phrase "(if any)" can be added, as in the "the Australian passport (if any) of that person".

Objects and information

The environment in which an enterprise operates includes:

1. phenomena in the world outside the enterprise but that are of interest to the enterprise, e.g.,  people, places, dates, and times;
   
   
2. constructs which the enterprise (or the industry in which it operates) creates for the purpose of conducting or describing its operations, such as flights, journeys, or bookings;
   
   
3. items of information created by employees or customers of (or suppliers to) the enterprise, to record events of interest to the enterprise:  examples of these are paper or online forms, structured and unstructured records, and reports produced automatically or manually.

Note that, while real-world phenomena and organisational constructs are governed by inviolable definitional rules (such as those discussed above), information may be incorrect or incomplete.  Information may be incomplete because it is not needed in a particular situation, or because it is needed but the supplier of the information has failed to provide all information needed.  For this reason, almost all rules governing information are necessarily operative (they can be violated).

Note that some rules governing real-world phenomena and organisational constructs are operative (e.g., persons may be prohibited from doing something, which some persons will do despite such prohibition).

It is important to realise that the rules governing real-world phenomena and organisational constructs may well be different to the rules governing information about those phenomena and constructs.  To illustrate this, consider dates of birth.

Every person has a date of birth.  While some enterprises may decide that they need to record the date of birth of every employee, others may decide otherwise.  An enterprise that does decide to record every employee's date of birth needs an operative rule to state that the date of birth must be recorded for every employee, while an enterprise that decides otherwise does not need such a rule.  Importantly, the physical world in which each of those enterprises operates is the same:  one in which every person has a date of birth.  The only difference lies in the presence or absence of a rule as to whether the date of birth must be recorded for every employee.  The rule statements involved are therefore RS177 (definitional) and RS178 (operative).

By the way, Version 1.0 of the SBVR proposes a different approach, involving multiple models (a "reality model" and an "in-practice model"), which I believe is unnecessarily complex.

The requirement to record date of birth may depend on circumstances.  For example, an insurance business may decide that it must collect the date of birth of each customer purchasing personal life insurance, so as to be able to calculate appropriate premiums.  If, however, a customer is only purchasing home insurance, the business does not need to collect his or her date of birth.  The business therefore needs an operative rule that requires that each customer provide his or her date of birth if purchasing personal life insurance:

These examples cover the situation in which something that is universal (a person's date of birth) does not always need to be recorded.  The reverse situation may also arise.  Not every person has a union membership expiry date but, if an organization employs only union members, every employee has a union membership expiry date.  Two operative rules characterize this situation:

Ensuring that data does not describe an impossible situation

An important class of rule statements ensures that data captured does not describe an impossible physical world situation.  Such situations include:

1. data specifying impossible values of physical properties, e.g., pH less than 0 or more than 14;
   
   
2. data specifying impossible transitions between values of a property of a person or thing, e.g., a person's transition from 'married' to 'never married';
   
   
3. data specifying impossible placement of persons or things, e.g., a person in more than one place at the one time, or a vehicle required to exceed a practical speed limit;
   
   
4. data specifying impossible sequences of events, e.g., a person's death occurring before his or her birth.

Let us consider further the first of these situations.  In the previous article^[3] we saw that a definitional rule can be used to limit the values of a particular physical property, as in RS165 (reproduced here):

Since that rule is definitional, it cannot be violated.  However, if data is being collected about the physical and chemical properties of water samples, it is necessary to prevent a user entering such data from entering a pH value that is outside that range.  To do so, an operative rule is also required:

Given that we need the operative rule statement RS166 to ensure data quality, do we also need the definitional rule statement RS165?  If your focus is solely on validating data inputs, you might choose to dispense with definitional rule statements.  However, as we have seen, they can be useful in a number of ways, including:

1. providing definitions for introduced terms,
   
   
2. describing the properties of the environment in which the enterprise operates.

To be continued...
In subsequent articles I’ll have more to say on definitional rules, introduce further templates to cover the range of definitional rule statements, and look at various other topics, such as the role of the time dimension in rules.

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  

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

[3]  Graham Witt, "A Practical Method of Developing Natural Language Rule Statements (Part 21)," Business Rules Journal, Vol. 12, No. 6 (Jun. 2011), URL:  http://www.BRCommunity.com/a2011/b603.html  

# # #