Four Useful Constructs for Developing a Structured Business Vocabulary: Special-Purpose Elements of Structure for Fact Models

Ronald G.  Ross
Ronald G. Ross Co-Founder & Principal, Business Rule Solutions, LLC , Executive Editor, Business Rules Journal , and Co-Chair, Building Business Capability (BBC) Read Author Bio       || Read All Articles by Ronald G. Ross
Excerpted from Chapter 6, Business Rule Concepts:  Getting to the Point of Knowledge (Third Edition), by Ronald G. Ross (August 2009). ISBN 0-941049-07-8   http://www.brsolutions.com/b_concepts.php

To express business rules and other forms of business communication at scale, you need both noun concepts and verb concepts.[1]  The result is a structured business vocabulary, often represented as a graphical fact model.  The verb concepts (fact types) distinguish fact models from other kinds of structural models (e.g., data models and class diagrams).

The business meaning (semantic shape) of the verb concepts lies completely with the wordings supplied for them by business workers and business analysts.  Such verb concepts have no implicit or prefabricated meaning of any kind.  They are business-defined elements of structure.

Other important elements of structure come in handy, pre-defined semantic shapes, as provided by SBVR.  This discussion illustrates use of four of these shapes, as presented in Table 1.  These special-purpose connections between noun concepts extend the reach and precision of the fact model significantly.  Before I get too deeply into that, however, I should give a quick note about the term instance.

About the Term Instance

At this point in the discussion, I will start taking a few liberties with the SBVR concept of instance.  In SBVR, instances are always in the real world, not in a model.  For example, you can't put the real country Canada into a model.  Wouldn't exactly fit(!).  In a fact model, you can include only concepts (like the one that stands for Canada) and facts (things you assert are true about Canada).

If you're used to thinking about instances being organized within or by a model (e.g., to be stored in a database), however, that gets a little confusing.  So in this discussion, I will use the term instance a bit more loosely.  Just remember, when business people talk about real-world things, they're not talking about instances in a model(!).
Table 1.  Special-Purpose Elements of Structure.

Special-Purpose Element of Structure

General Form

Example

Use in a Sample Business Rule Statement

categorization

(Class of thing1) is a category of (class of thing2).

'Corporate customer' is a category of 'customer'.

A customer is always considered corporate if the customer is not an individual person.

property

(thing1) has
(thing2)

order has date taken

order has date promised

An order's date promised must be at least 24 hours after the order's date taken.

composition
    (wholepart or
    partitive structure)

(whole) is composed of (parts)

(part) is included in (whole)

chair is composed of:

  • legs
  • seat
  • back
  • armrests

A chair may be ordered without armrests.

classification

(Instance) is classified as a (class of thing).

Canada is classified as a country.

Canadian dollar is classified as a currency.

An order may be priced using the currency 'Canadian dollar' only if the customer placing the order is located in Canada.

1.  Categories and Categorizations

A category is a class of things whose meaning is more restrictive than, but otherwise compliant with, some other class of things.  For example, male is a category of person.  Each male is always a person, but not every person is a male.  A male can have properties that would not apply to any person who is not a male.  In general, a category represents a kind, or variation, within a more general concept.

Representing one class of things to be a category of another class of things is called categorization.  Figure 1 illustrates several categories (using heavy lines).

Figure 1.  Illustration of categories.

The following categorizations are illustrated by Figure 1.

  • Both sales representative and engineer are recognized as categories of a more general concept employee.  Note the property employee name is indicated for employee.  Since all sales representatives and engineers can have names — indeed, any employee can — the name property is indicated only for employee.  Remember that all sales representatives and engineers are employees in this business, so the name property pertains as a matter of course to both representative and engineer.  It does not need to be re-specified for them; inheritance of the property is assumed.  On the other hand, commission rates apparently pertain only to sales representatives — not to all employees (e.g., not to engineers) — since commission rate is indicated only for sale representative.

  • Product has three categories — military, corporate, and consumer — forming a group.  This group of categories is organized on the basis of a categorization scheme named orientation — more about that later.  Note that (as always for categories) military, corporate, and consumer must be products.  Indeed, unless everyone reading the diagram is thoroughly familiar with categorization, better labels would probably be military product, corporate product, and consumer product.  The boxes represent that anyway, but these revised labels would emphasize the point.

