Conceptual Model vs. Concept Model: Not the Same!
What exactly is a conceptual model? And is it the same as a concept model? You would think they might be similar or even the same. Actually, they are quite different and serve very different purposes.
A conceptual model is a representation of key elements of some target problem purposely excluding any design complexity. A conceptual model can be viewed as a part or phase of discourse about that target problem, usually early-on. After that phase you might simply file it away. In that sense a conceptual model is high-level.
A concept model, in contrast, is an aid in achieving precision in continuing discourse about some subject matter. It enables clear communication by allowing you to express statements (sentences) that can be readily understood and disambiguated (perhaps automatically). A concept model becomes ever more important the deeper you dig into the subject matter. It's not something you should ever 'file away'.
There are multiple forms of conceptual model, but there is one and only one form of concept model.
- The form of a conceptual model depends on the target being conceived. For example, you can have a conceptual model of processes, of locations, of organizational roles, etc. Sometimes the same conceptual model can involve more than one of these. The nature of connections in the conceptual model also depends on the target. For example, the connections might be sequential, spatial, collaborative, etc. — or some combination thereof.
- The form of a concept model never depends on the target. A concept model is always literally expressed by a set of definitions, each definition representing a concept. All connections between concepts are either verbal concepts (i.e., ones literally expressed by verbs or verb phrases) or logical statements (e.g., specialization, the notion that one concept is a specialization of some other concept). No other kinds of connection are ever entertained.
A conceptual model is often inherently graphical. A concept model, in contrast, is always semantic. You can certainly create a graphical guide to a concept model, but doing so is always a matter of convenience, not of necessity.
The target of a conceptual model frequently involves things in the real world. That target is often something you want to engineer, re-engineer, or perhaps reverse-engineer.
The target of a concept model, in contrast, is always what's in the mind, not directly about things in the real world. It's about how you understand things — that is, how you define your concepts. It is engineered based on the words needed to express those concepts. Its purpose is to help you communicate complex knowledge — in sentences.
Table 1 summarizes fundamental differences between a conceptual model and a concept model.
Table 1. Conceptual Model vs. Concept Model.
Case Study: Creation of a Conceptual Model vs. a Concept Model
Suppose the year is 1956. We decide we want to create a fast, multi-lane, non-stop highway between the cities of Los Angeles, CA and Jacksonville, FL. In other words, we want to create Interstate Highway 10 ('I-10'). A good place to start is to create a conceptual model.
So, a rough map is drawn up by hand (it's 1956!) showing the locations "Los Angeles, CA" and "Jacksonville, FL" connected by the new Interstate being conceived ("I-10", so labelled on the model). Discourse about the new route is successfully initiated, and its engineering eventually moves on to the design and then the construction phases. The conceptual model is judged to have been a success.
In 1956 no repository is available other than file cabinets (which is probably where the sketch ends up). But let's suppose an automated platform were available to record the 'facts' represented in the conceptual model (not just the visualization itself). Those facts would be the start of a Business Knowledge-Base. Here are the facts so far.
- The city "Los Angeles, CA" exists.
- The city "Jacksonville, FL" exists.
- The Interstate Highway "I-10" links "Los Angeles, CA" and "Jacksonville, FL."
Not much there! No concept model has been created. So far, there are no definitions for 'city', 'Interstate Highway', or 'links'.
Now let's suppose we want to specify some business rules, as follows:
- Each Interstate Highway must be at least two lanes in each direction.
- Each Interstate Highway must be at least three lanes through a major city.
- A rest stop must be situated on an Interstate Highway no more than every 100 miles except in major cities.
The hand-drawn conceptual model could perhaps be updated with some new graphical features — for example, representing two-lane and three-lane highway segments, major cities, and rest stops. Or not. It's a judgment call about whether the updates would be useful for discourse at that stage (and in the future).
In order to communicate and understand the business rules precisely, however, each of the concepts needs to be defined and related as appropriate. In other words, you need to create a concept model.
So, work on a concept model is initiated and appropriate entries are created in the Business Knowledge-Base. Those entries would include the following (by no means complete):
- Definition: A highway is defined as (something about transport routes for vehicles) ….
- Verbal wording: highway links city
- Definition: An Interstate Highway is defined as a highway that ….
- Fact: An Interstate Highway is a specialization of highway.
- Definition: A lane is defined as a ….
- Fact: A highway is comprised of lanes.
- Definition: A direction is defined as (something about the intended flow of vehicles in one or more lanes) ….
- Definition: A city is defined as a ….
- Verbal wording: city is major
- Definition: A rest stop is defined as a location situated on an Interstate Highway that (something about providing food, water, restrooms, rest areas, and gasoline) ….
This set of entries constitutes the initial concept model.
Suppose you wanted to engineer a database. Yes, you could start with a conceptual model to portray the essential things you ultimately want to keep data about. And yes, you could call it a conceptual data model.
Here's a two-part test to determine whether your conceptual data-model can pass muster as a concept model.
- Is every term defined? If not, the model is not a concept model. By the way, I mean fully defined in business English without any use of data-ish terminology.
- Is every verb (or verb phrase) specified that you would need to make any meaningful statement about the subject matter (e.g., any business rule). If not, the model is not a concept model.
Very few (actually none) of the conceptual data-models I've come across can pass these tests.
By the way, can a concept model be used to create a data model (to engineer a database)? Absolutely. In fact, I think you should use one. Literally, how could you keep data about something you can't talk about precisely?! That's a highway to nonsense!
A concept model is not a conceptual model as in the common industry usage. A concept model is about defining as precisely as possible what you mean by the words you use. To say it differently, a concept model is a word model — a model of words — where the words represent concepts.
A concept model serves as a lexicon for expressing your inventory of thoughts about some subject matter. It gives you standard words to make unambiguous statements (write clear sentences) to express those thoughts.
A concept model comprises a structured vocabulary with sufficient semantics to 'test' the precision and consistency of all statements written about the subject matter. The statements can be of arbitrary complexity. The concept model provides a basis for disambiguation — the discovery of disconnects in our mutual understanding. It literally ensures we are communicating — i.e., that our statements can be interpreted correctly (whether by people or machines).
A concept model is a foundation for clearly expressing knowledge. And if you can express knowledge clearly, then you can capture and disambiguate it. That's something new — it's not something that's ever been done before in an engineered fashion.
 The names of the two cities and the link appear in quotation marks in this sentence because the icons and line on the sketch are not the real-world things, just representations of them.
 Refer to the Business Agility Manifesto: https://busagilitymanifesto.org/.
 Facts always must be complete, unambiguous sentences (propositions) that are true.
 Personally, I wouldn't bother trying to define the real-world instances 'Los Angeles, CA', 'Jacksonville, FL', or 'I-10', but you could. In fact, it might be prudent. My concept of 'Los Angeles, CA' might be different from yours(!). For example, is it just the chartered city, or is it the whole metropolitan area including Santa Monica, CA (where I-10 actually starts)?
 I'm using business rules just as an example. They could be literally any business communications you'd like to express precisely.
 Personally, I wouldn't use that term because 'conceptual data' is just too confusing. It's an oxymoron. So, if you want to use the term, at least hyphenate it properly — conceptual data-model — as I do in the paragraphs that follow.
 You can start off modestly, of course.
 The meaning of 'concept model' in this discussion is from the OMG standard Semantics of Business Vocabulary and Business Rules (SBVR). For more information refer to http://www.brcommunity.com/standards.php.
 the vocabulary of a subject — from Merriam-Webster unabridged Dictionary (2)
 As used in this discussion statement always means one or more complete, meaningful sentences.
 What is the difference between knowledge and information? Here's my personal view. Let's suppose we updated the I-10 conceptual model to visually show two-lane vs. three-lane highway segments. I can look at the model and see that I-10 is at least 3 lanes everywhere within Los Angeles, CA and Jacksonville, FL. I'd call that information. What you don't know is whether an Interstate Highway is intended to be at least three lanes in every major city. Even if the map were complete, and the Interstate Highways were three lanes in every major city, could you be sure even then? No, it might be just a coincidence. To be sure I need the business rule. It gives more than just information; it communicates knowledge.
# # #
About our Contributor:
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.