Three Names for the Same Customer
Picture this: your ontology has grown past 150 objects, and this happens. Sales built a Customer Object Type. Finance didn’t know it existed, so they built Client — the same concept under a different name. Customer Support went a step further and created a third version, this time in the local language. All three teams think they’re managing “our customer data,” but in reality three separate ontology objects exist side by side. When someone tries to build a revenue dashboard, nobody can confidently say which one is the source of truth.
Here’s why this happens, and how to prevent it.
The Key Difference from SAP — There’s No Code
In systems like SAP, the ID (code) and the description are kept separate. A material code like M-10023 and its description “Stainless Bolt M10” are managed independently, and the coding scheme itself is enforced by the system. No one can casually change the material code format.
Palantir Ontology works differently. There’s only a Name. Because there’s no enforced coding scheme, naming is entirely free-form. Early on, that freedom is an advantage — anyone can immediately give something a name they understand. But that same freedom is exactly what causes problems later.
Why It Falls Apart Over Time
In the early stage, there’s no problem. The team is small and the ontology has few objects, so one or two people can keep track of everything and maintain consistency.
As it scales, three problems appear at once.
- Duplicate creation of the same concept: like the Customer / Client example above, the same concept gets built under a different name by every team that needs it.
- Mixed languages: some Object Types are in English, some in the local language, some mix both. Nothing is searchable, nothing is consistent.
- Inconsistent Property naming: some teams keep the raw DB column name (
EKKO_MATNR), others rename it to a business term (MaterialNumber).
The bigger problem is the cost of fixing it after the fact. Renaming a single ontology object means reworking every Workshop screen, every AIP prompt, and every Link Type that references it. If you later try to merge duplicate customer objects into one, you have to redo every screen and workflow each team built independently in the meantime.
Four Standardization Strategies
1. English first, local language as a supplement
Define Object Type and Property names in English, and record the local-language description separately in the Description field. Keep the name Customer fixed as one thing, and note the local term and any synonyms in the Description. This way, search and references always converge on a single name.
2. Put your naming conventions in writing
Decide whether you’re using PascalCase (PurchaseOrder) or camelCase (purchaseOrder), and document your rules for abbreviations (e.g., “never shorten Purchase Order to PO”) and pluralization (Customers vs. Customer). Without a written document, people rely on “I think we did it this way last time” — and that memory drifts as the team grows.
3. Use business terms, not raw DB column names
Don’t carry over a raw column name like EKKO_MATNR as your ontology Property name. Use the English name that maps to what the business actually calls the field — MaterialNumber, not the source column. The whole point of an ontology is to capture business meaning, not physical data structure.
4. Make searching before creating mandatory
Before creating a new Object Type or Property, require a search to check whether something similar already exists. This single step alone prevents most Customer/Client-style duplication.
Before / After
| Item | Before standardization | After standardization |
|---|---|---|
| Customer concept | Customer / Client (duplicated across teams) | Unified as Customer, local terms noted in Description |
| Property naming | Kept EKKO_MATNR as-is |
Renamed to MaterialNumber |
| New-object process | Each team creates on its own | Mandatory search before creation |
| Naming conventions | Different per team | Standardized on PascalCase, documented |
The Lesson from Practice: The Threshold Is 100–200 Objects
Empirically, these problems start surfacing once an ontology reaches roughly 100–200 objects. Below that, “we can probably keep this straight from memory” still works. Above it, it doesn’t.
The best time to set a standard is at the very start of design, while the object count is still in the single digits. Setting a standard later costs several times more than setting it from day one, because you’re reworking every object that was already built.
Summary
Free-form naming in an ontology gives you speed early on, but that same freedom becomes debt as you scale. English-first naming, documented conventions, business-term-based Property names, and mandatory search before creation — setting these four things up while the object count is still small is far easier than merging fragmented customer objects back into one later.
Frequently Asked Questions
Q. How do I clean up an ontology where naming has already gotten messy? Don’t try to fix everything at once. Start by standardizing the most-referenced core objects (e.g., Customer, Order) first. It’s safer to work outward gradually, checking the Workshop screens and Link Types that reference each object as you go.
Q. Do small teams really need this kind of standard? It might not feel necessary right now, but ontology objects tend to grow faster than expected. A standards document doesn’t need to be more than a single page — it’s worth creating one while you still have only a handful of objects.
Q. What if the English name feels awkward or unintuitive? Add a description with usage examples and how it differs from similar concepts in the Description field. What matters more than the name itself is whether anyone can search for it and confirm what it refers to.