Any category can have categories; any category of a category can have categories, and so on.  Multiple levels of categorization are not uncommon in fact models.  Indeed, such refinement or narrowing of meaning as you go 'deeper' yields a high degree of precision or selectivity for making statements about the business (e.g., giving business rules).  For example, a business rule might be expressed for software engineers, a potential category of engineer, which does not apply either to other kinds of engineers or to employees in general.

2.  Properties

The Merriam-Webster Unabridged Dictionary defines 'property' as a quality or trait belonging to a person or thing.  Figure 1 indicates employee name to be a property of employee, and commission rate to be a property of sales representative.  A thin line is used to attach each to the appropriate box (noun concept).  Exactly what does the thin line represent? 

The thin line does not indicate that every member of a class of things actually has an instance of the property, only that it can.  If each member of a class of things must have an instance of the property, an explicit business rule is required (e.g., An employee must have an employee name.).

The thin line is actually a shorthand for a binary fact type.  The wording for this binary fact type defaults to (thing1) has (thing2).  The important word here is has.  The verb to have is very general — not specific or descriptive at all.  Has makes very poor wording for fact types not specified as properties.  For properties, on the other hand, a has default is often convenient.

Can properties be worded using verbs other than hasYes.  For example, the commission rate property of sales representative might be worded sales representative is compensated at commission rate.

The property shown at the end of the line is often actually a role of some other noun concept.  For example:

  • Suppose commission rates are always percentages (in this business).  Then the commission rate property of sales representative actually represents the fact type worded sales representative is compensated at [commission rate] percentage.

  • Similarly, the employee name property of employee might actually represent the fact type worded employee has [employee name] name.

Note on Notation

Why bother with a graphical shorthand for properties?  The answer has to do with scaling up.  If you were to treat all properties as 'regular' fact types, the fact model would become hopelessly cluttered with connections having to do with such things as numbers, names, dates, units of measure, and much more.  Such connections are of secondary importance to the business.  Avoid that!

