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]) and definitional rules.^[8]  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 next few articles, we will look at the syntax of rule statements in general, starting with data cardinality rule statements.^[9]

Review of data cardinality rule statements

In this series we have encountered various types of data cardinality rule statements:

1. mandatory data item rule statements,^[10] such as

2. mandatory option selection rule statements,^[11] such as

3. mandatory group rule statements,^[12] such as

4. prohibited data rule statements,^[13] such as

5. maximum cardinality rule statements,^[14] such as

6. multiple data rule statements,^[15] such as

7. dependent cardinality rule statements,^[16] such as

The anatomy of a data cardinality rule statement

You may recall from Part 7 of this series^[17] that data cardinality rule statements are operative rule statements, which are of three classes:

1. obligation statements, containing the keyword must, not immediately followed by not
   
   
2. prohibition statements, containing the keyword must, immediately followed by not
   
   
3. restricted permission statements, containing the keyword may and a conditional clause preceded by the keyword only.

There is an overarching pattern for each class of statement:

It can be seen that in each class of statement

1. the subject of the statement is everything between the initial determiner (Each, The, A, or An) and the keyword must or may.
   
   
2. there is a predicate (the form of which depends on the specific type of rule statement).
   
   
3. there may be a conditional clause following if, unless, or after (mandatory in the case of a restricted permission statement).

We shall look at each of these components of a data cardinality rule statement in turn.

The subject of a data cardinality rule statement

The subject of any data cardinality rule statement (except a dependent cardinality rule statement such as RS55) must be the term signifying the transaction in which a data item is required or prohibited.  If necessary, this term should be qualified by a qualifying clause, as described below under the heading Qualifying the subject of a data cardinality rule statement.

Each type of form (paper or on-screen) should be assigned an agreed term that signifies the transaction documented by the form (e.g., Leave Application, Order, or Flight Booking Request), and that term should be used as the subject in any data cardinality rule statement governing data in that form.

Similarly, each type of incoming message (which should either be a request for a service or a response from a service) should also be assigned an agreed term.  A good standard for terms signifying messages is to base them on the name of the service:

1. If the message is requesting a service, append the word 'request' to the service name, e.g., 'digital signature validation request'.
   
   
2. If the message is a response from a service, append the word 'response' to the service name, e.g., 'account details update response'.

The only exception (as indicated above) is the dependent cardinality rule statement (of which rule statement RS55 is an example); its subject is number of passenger names specified in each Flight Booking Confirmation.  Another example is RS56, in which the subject is number of advance seat requests specified for each flight in each Flight Booking Confirmation:

The subject of this type of rule statement consists of the following syntactic components in sequence:

• number of
• the term signifying the data item for which the cardinality is being defined, e.g., advance seat requests in RS56
• specified
• optionally a prepositional phrase identifying a complex data item (an object in a transaction for which more than one individual data item is specified), e.g., for each flight in RS56
• in each
• the term signifying the transaction or persistent data record in which the data item is required, e.g., Flight Booking Confirmation in RS56.

Qualifying the subject of a data cardinality rule statement

A data cardinality rule may not apply to all instances of a transaction, in which case a qualifying clause is required, to restrict the application of the rule.  For example in RS53 the qualifying clause that is for international travel is used to restrict the application of that rule statement to those types of Travel Insurance Application that are for international travel (rather than those for domestic travel).  Qualifying clauses will be discussed in more detail in a subsequent article.

The predicate of a data cardinality rule statement

Predicates of data cardinality rule statements take different forms depending on the type of rule being stated.

The predicate of a mandatory data item rule statement or multiple data rule statement consists of the following syntactic components in sequence:

• specify
• exactly or at least
• a cardinal number:
• one for a mandatory data item rule statement
• two, three, etc. for a multiple data rule statement
• a term signifying the data item in question, e.g., birth date, flights:
• singular for a mandatory data item rule statement
• plural for a multiple data rule statement
• if the data item is part of a complex data item (an object in a transaction for which more than one individual data item is specified, such as a passenger in a Travel Insurance Application), a prepositional phrase such as
• for each passenger
• for each high value item (if any)
• for the credit card
• in the postal address (if any).

