Chaos and Order

💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

Introduction — The Customer's Model Mostly Lives in People's Heads
The Cheapest First Step — Ubiquitous Language
Bounded Context — When the Same Word Means Different Things
Modeling the Nouns — Entities, Value Objects, Aggregates
Three Words to Keep Straight — Taxonomy vs Ontology vs Knowledge Graph
The Formal Stack — RDF, RDFS, OWL, and schema.org
The Operational Stack — Property Graphs and Palantir's Ontology
When Is a Formal OWL Ontology Worth It?
The Failure Mode — A Beautiful Ontology Nobody Uses
Closing — From Questions, Not Concepts
References

Introduction — The Customer's Model Mostly Lives in People's Heads

When a Forward Deployed Engineer first lands at a customer, the most valuable asset is usually in no database at all. It lives in the head of the maintenance lead who has worked the floor for twenty years, in the claims adjuster's gut feel, in the tacit knowledge behind a dispatcher saying "no, we never do it that way."

One core job of the FDE is turning that scattered tacit knowledge into an explicit model the whole team can share and a machine can read. This post climbs that ladder from the bottom up — from the cheapest, highest-value first step of ubiquitous language, through formal ontologies (RDF/OWL), to operational ontologies (property graphs and Palantir-style objects plus links). The role itself is covered in The FDE Craft, Deep Dive and Preparing to Become a Forward Deployed Engineer; here I focus on the single craft of turning a domain into a model.

And let me be honest from the start. An ontology is the artifact most prone to over-engineering, and the most common failure is a beautiful ontology nobody uses. Half of this post is about dodging that trap.

The Cheapest First Step — Ubiquitous Language

Long before you draw a formal graph, there is a near-free, high-leverage move. It is what Eric Evans' Domain-Driven Design calls the ubiquitous language. Martin Fowler sums it up as "the practice of building up a common, rigorous language between developers and users."

The load-bearing word is rigorous — because, as Evans puts it, "software doesn't cope well with ambiguity." If "equipment," "asset," "unit," and "machine" point at different things for different people on the floor, and nobody names the difference, that confusion flows straight into the code.

So an FDE's first artifact is not a graph but a glossary. You sit with domain experts, use the same words back at them repeatedly, and refine wherever a term is awkward or imprecise. As Fowler notes, domain experts object to terms that blur meaning, while developers catch the ambiguity that would break a design. The conversation itself validates the model. And this language must appear identically in meetings, in code, in screen labels, in database column names. The moment a translation layer appears, a bug is born.

Bounded Context — When the Same Word Means Different Things

In a large organization, trying to unify one ubiquitous language across everything usually fails. Fowler is blunt about why: "total unification of the domain model for a large system will not be feasible or cost-effective."

His example is exact. At one utility company, the word "meter" meant "subtly different things to different parts of the organization" — a grid connection to one team, a customer contract relationship to another, the physical device on the wall to a third. The difference could be smoothed over in conversation, but not "in the precise world of computers."

DDD's answer is not forced unification but the bounded context. You split the model where the language changes ("you need a different model when the language changes") and connect contexts through explicit mappings. For an FDE this is not a luxury but a survival skill. If you fail early to catch that "work order" in the maintenance department means something different from "work order" in accounting, you pay for it months later at integration time.

Modeling the Nouns — Entities, Value Objects, Aggregates

Once the language settles, you give the nouns structure. DDD hands you three tools.

Entity. Something with an identity that runs through time. Pump A17 is still the same pump after you swap its parts and move its location. If two things with identical attributes are still distinct, it is an entity.
Value Object. Something defined purely by its attributes, with no identity. Like Money(100, USD) or a GPS coordinate — interchangeable and usually immutable. Equal values are treated as the same thing.
Aggregate. In Fowler's definition, "a cluster of domain objects that can be treated as a single unit." An order and its line-items is the canonical example. Each cluster has an aggregate root, "any references from outside the aggregate should only go to the aggregate root," and "transactions should not cross aggregate boundaries."

Aggregates matter because they are your consistency boundaries. Group work order, service items, and used parts into one aggregate and it becomes obvious what must change atomically and what may change independently. That decision carries straight through to your graph schema and transaction design later.

Three Words to Keep Straight — Taxonomy vs Ontology vs Knowledge Graph

This is where people conflate most. The three words point at different things.

A taxonomy is a hierarchical classification. It hangs concepts on a tree through a single is-a relation. Library classification or product categories work this way.
An ontology, in Ontotext's definition, is "a formal description of knowledge as a set of concepts within a domain and the relationships that hold between them." Unlike a taxonomy, it "expresses relationships and enables users to link multiple concepts to other concepts in a variety of ways." It is a multi-directional web of relations, not a single hierarchy.
A knowledge graph is that ontology applied to actual facts. As Ontotext puts it, "the ontology data model can be applied to a set of individual facts to create a knowledge graph." The ontology is the schema; the knowledge graph is real data populated against it.

Taxonomy (classify): one hierarchy. is-a only.
  Asset
   +- Pump
   +- Motor

Ontology (schema): concepts + "kinds of" relations. multi-directional.
  Asset      --hasPart-->      Part
  WorkOrder  --services-->     Asset
  Technician --qualifiedFor--> AssetType

Knowledge graph (facts): the ontology applied to real data.
  Pump#A17 --hasPart--> Seal#9        (a single fact = node + edge)
  WO#4421  --services--> Pump#A17

In one line: the ontology "sets the stage for the knowledge graph to capture the data" (Ontotext). So "let's build an ontology" and "let's build a knowledge graph" are different jobs — one is schema design, the other is a data pipeline.

