Ch 11 - Context, Intent, and Action: The Semantic Foundation

Back in the day, Eddie Bravo’s 10th Planet Jiu-Jitsu featured some interesting, unorthodox moves with equally unorthodox names: Lockdown, Rubber Guard, Truck, Twister, Mission Control, New York, and Chill Dog. When I began learning these moves, it felt like a new cheat code was unlocked for me. Equally fun was using names that only an inner circle of grapplers knew. I heard that in jiu-jitsu tournaments, the 10th Planet team would shout out these names because their traditionally trained opponents weren’t likely keen on the meaning of these terms. Every gym develops its own shorthand, and if you’re new, you pick it up from the people around you as much as from the coach. Someone says “underhook,” and you learn what it means because someone shows you, not because you read a definition. In jiu-jitsu, you think of a term, and it gives you the mental framework to execute it. Meaning provides context, intent, and action. In data modeling, semantics is the same problem at organizational scale. “Customer” means one thing to sales, another to finance, another to marketing. When the numbers don’t match across departments, it’s usually a vocabulary problem, not a technical one. Foundations for Meaning in Data ModelingLet’s go back to the good old problem of defining a customer, and consider what happens when a company’s sales and operations teams define “customer” differently. Sales counts anyone who’s ever made a purchase, no matter how long ago (the sales team likes bigger commissions). Operations could only activate customers from the past year (to be efficient). When they pull reports for the executive team, the numbers don’t match. The CEO gets contradictory insights. Decisions are delayed. Resources are misallocated. It happens all the time, as you’ll see later in this book. When I first started working on this book a couple of years ago, the discussion of meaning and semantics in data modeling was sparse. For decades, data modelers argued about things like the definition of a customer, and the conversation was confined to structured (and maybe semi-structured) data. But with the world’s focus on AI, fresh attention is now being paid to what we mean by the things we say. Meaning and context are, strangely, experiencing a rebirth through the way we interact with machines. A discussion of data modeling in this new context is incomplete without covering meaning, semantics, and knowledge. This is where the Knowledge Camp, which we introduced in Chapter 1 and touched on in subsequent chapters, finally gets its due. This chapter is about capturing meaning through semantics, ontologies, taxonomies, and metadata. It’s unglamorous, but it’s the work that separates ad-hoc models from real ones, especially as we work alongside AI. Why Meaning Is the Missing Link in Data ModelingThere’s an assumption (often vague) in traditional data modeling that “data has meaning”. The big question is, what does it mean for whom? Exactly what do we mean by meaning? Meaning is context-dependent. It’s often unstated and lives in people’s heads rather than in schemas. I’m not going to get overly philosophical or pedantic. But many problems arise from ignoring meaning. This takes the form of poor data models, integration failures, mismatched assumptions, or scattered definitions. Any of these can create chaos in the data model. There’s also a macro trend occurring. Mainstream data modeling approaches have traditionally focused on structured data. But the popularity of AI, especially large language models, is shifting focus from “structure only” to “structure plus semantics.” An LLM doesn’t read your schema the way a DBA does. It needs explicit meaning to do its job, and so do the AI agents increasingly being deployed to query, transform, and act on your data. This makes semantics not just a modeling best practice, but a requirement. What Do We Mean by Meaning?Meaning is what something is intended to signify or express. At least, that’s the starting point. There’s meaning to you. There’s meaning to me. Where our individual meanings overlap, we create shared meaning, and that’s the space where data modeling lives. Remember the “customer” problem from earlier in this chapter (and book at large)? That’s just the tip of the iceberg. When did they last order? How much did they order? What qualities, quantities, and timeframes constitute a Customer? And by the way, what is an Order? If a customer requested a free sample ten years ago, is that person a Customer, and was that actually an Order? This is where the hard work of data modeling begins. This is the fun and challenging part. Meaning can vary by context. This ambiguity in business stands in sharp contrast to other fields that demand objective, universal truths. In some fields, meaning is concrete and unambiguous. My background is in mathematics, where I was subjected to endless lemmas and theorems I had to prove forward and backward. Simple things we take for granted, like addition, have rigorous mathematical proofs. Addition is unambiguous in standard arithmetic. Then there’s the scientific method, an agreed-upon practice for testing and validating hypotheses. If enough people test a hypothesis and reach the same conclusion, it is accepted as “fact.” Of course, science always leaves the door open for invalidation. In chemistry, the molecular structure of water is always H₂O. And in my personal life as an avid rock climber, despite Flat Earthers arguing otherwise, gravity is very real. I always tie into a rope or fall onto a crash pad. Feel free to test the theory of gravity out if you feel differently. I could go on, but the point is clear: meaning is mostly subjective, sometimes objective. It depends on the context and the thing to which you’re ascribing meaning. Because data models are seldom used by only one person but instead by a group, your job as a data modeler is to capture and represent the shared meaning of what you’re trying to convey. This shared meaning creates a common understanding of concepts, vocabulary, and related terms across the organization. It also facilitates shared understanding among organizations, particularly regarding standards. I know philosophers might shoot down what I’ve written. That’s fine, since this isn’t a philosophy chapter. The main takeaway is this: your job is to capture this messy, contextual, but vital meaning in a way that it can be collectively agreed upon and understood. This is the essence of data modeling, whether for humans or machines. Meaning lives in that messy middle ground where it’s subjective enough to need context, and objective enough to require shared rules. Semantics in Data Modeling: Creating Shared Understanding and ContextIf meaning is what we agree something is, semantics is how we describe and preserve that agreement in language. Semantics is the heart of data modeling. While traditional modeling has focused on technical structure, it often overlooks a key component: shared understanding. Creating a common interpretation of data is essential to solving communication bottlenecks between people and, increasingly, between people and machines. With the rise of AI as both a consumer and generator of data, semantics is no longer a second-class citizen. Semantics ensures that the real-world meaning of data and the relationships among different data elements are consistently captured and understood by people and machines.

          Read more
       (https://practicaldatamodeling.substack.com/p/ch-11-context-intent-and-action-the)