Figure 1 actually includes several other properties, as follows.

  • Two properties for the objectification[2] briefing have been indicated using a single thin line (another shorthand to reduce clutter).

  • Orientation, which can be seen just above the crossbar for the categorization of product, is also a property, albeit a special kind.  Orientation is the name of the categorization scheme used to organize the three kinds of product.  Since orientation is a property of product; we can say product has orientation.  (That's like saying person has gender, meaning male and female.)  Is it required that every product fall into at least one of the three categories:  military, government, or consumer?  In other words, must every product have an orientation?  (Or perhaps exactly one?)  Don't assume so — that would require some explicit business rule(s).

3.  Compositions — Whole–Part (Partitive) Structures

Many things in the real world are composites, made up of several other kinds of thing.  For example, an automobile (simplistically) is composed of an engine, a body, and wheels.  A mechanical pencil is made up of a barrel, a lead-advance mechanism, pencil lead, and eraser.[3]  An address (simplistically) is made up of a street number, a street, an apartment number, a city, a state/province, a country, and a zip code / postal code.

Sorting out the terminology and composition of such whole–part structures is often quite useful.  Before looking at a graphical example, let's address some relevant questions:

  • Is every instance of the whole in a whole–part structure required to have at least one instance of each part?  No.  For example, not every address has an apartment number.  If every instance of the whole is required to have some part(s), an explicit business rule must be given.

  • Can an instance of a whole have more than one instance of a kind of part?  Yes.  An automobile must have at least three wheels (a business rule).  But use caution here.  A whole–part structure usually works best where there is only one, or a small number, of each part.

  • Can the specification of a whole–part structure indicate only one kind of part?  Yes.  However, exercise common sense!  For example, is it really useful to consider the fact type worded order includes line item to be a whole-part structure?  We do not favor that practice.

  • Can a part itself be a whole composed of other parts?  Yes.  Multiple levels of composition are possible.

  • Can both the whole and the parts be selectively involved in fact types on their own?  Yes.

  • Can an instance of a part exist independently from an instance of the whole?  Yes (unless business rules disallow it).  A wheel, for example, can be removed from an automobile.

  • Can an instance of a part be in more than one instance of a whole at the same time?  Yes (again, unless business rules disallow it).  A power source, for example, can be part of more than one circuit.

Figure 2 illustrates a composition of briefing using a tree structure of thin lines to indicate the parts.  The wording for this fact type, not shown explicitly, is assumed to be:  briefing is composed of:  introduction, main body, conclusion.  In other words, tell 'em what you're gonna to tell 'em, tell 'em, and tell 'em what you told 'em.

Figure 2.  Example of a composition (whole-part structure).

4.  Classifications

A central focus in fact modeling is on identifying, defining, and naming the classes of things important to basic business operations.  Most often the business cannot possibly know in advance what all the instances will be of a class of things.  For example, most businesses cannot predict all their future customers.

For certain classes of things, however, the business can identify or prescribe in advance some or all of the instances, especially for those classes where the instances are relatively stable.  For example, we know all the European countries at the present time.  Moreover, the business will need to pre-define instances when it has some business rule(s) that pertain selectively to them — for example:  A shipment may be made only to the European countries United Kingdom or The Netherlands.

Representing the connection between an instance and its particular class of things is called classification.[4]  Figure 3 illustrates.  The line with the double-wavy hatch mark indicates a classification connection from the class of things European country to some of its instances.

Note on Notation

The double-wavy hatch mark indicates that a meta level is crossed.  To avoid clutter, we recommend ample use of neighborhoods[5] to depict instance-level terminology.

Figure 3.  Example of classification.

Some additional examples of classifications:

  • Health care:  All recognized health services — e.g., consultation, office visit, hospital admission, surgery, and so on.

  • Ship inspection:  All recognized parts of a ship — e.g., bulkhead, hatch cover, railing, deck, and so on.

These examples were chosen deliberately to illustrate that classifications can be multi-level.  For example, the instances bulkhead, hatch cover, etc. of the class of things ship part type might themselves be viewed as classes of things with respect to specific bulkheads, hatch covers, etc.  These specific bulkheads, hatch covers, etc. probably have serial numbers and would be found on a given ship or in a given shipyard.  Business rules might be targeted toward any of these levels.

References

[1]  I discussed verbalization in my November 2009 column. See:  http://www.BRCommunity.com/a2009/b506.htmlreturn to article

[2]  Refer to the discussion of verbalization in my November 2009 column.  See:  http://www.BRCommunity.com/a2009/b506.htmlreturn to article

[3]  From [ISO-704]  International Organization for Standardization (ISO).  Terminology work — Principles and Methods.  English ed.: ISO (2000), p. 9. return to article

[4]  Classification is termed assortment in Semantics of Business Vocabulary and Business Rules (SBVR), v1.0.  Object Management Group (Jan. 2008). return to article

[5] A neighborhood is a page or tab in a large graphical fact model that generally concentrates on categories, properties, and instances for just one or several core concepts. return to article

# # #

Standard citation for this article:


citations icon
Ronald G. Ross , "Four Useful Constructs for Developing a Structured Business Vocabulary: Special-Purpose Elements of Structure for Fact Models" Business Rules Journal Vol. 11, No. 6, (Jun. 2010)
URL: http://www.brcommunity.com/a2010/b538.html

About our Contributor:


Ronald  G. Ross
Ronald G. Ross Co-Founder & Principal, Business Rule Solutions, LLC , Executive Editor, Business Rules Journal , and Co-Chair, Building Business Capability (BBC)

Ronald G. Ross is Principal and Co-Founder of Business Rule Solutions, LLC, where he actively develops and applies the IPSpeak methodology including RuleSpeak®, DecisionSpeak and TableSpeak.

Ron is recognized internationally as the "father of business rules." He is the author of ten professional books including the groundbreaking first book on business rules The Business Rule Book in 1994. His newest are:


Ron serves as Executive Editor of BRCommunity.com and its flagship publication, Business Rules Journal. He is a sought-after speaker at conferences world-wide. More than 50,000 people have heard him speak; many more have attended his seminars and read his books.

Ron has served as Chair of the annual International Business Rules & Decisions Forum conference since 1997., now part of the Building Business Capability (BBC) conference where he serves as Co-Chair. He was a charter member of the Business Rules Group (BRG) in the 1980s, and an editor of its Business Motivation Model (BMM) standard and the Business Rules Manifesto. He is active in OMG standards development, with core involvement in SBVR.

Ron holds a BA from Rice University and an MS in information science from Illinois Institute of Technology. Find Ron's blog on http://www.brsolutions.com/category/blog/. For more information about Ron visit www.RonRoss.info. Tweets: @Ronald_G_Ross

Read All Articles by Ronald G. Ross
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
 Ronald G. Ross

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.