The Formal Stack — RDF, RDFS, OWL, and schema.org

To do a formal ontology properly, you learn the three layers of the semantic web stack.

RDF is the triple model. Every fact is written as (subject, predicate, object), and each element is globally identified by a URI. The point is to "detach data from its schema" so multiple sources join as one.
RDFS (RDF Schema) adds classes, properties, and a hierarchy via things like subClassOf. That is schema at the taxonomy level.
OWL adds logic. Classes, object properties (individual-to-individual), datatype properties (individual-to-value), and individuals. On top come logical constructors (and/or/not, as in "Mother = Woman AND Parent"), cardinality ("hasChild max 4"), inverse, transitive, functional, and symmetric properties, and disjointness declarations. Crucially, a reasoner can "automatically compute consequences" from these rules and discover facts a person would not have spotted.

Want a concrete, real instance? Look at schema.org. Launched in June 2011 by Bing, Google, and Yahoo, joined by Yandex that November, this vocabulary today holds 823 types and 1,529 properties and is the de facto standard for embedding structured data in web pages. It is proof that ontologies are not an academic toy but infrastructure running search every single day.

The Operational Stack — Property Graphs and Palantir's Ontology

What an FDE actually ships is usually not an OWL file but a property graph. A Neo4j-style labeled property graph (LPG) has four pieces — nodes (the domain's discrete objects), labels (classifying what kind of node), relationships (directed, typed edges), and properties (key-value pairs on both nodes and relationships). That last part is the decisive difference from RDF triples. In RDF, attaching a property to an edge requires a workaround (reification); in an LPG, a relationship simply carries properties. For operational queries and graph traversal, that is far more convenient.

The industrial summit of this operational ontology is Palantir Foundry's Ontology. Palantir's docs call it "an operational layer for the organization" and a "digital twin of the organization," split into two categories.

Semantic elements — object types, properties, and link types. You define your organization's meaning by "mapping existing datasources into objects, properties, and links in the Ontology."
Kinetic elements — action types, functions, and dynamic security. This is where it departs from an ordinary graph database. An action type not only reads the graph but takes an operator's decision and changes it.

Same fact: "work order 4421 services pump A17"

RDF triple:      wo:4421  ex:services  asset:A17 .
Property graph:  (:WorkOrder {id:4421})-[:SERVICES]->(:Asset {id:'A17'})
Palantir object: WorkOrder(4421) --link:services--> Asset(A17)
                 + ActionType: "mark service complete" mutates state

The core difference is the verb. A formal ontology describes how the world is; an operational ontology also captures what you can do on top of it.

When Is a Formal OWL Ontology Worth It?

So when do you reach for heavy OWL, and when is a pragmatic property graph enough? The honest decision criteria:

When a formal ontology (RDF/OWL) earns its keep:

When multiple organizations or systems must share the same meaning — standard vocabularies, regulatory reporting, cross-institution data exchange, anywhere interoperability is the essence. That is exactly why schema.org works across the whole web.
When reasoning creates real value — when "what logically follows from these rules?" is the business question. Rule-based classification in regulatory and compliance domains, where the rules change often, is the classic case.
When the meaning must be long-lived and shared across teams for years.

When a pragmatic property graph is enough:

When, inside one organization, the goal is to answer defined questions fast and to traverse and operate the graph. The vast majority of FDE projects live here.
When relationships carry a lot of attributes (when, who, how much) and, above all, speed matters.

A rough rule: if a reasoner running overnight would surface no genuinely new facts, OWL's logical machinery is mostly cost. In that case a schema'd property graph is the more honest choice.

The Failure Mode — A Beautiful Ontology Nobody Uses

Now the most important section of this post. The common failure of an ontology is not a wrong model but a perfect model that goes unused.

The symptoms are always similar. A six-month ontology committee convenes, an elegant class hierarchy containing every concept in the universe gets drawn, the presentation earns applause — and after that, nobody queries it. Either the data was never connected, or it is disconnected from the business questions, or both. It was modeled for completeness, not for use.

The remedy is to reverse direction. Start from questions, not concepts. Not from the class diagram on the whiteboard, but from the list of questions the business cannot answer today and is frustrated by. For instance — "which assets are most likely to fail next quarter?", "which qualified technician is available for this work order right now?", "what parts, and how many, should we stock at depot X?" Model only the objects and relations needed to answer those, and defer the rest until a question demands it.

One more discipline: an ontology should grow connected to real data. An ontology that never touches data is just an unvalidated hypothesis. Like the ubiquitous language, an ontology should be a living artifact that keeps evolving.

Closing — From Questions, Not Concepts

To sum up: an FDE turning a domain into a model is a ladder. The floor is the near-free ubiquitous language — building a rigorous shared vocabulary with domain experts. Above it, bounded contexts handle the collisions of the same word, and entities, value objects, and aggregates give the nouns structure and consistency boundaries. Higher up sit the formal stack (RDF/RDFS/OWL) and the operational stack (property graphs, Palantir-style objects plus links plus actions), and which you choose comes down to whether interoperability and reasoning are genuinely needed.

And one most-honest piece of advice: do not rush toward the higher rungs. Most of the value comes from the bottom two — shared language and clear boundaries. Every time the urge to build an ontology strikes, ask this: "which question that the business actually asks does this model answer?" If there is no answer, that is the signal that what you should build right now is not an ontology.

A well-built knowledge graph is not an end in itself but the foundation for the next step. Using that graph as the substrate for LLM retrieval — Graph RAG and knowledge-graph construction — continues in Production RAG Patterns.