Data, Facts, Messages, and Ambiguity

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

Extracted from Business Knowledge Messaging: How to Avoid Business Miscommunication, by Ronald G. Ross, 2022. https://brsolutions.com/business-knowledge-messaging.html

Suppose I ask you for an example of a city. You respond with "Utrecht." I trust you, so I accept Utrecht as a city. Because my memory is bad, I put it in a database for safekeeping. What just happened?

We had an exchange of messages, of course. This exchange might have been in-person or digital, no matter. Now I have the piece of data in my database 'Utrecht'.

More precisely, I have the datum[1] 'Utrecht' in my database. I have other cities represented there too, including 'New York', 'Tokyo', 'Singapore', etc. Each one of those is a datum too. Collectively, they add up to data (plural).

When I put 'Utrecht' in my database, I obviously didn't put in the real city (way too big to fit). I put in just the name of the city, the character string that acts as a signifier for the real city.

How should I interpret that datum? I originally asked for an example of a city. You sent me back "Utrecht." So actually, your message can be properly interpreted as "Utrecht is an example of a city." In other words, you sent me a fact, even though your message wasn't a complete sentence.

How then should I interpret 'Utrecht' in my database? It's actually a representation of that original fact, in shorthand form, inserted into the database to assist my memory.

What's the bottom line? You should think of every datum in every cell of every database table as representing some fact (many more complicated than this one). Data is not just data; each datum represents a fact — in other words, knowledge. Each datum is a message to people in the future about some aspect of business knowledge.

How Ambiguity Arises in Data

The fundamental problem with the data in database tables (aka structured data) is that it has essentially been stripped bare of almost all grammatical conventions. Witness 'Utrecht' above. What problems can that cause?

Consider the simple example in Figure 1. Let's try to reconstruct the meaning of the messages from just what we see in the data.

Figure 1. Example of Structured Data

Consider the first row in the table. Exactly what facts does it represent? Let's try to express it as a sentence.

Proposed Fact: The order having the id 20680 was placed by C who has something to do with the city Utrecht …

But what does 'C' have to do with the city 'Utrecht'?

  • Does C reside in Utrecht?

  • Did C place the order in Utrecht?

  • Does C want the order to be shipped to Utrecht?

We get stuck right off.

Actually, the situation is even worse than that. The proposed fact already assumes the connection between the order #20680 and C is 'was placed by'. Did you catch that? How can we be 100% sure that's the intended meaning? We can't! We're just guessing.

The rows of data in this database table are simply not very well-formed messages. Reverse-engineering the intended facts requires making assumptions. Ambiguity lurks; miscommunication and misuse will ensue. Have pity on the recipients of formal messages.

Yes, better labels for the columns in this table could help eliminate some of the guesswork. Improvements for the purpose of better data design, however, can never eliminate all the potential ambiguities for messaging. And they won't even touch the larger problem of better messaging about business knowledge across the entire business.

What can you do? A fundamental step is creating a blueprint for the underlying knowledge, which we call a concept model (structured business vocabulary).[2] A concept model supports formal business messaging of all forms, including structured data, by providing wordings for the verbs you need to create complete, coherent sentences.

References

[1] the singular of 'data'

[2] Refer to: Business Knowledge Blueprints: Enabling Your Data to Speak the Language of the Business (2nd ed), by Ronald G. Ross, 2020. https://www.brsolutions.com/business-knowledge-blueprints.html

# # #

Standard citation for this article:


citations icon
Ronald G. Ross, "Data, Facts, Messages, and Ambiguity" Business Rules Journal, Vol. 23, No. 10, (Oct. 2022)
URL: http://www.brcommunity.com/a2022/c104.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 BRS 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
CONTRIBUTOR ARCHIVES
Disambiguation Beyond a Reasonable Doubt
Ambiguity and Its Cure
Data, Facts, Messages, and Ambiguity
As the Agile Churns
Agile Death Spirals and Data
In The Spotlight
 Jim  Sinur
 Ronald G. Ross
The BRSolutions Professional Training Suite

BRSolutions Professional Training Suite

All About Concepts, Policies, Rules, Decisions & Requirements
We want to share some insights with you that will positively rock your world. They will absolutely change the way you think and go about your work. We would like to give you high-leverage opportunities to add value to your initiatives, and give you innovative new techniques for developing great business solutions.