Building Semantics with Conceptual Models
Some tips & tricks for rigorous modeling!
Data consumers need to understand what they are consuming. This was always true, way before AI agents. I’ve been practicing, speaking, writing, teaching, and learning continuously more about conceptual modeling for well over a decade now, and conceptual modeling has always been a method of capturing and documenting that understanding.
But while some demand for this kind of work always existed, it wasn’t often considered a must-have: you see, Bob from Accounting could always go and ask Juliet from Procurement when he didn’t understand something in the supplier data. Our engineering-focused data industry simply took that for granted; we counted on the resilience of everyday human-to-human communication networks to paper over our failure to capture and document data context. We delivered the technological part and called it a day1.
Enter the agentic era, and now context is king! Listen, I’m not a perfect human being, so I have to admit I tend to mutter “I freaking told you so” under my breath every now and then... But it’s OK, of course I get why this is so important right now. The agent can’t (at least not yet?) go and ask Juliet from Procurement, and it needs a lot of semantical information to figure things out. So we need to help it understand.
Conceptual modeling is at its core semantic work. Traditionally, conceptual modeling was seen as a step in the 3-part ladder of data solution design; conceptual-logical-physical. While it is an excellent way to start your solution design, it’s not only that: we can use the semantical information we captured in more than just solution design.. You can find that argument expanded upon in an earlier article:
However, if you are serious about semantics, and really want to capture and document something that is going to be useful to agents and humans alike, you can make your life a lot easier if you pay a little attention to how you do conceptual modeling. There’s a path from a conceptual model all the way to a proper knowledge graph: a conceptual model can be turned into an ontology. It’s possible, it’s quite straightforward, and I’ve done it in real life. All you need is a bit of discipline in your modeling.
I want to drop you some breadcrumbs to follow in order to make your conceptual models more disciplined and useful. What follows is a super simple basic idea of how to do conceptual modeling in a way that best supports capturing and documenting semantic context.
Methodological disclaimers
I wrote above that the point is “capturing and documenting semantic context”. Note that that sentence in no way refers to databases, data lakes, data warehouses, lakehouses, pipelines, ETL or ELT, nor any other technological mumbo-jumbo. In fact, I’m going to ignore the whole data storage angle entirely here! When we model for actual business concepts and the semantic structure of data, we don’t care about storage2. You can, of course, still use the same conceptual models for solution design, but you don’t have to - that’s the beauty of this work!
Please note also that the way I do conceptual modeling is NOT:
A) the only right way to do it
B) in any way academically solid
C) actually mine.
I am a pragmatic person. I try things, I keep what works in practice, and I drop what doesn’t. Others will concern themselves with the differences between “concept models” and “conceptual models”, or with specific notations designed to capture every possible nugget of information present in human language. I’ve just gathered bits and pieces from here and there, from various people and books and courses, into something that seems to work3.
I also want to manage expectations and point out that this article is not going to be a full how-to guide on conceptual modeling. But with great pleasure I can tell you that a full how-to guide is coming! Together with my mate Shane Shagility Gibson we’re writing a guide to conceptual modeling. You can follow the book’s progress on the Modeling Business Concepts Substack.
With the disclaimers out of the way, we can get down to brass tacks.
In a Nutshell: What Do We Model?
It’s very simple, really. In the end, there are only two things of importance in a conceptual model:
Entities
Relationships
An entity is a thing that exists in real life, that you have data about. A relationship is an association between two entities; a way to assert that they have something to do with each other.
That’s it.
You can make an argument about including attributes (or properties) of entities; go ahead if you want to, but I usually try to avoid going too deep into that, as people tend get stuck in attributes. We need the basic “structure of reality” first, and that we get with entities and relationships. Add attributes later.
These two things are generally presented visually. Usually, an entity is a box in a diagram. A relationship is a line between two boxes. That gives you a visual model of what exists and how things are connected - an “entity-relationship diagram”, some might say.
Here’s one for you:
Easy, isn’t it?
The Mind Map Trap
Drawing boxes and lines is easy, fun, and useful in many situations. I always support any activity that includes drawing boxes and lines of any kind before people start coding stuff!
But while you can conceivably call almost any bunch of boxes and lines a “conceptual model” of some kind, not all of those diagrams are very helpful for serious semantics work. A mindmap can help the participants in a workshop to come to an understanding, and that is valuable in itself. But a mindmap lacks rigor and specificity. A mindmap has vibes, whereas a good conceptual model has structure. A mindmap is temporary, tied to a specific situation and discussion, whereas a good conceptual model is universally true until the business itself changes. A mindmap suggests, a good conceptual model declares.
Don’t get me wrong: you absolutely can draw mindmaps if it helps you. You can even call them conceptual models if you like; despite what the angry old men on LinkedIn might lead you to believe, there’s no real Data Modeling Police to throw you in data modeling jail. I just want to point out that with a bit more structure and rigor, you can benefit a lot more. At the same time, I try to keep things as simple as possible. Let me show you how to square that circle!
Tips and Tricks for Rigorous Conceptual Models
Make all your entities singular, countable nouns
“Customer”, not “Customers”. And for heaven’s sake, never “Customer Data”! This is the simplest and most powerful trick in making your conceptual models semantically solid. You want each entity - the box in the diagram - to be a noun in a sentence that describes how the business works. You see, those nouns will soon need to play the roles of subjects and objects.
Define all your entities
For every single box in the diagram, you need to have a definition. No deviation from this rule, ever! A good definition answers the question “what do you mean by entityname”. Write it down in simple business language. This is the basis of your glossary (or vocabulary). Terms + definitions = semantics.
If your data modeling tool has an integrated glossary functionality, good. If it doesn’t, document the definitions in Excel if you have to, but just do it!
Name all your relationships
If entities are nouns, then relationships are verbs. Every relationship - the line between the boxes - needs a name. That name must be a verb that describes the nature of the association: why is entity A related to entity B? Hint: it’s not because they share a foreign key in some table! Look into the real business and describe the real-life association.
This has two important benefits. First, we will be able to use these verbs as the predicates between our subjects and objects when we start constructing triples for a graph. Second, by naming the relationships we will soon discover that to “own” a Bank Account is a completely different thing than “having access to” a Bank Account! Two verbs means two relationships. These are important semantical connections that we will miss if we just draw a line and leave it to the reader to figure out what it represents.
Define subtypes and supertypes
A subtype is a “kind of thing”. A supertype is a higher level of thing. A car (subtype) is a kind of vehicle (supertype); a cat is a kind of mammal. Include this information in your model - but only if it’s relevant.
Some modeling experts will tell you that you should never use supertypes, because too much generalization will make the model difficult to understand. It’s absolutely true that one can go overboard with sub- and supertypes, but if I hear people talking about “two kinds of accounts”, I will certainly model the two types and their supertype. Including at least some supertypes and subtypes in a conceptual model will help you document taxonomies, which you’ll need for your knowledge graph eventually.
Here’s another example model: see how the relationships are named, and how subtypes are utilized to define different kinds of “Counterparty” and “Account”.
Ontologizing the Model
If you have created a conceptual model following the above guidelines, you’ll find it very straightforward to turn your model into a formalized ontological structure using e.g. OWL. All of the information you captured in the diagram will find its place in the ontology.
The basic logic is as follows:
Every entity becomes a class (e.g. owl:class).
Every pair of entities and the relationship between them becomes a triple.
Entity definitions become class definitions (e.g. rdfs:comment or skos:definition)
Subtypes and supertypes correspond to skos:broader & skos:narrower or rdfs:subClassOf.
The name of the entity (the noun) is the name of the class (e.g. skos:prefLabel).
The relationship (with its name being the verb) is the predicate in the subject-predicate-object triple (thus becoming an owl:objectProperty).
How this conversion from a conceptual model to an ontology technically happens depends on your tooling. Whatever your modeling tool, you can probably export the model in some format. Building a little converter between that format and e.g. a Turtle file is not a problem once you know how the logical mapping should happen. Just give the logic to Claude and off you go!
Of course, an ontology expressed in OWL can also contain a lot more information that you didn’t necessarily have in your conceptual model, but that’s fine! That’s how it should be: you use the conceptual model to easily capture the basic structure of the ontology. The conceptual modeling phase makes the discussion with your business stakeholders easier and ensures this basic structure is correct. Then you can continue building the ontology4.
Use It or Lose It
My point is this: do not underestimate what you can achieve with a conceptual model. It’s not just a mindmap; or rather, it doesn’t have to be a mindmap. A few simple methodology tricks will make the model systematic enough that it can be directly converted into ontology syntax.
Conceptual modeling is a simple, visual way of documenting what we know about our business in terms of data. Use it where it’s strongest: as a method of building a shared understanding before you start formalizing the syntax. But at the same time, ensure that the modeling work you do makes it as easy as possible to continue the process. A mindmap sitting isolated and forgotten in some project folder in Sharepoint is a wasted opportunity to build up your true semantic architecture.
Thank you for reading! I have to apologize for the inconsistent publishing rhythm on this Substack lately - the reason for that is very much related to the topic of the article. There’s simply so much demand for everything relating to semantics now, including conceptual modeling, that I have my hands full at all times! I really want to write more, but right now it’s quite hard to find the focus time I need to ensure a level of quality I require from my articles. But it turns out there’s no better place to focus than at 11000 metres above Greenland, where the bulk of this piece was written!5 Anyways, if you want to be notified of new articles when they come (they will come, don’t worry), consider subscribing!
Until next time - cheerio!
And then we wondered why value delivery is so difficult and how the business doesn’t understand us and how they just keep exporting everything to Excel. Oh well, must be a data literacy problem!
Occasionally, I read comments from people in the knowledge management community where they draw a thick line between the “relational paradigm” and their world. In some of those comments, people claim that data modeling is limited by its assumption that all data must be relational (i.e. made of tables and columns and keys). To that, I say that the only limited thing here is their understanding of data modeling! You absolutely can AND SHOULD do conceptual modeling without any concern of the physical storage structure of the information you’re modeling. Conceptual modeling is a valid approach to structured and unstructured data alike.
The biggest impact on my modeling methods, and probably on my career in data overall, was the data modeling course I attended some twelve years ago. That was run by Alec Sharp, whom I’ve been fortunate to call a friend ever since. In fact, I’m writing these words on a plane heading to Vancouver, where (in addition to some hiking and museum trips) I’m meeting him!
Preferably you would be following Jessica Talisman’s Ontology Pipeline, with the conceptual modeling phase giving you a good kick-start.
I’m finalizing this on Bowen Island near Vancouver, by the way. Maybe I’ll write the next one on the way back?