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 (2^nd ed), by Ronald G. Ross, 2020. https://www.brsolutions.com/business-knowledge-blueprints.html

# # #