A number of things should be noted about the prepositional phrase:

1. The determiner each is used if there can be more than one of the complex data item in the transaction, while the is used if there can only be one of the complex data item in the transaction.
   
   
2. The clause (if any) is used if and only if the complex data item is optional.
   
   
3. The term signifying the complex data item (if any) can be followed by a qualifying clause if necessary to restrict the application of the rule, as in:

Similarly, the predicate of a prohibited data rule statement or maximum cardinality rule statement consists of the following syntactic components in sequence:

• specify
• a suitable determiner:
• a for a prohibited data rule statement
• more than followed by a cardinal number (one, two, three, etc.) for a maximum cardinality rule statement
• a term signifying the data item in question, e.g., birth date:
• singular after a or one
• otherwise plural
• if the data item is part of a complex data item, a prepositional phrase such as
• for any passenger
• for any high value item
• for the credit card
• in the postal address (if any).

Note:

1. The prepositional phrase in a prohibited data rule statement uses any rather than each.
   
   
2. Where the complex data item is optional as well as multiple (there can be more than one in the transaction), (if any) is not needed after any.

The predicate of a mandatory option selection rule statement (such as RS287 and RS288) consists of the following syntactic components in sequence:

• specify
• if the data item is part of a complex data item, a prepositional phrase as in a mandatory data item rule statement or multiple data rule statement
• whether
• a conditional clause, such as that passenger is an adult passenger, a child passenger, or an infant passenger.

Note:

1. For easier comprehension, the prepositional phrase (if any) immediately follows specify rather than being at the end of the predicate as the conditional clause may be quite long.
   
   
2. Conditional clauses will be discussed in more detail in a subsequent article.

The predicate of a mandatory group rule statement (such as RS45, RS46, RS289, and RS290) consists of the following syntactic components in sequence:

• specify
• if the data item is part of a complex data item (as in RS290), a prepositional phrase as in a mandatory data item rule statement or multiple data rule statement
• one of:
• at least one of the following:, followed by a list of terms, each preceded by an indefinite article (a or an), the last pair separated by or (optionally preceded by a comma), and each other pair sped by a comma (as in RS45)
• exactly one of the following:, followed by such a list of terms (as in RS46)
• a pair of terms each preceded by an indefinite article, with or after the first term and but not both after the second (as in RS289)
• a pair of terms each preceded by an indefinite article, with a comma after the first term and or both after the second (as in RS290).

Again, for easier comprehension, the prepositional phrase (if any) immediately follows specify rather than being after the list of alternatives.

The predicate of a dependent cardinality rule statement is the same as that of a range rule statement, equality rule statement, or inequality rule statement.  These will be discussed in a subsequent article.

To be continued...
In the next article in this series we will look at the syntax of data content rule statements.

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 states what must or must not happen in particular circumstances, and which can therefore be contravened, by contrast with a definitional rule.  

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

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

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

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

[9]  Statements of rules that require the presence or absence of a data item and/or place restrictions on the maximum or minimum number of occurrences of a data item.  

[10]  Statements of rules that require that a particular data item be present.  

[11]  Statements of rules that require that one of a set of pre-defined options be specified.  

[12]  Statements of rules that require that at least one of a group of data items be present.  

[13]  Statements of rules that mandate the absence of some data item in a particular situation.  

[14]  Statements of rules that place an upper limit (usually but not necessarily one) on how many instances of a particular data item there may be.  

[15]  Statements of rules that mandate the presence of two or more instances of a particular data item in a particular situation.  

[16]  Statements of rules that mandate how many of a particular data item must be present based on the value of another data item.  

[17]  Graham Witt, "Writing Natural Language Rule Statements — a Systematic Approach:  Part 7 — Equality Rules, Rule Statement Patterns," Business Rules Journal, Vol. 14, No. 1 (Jan. 2013), URL: http://www.BRCommunity.com/a2013/b686.html  

[18]  'A', 'An', or 'The' is used rather than 'Each' in this type of rule statement since the use of 'Each' with 'must not' leads to awkward-sounding statements such as '†Each passenger must not smoke.' (the dagger symbol is used to indicate that a rule statement is, for one or more reasons, not recommended).  

# # #