Writing Natural Language Rule Statements — a Systematic Approach Part 21: The Syntax of Data Cardinality Rule Statements

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]) 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
RS15. Each Travel Insurance Application
must specify exactly one birth date
   
for each passenger.
  1. mandatory option selection rule statements,[11] such as
RS21. Each Travel Insurance Application
must specify whether it is for international travel or for domestic travel.
  1. mandatory group rule statements,[12] such as
RS43. Each Travel Insurance Application
must specify a return date or a travel duration but not both.
  1. prohibited data rule statements,[13] such as
RS50. A Travel Insurance Application
must not specify a medical condition
    for any passenger
        who does not have any pre-existing medical condition.
  1. maximum cardinality rule statements,[14] such as
RS51. A Travel Insurance Application
must not specify more than one Frequent Flier membership
for any one passenger.
  1. multiple data rule statements,[15] such as
RS53. Each Flight Booking Confirmation
that is for a return journey or for a multi-stop journey
must specify at least two flights.
  1. dependent cardinality rule statements,[16] such as
RS55. The number of passenger names specified in each Flight Booking Confirmation
must be equal to the number of passengers
specified in the Flight Booking Request
that gives rise to that Flight Booking Confirmation.

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:

P2.  <obligation statement> ::=
{Each | The} <subject>
must <predicate>
{{if | unless | after} <conditional clause>|}.
P3.  <prohibition statement> ::=
{A | An | The} <subject>
must not <predicate>
{{if | unless | after} <conditional clause>|}.[18]
P4.  <restricted permission statement> ::=
{Each | The} <subject>
may <predicate>
only {if | after} <conditional clause>.

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:

RS56. The number of advance seat requests specified
    for each flight
    in each Flight Booking Confirmation
must be no more than the number of passenger names
    specified in that 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.

RS25. Each Travel Insurance Application
    that is for international travel
must specify at least one Region.

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:
RS286. Each Flight Booking Confirmation
must specify exactly one birth date
    for each passenger
        whose age is less than 12 years.

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.
RS287. Each Flight Booking Request
must specify
    whether it is for
    a return journey, a one-way journey, or a multi-stop journey.
RS288. Each Flight Booking Confirmation
must specify
    for each passenger
    whether 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.

RS45. Each Travel Insurance Application
must specify at least one of the following:
    a postal address, an e-mail address or a contact phone number.
RS46. Each Travel Insurance Application
must specify exactly one of the following:
    a postal address, an e-mail address or a contact phone number.
RS289. Each Flight Booking Confirmation
must specify
    a credit card or an electronic funds transfer payment receipt but not both.
RS290. Each Flight Booking Confirmation
must specify
for the contact person
    a mobile phone number, an e-mail address, or both.

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

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

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

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

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

[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.  return to article

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

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

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

[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).  return to article

# # #

Standard citation for this article:


citations icon
Graham Witt, "Writing Natural Language Rule Statements — a Systematic Approach Part 21: The Syntax of Data Cardinality Rule Statements" Business Rules Journal, Vol. 15, No. 4, (Apr. 2014)
URL: http://www.brcommunity.com/a2014/b757.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
Subscribe to the eBRJ Newsletter
In The Spotlight
 John A. Zachman
';
The Issue Is THE ENTERPRISE By John A. Zachman Jan. 2017 | Vol. 18, Iss. 1
 Jim  Sinur

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.