From Object-Oriented Programming to Ontology: A Step-by-Step Learning Guide

Recently, I have been learning about Palantir's Ontology while also looking at IBM's thinking on semantics and business planning models. One question gradually came into focus: if both give data business meaning, describe relationships, and capture rules, are they essentially doing the same thing?

That question makes a useful starting point for learning about ontology.

If you know a little object-oriented programming, the words "objects, properties, relationships, and actions" can feel familiar. Equipment is a class, a particular pump is an instance, temperature is a property, and maintenance is a method. Seen this way, it can seem as though you already understand most of it.

The analogy is useful. The next question is what really needs explaining: when multiple systems, people in different roles, and AI all use these objects, how do they establish that they mean the same thing and operate on it under the same rules?

Learning about ontology can start here.

First, a note on scope. In knowledge engineering, an ontology describes the concepts in a domain, the relationships between them, and which statements hold. It can be expressed in a formal language so that software can process it and reason with it. This article focuses on ontology modeling in enterprise software, using Palantir as an example to explain how a model connects to data and supports queries and business operations. Ontology in the philosophical sense is outside the main path here. SourceW3C: OWL 2 Primer ^[1]

Start with Equipment, Work Orders, and Engineers

Suppose we want to build an equipment maintenance system.

The initial requirements are simple: find equipment showing problems, create maintenance work orders, assign engineers, and complete the repairs. There is no need to choose a database or open an SDK yet. Start by writing down three nouns:

• Equipment
• WorkOrder
• Engineer

With an object-oriented design, we might give equipment an ID, a name, and an operating status; work orders a fault description, a creation time, and a processing status; and engineers a name and a specialty.

These give us a ready foundation for understanding ontology.

• Class → Object Type: equipment, for example.
• Instance → Object: the pump identified as P-003, for example.
• Field → Property: operating status or installation location, for example.
• References between objects → Link: a work order concerns the repair of a particular piece of equipment, for example.
• A group of instances → Object Set: all equipment awaiting repair, for example.

Palantir's distinction between object types, objects, and object sets broadly follows this idea: a type describes a shared structure, an object represents a specific entity or event, and a set represents a group of objects. SourceOfficial documentation on object types ^[2]

Once the nouns are familiar, though, the questions need to become more precise.

Does "equipment" mean a product model or an individual machine installed on site? If a pump's motor is replaced, is it still the same piece of equipment? Can one work order cover several machines? Can an engineer be responsible for several work orders at once?

The answers change the model.

For example, it is better to distinguish "a particular pump model" from "pump P-003 on site." The former describes the specifications of a type of product. The latter has its own installation date, maintenance history, and operating status. Combine them in one object, and you can end up with puzzling data such as "this product model has been repaired three times."

The first step in ontology modeling is to decide exactly what we are describing, and at what level of detail.

The nouns sound simple. Their boundaries often lie in the details.

Once we have the objects, we can write down the relationships:

• Work order W-017 → concerns the repair of → equipment P-003
• Work order W-017 → is assigned to → engineer E-008
• Equipment P-003 → is installed in → Building A

Each arrow has a specific meaning. A repair relationship and an installation relationship do not become the same kind of relationship just because both connect two nodes. We also need to define their direction, cardinality, and whether a relationship may be temporarily absent. A newly created work order, for example, may not yet have an assigned engineer.

This is why drawing a relationship diagram completes only part of the work. Drawing lines is easy. Explaining exactly what each line allows takes us back to the business itself.

Keep the Object Connected to Its Real-World Counterpart

Putting the model into real data brings up another set of questions.

Continuing with this hypothetical case, the equipment register identifies the pump as P-003, the monitoring system uses sensor_17, and the maintenance records call it "pump number three."

A person may know that all three refer to the same machine. A program needs an explicit basis for making that connection.

We therefore need to establish a stable identity for the equipment and map records from different sources to it. Then we need to determine where its name comes from, who maintains its operating status, when sensor readings were collected, and how to handle conflicting sources.

At this point, the OOP analogy needs something added to it. Creating an instance in a program gives us an object representation inside that program. An object in an enterprise ontology also needs to keep corresponding to the same thing in the business world over time.

Being about the same object does not make every piece of information equally current or equally reliable.

For example, the monitoring system's last reported temperature might be 85°C, but the reading was taken yesterday. If the interface simply displays "85°C," users can easily mistake a historical reading for the current state.

When starting out, we can treat the latest temperature and its collection time as equipment properties. If the question later becomes "how did vibration change over the past week?", we can introduce a time series or separate observation records. The model expands with the questions it needs to answer.

An ontology does not automatically fix these data problems. It provides a way to organize and use data, while object identification, data quality, and update rules still need careful design.

This work may seem less appealing than "intelligence," but it directly determines whether the analysis built on top of it can be trusted.

From Changing a Field to Completing a Business Operation

Now the equipment needs to be repaired.

In a simple program, we might write:

work_order.status = "closed"

The line is easy to understand, but it leaves several business questions unanswered. Who may close the work order? Have the repair results been entered? Is acceptance required? What related information also needs to change once the order is closed?

Palantir's Actions can define the changes to objects, properties, and relationships involved in a business operation, along with the relevant parameters, logic, and validation. SourceOfficial documentation on Actions ^[3]

For this exercise, suppose we define a "complete maintenance" action:

• Inputs: the work order and the repair results.
• Conditions: the work order is in progress, the person performing the action has the required permissions, and the repair results are not empty.
• Changes: save the repair results, record the completion time, and change the work order status to awaiting acceptance.

I have deliberately kept "awaiting acceptance" here. It means that an engineer finishing the work and the business confirming completion are two different states. If the actual process does not require acceptance, we can simplify it. If it does, the model should express that.

We can also distinguish Functions from Actions at this point.

A Function implements calculations or business logic, such as calculating equipment risk or selecting candidate engineers. Under the applicable mechanisms, it can also support ontology edits. An Action organizes a business change into an operation that can be called, and a complex Action can be backed by a Function. So it is not accurate to treat every Function as "read-only," or to think of an Action as just an ordinary method on an object. SourceOfficial documentation on Functions ^[4]

There is another easily missed fact: updating a work order's status to "completed" does not prove that the equipment on site has actually been repaired. If the operation also writes back to an external maintenance system, we must check whether that system successfully received the update.

Software records, synchronization between systems, and outcomes in the real world each need their own evidence.

Ontology as a General Concept and as a Product Implementation

By now, we have encountered two layers: one describes the business world, while the other defines how to change business state in the system.

Palantir includes objects, properties, relationships, Actions, Functions, and capabilities such as dynamic security within its Ontology, forming an operational layer for an organization. SourcePalantir Ontology overview ^[5]

But we should not extend this product definition to every ontology.

Ontology modeling in general does not have to include workflows, writeback capabilities, or a permissions engine. Palantir's decision to bring these capabilities together within one product system is an engineering and product choice.

Object-oriented programming can also support complex business systems shared across an organization. Ontology has not suddenly made everything that was previously impossible possible. A more useful comparison asks where business definitions live, how many applications can reuse them, how changes propagate, who maintains them, and whether failures can be traced.

For a small tool, a few classes, a database, and clearly defined business services may be enough. As more people and applications become involved, the value of explicitly managing shared business definitions becomes easier to see.

What IBM's Semantics and Business Planning Models Have in Common with Ontology

This also explains the sense of familiarity I had when I first encountered IBM's thinking on the subject.

IBM's approach involves semantic recognition in natural language, metric definitions, dimensions, calculation rules, and planning models. It also includes capabilities such as data entry and budget writeback.

Treating it as a tool that "translates questions into queries" would therefore understate its scope. It also organizes the business rules needed for analysis and planning into reusable models.

SourceIBM

Using the maintenance example, we can distinguish the two modeling perspectives like this:

A business planning model might focus on maintenance costs for a particular building, month, and budget version, how to allocate those costs across equipment or departments, and how additional maintenance spending would affect business results.

An object model might start with pump P-003, connect it to work orders, people, spare parts, and statuses, and then define the relevant operations.

This compares the focus of the models, not the limits of their capabilities. A multidimensional model can incorporate detailed records, and an object model can support aggregation and calculations. In practice, the two perspectives can also work together.

I therefore see their shared purpose as organizing business meaning that an enterprise already knows, but that is scattered across systems and people's experience, into models that software can use consistently.

Whether their permissions, versioning, change consistency, and execution across systems are comparable requires a closer look at the implementations. An architecture diagram can explain the design intent; it cannot stand in for operational results.

What Semantic Parsing, Ontology, and Knowledge Graphs Each Do

The relationship between semantic parsing and ontology now becomes easier to explain.

Someone asks, "Which machines have needed repeated repairs this month?"

Semantic parsing needs to turn this sentence into a precise query intent: what time period to use, whether "repeated" means two or more repairs or three or more, and whether to count work orders created or repairs actually performed.

The ontology and the related business rules need to establish beforehand what counts as equipment, what a maintenance work order is, whether one work order corresponds to one repair, and which statuses are included in the count.

The query program then retrieves data using those definitions.

If the company has not agreed on what "repeated repairs" means, the model should state the definition it is using and ask for clarification when necessary. Letting AI choose an answer does not make the disagreement go away.

Knowledge graphs can also be confused with ontology here. As an introduction, it helps to think of an ontology as focusing on concepts, relationships, and their meanings, while a knowledge graph connects specific entities and facts in a knowledge representation. This is only a useful distinction for learning, though. A real system can keep the model and the facts together, and an ontology can also contain statements about specific individuals. SourceW3C: ontologies, classes, and individuals ^[1]

A graph database, meanwhile, is a storage and query technology. Even after the database has been chosen, someone still needs to explain the business definitions of equipment, work orders, and repair counts.

AI Can Use These Definitions, but It Still Needs Evidence

Adding AI makes these definitions more useful, and also easier to expect too much from.

In the maintenance system, AI could query equipment based on a user's question, follow relationships to find work orders, call a risk calculation, and then suggest an assignment. If it is allowed to act, it still needs to go through the appropriate operation interfaces and permission checks.

This reduces the need for the model to guess table structures or assemble business definitions on the fly. But providing an ontology does not mean that AI now understands the entire business.

Suppose repairs to P-003 have recently become more frequent, and a nearby production line has also experienced downtime. The model can help us find both sets of facts, but the association alone cannot establish that "the pump caused the downtime." A causal judgment still needs fault records, the sequence of events, and other evidence.

Similarly, configuring "add equipment to the inspection list when its temperature exceeds a threshold" gives us an explicit business rule. Predicting failures from historical data is a separate modeling task. Explaining the results in language is another capability again. Distinguishing them helps us understand where a conclusion actually comes from.

I think this is a useful habit to keep while learning about ontology: whenever a result looks clever, ask one level further down. Is it an existing fact, a rule defined by a person, a calculation, or a model inference?

Bring the Concepts Together with a Small Exercise

If you want to study this systematically, I suggest turning the maintenance case into a small exercise and working through it in the following order. Leave something you can check at each step.

1. Write the questions first, then define the objects. Choose just three questions: which machines need repair, which work orders remain unassigned, and which machines have been repaired more than twice in a month. Define equipment, work orders, engineers, and their relationships around those questions. Leave unrelated concepts outside the model for now.
2. Prepare a little data to check identities and definitions. Three machines, five work orders, and two engineers are enough. Deliberately include an equipment alias, an unassigned work order, and an outdated reading. Check whether the model can express each clearly. At this point, read the official explanations of object types ^[2] and link types ^[6] alongside your exercise.
3. Define one complete operation. Choose "assign an engineer" and specify its inputs, permissions, preconditions, and results. Then list the cases that should fail: the engineer does not exist, the work order is closed, or the person performing the action lacks permission. As you read the Actions documentation ^[3], match each of these questions to the relevant explanation.
4. Connect an application and perform queries and changes. If you have a Foundry environment, use a language you know and OSDK to query equipment, read its linked work orders, and call an Action. If you do not have an environment, you can first simulate the same interfaces locally. Be clear about what that proves: the simulation validates your own model and logic, while the platform's runtime behavior still needs to be studied separately.
5. Put the model through a change. For example, allow several engineers to collaborate on one work order, or add acceptance to "complete maintenance." Observe how the data, queries, and operations need to change. Being able to handle this often tests your understanding better than making the initial relationship diagram look polished.

The OSDK documentation fits naturally into step four. OSDK provides types and interfaces generated from the ontology so that applications can access its capabilities. With the objects and operations already defined, each name in the SDK has a concrete meaning. SourceOntology SDK overview ^[7]

After completing the exercise, decide where to go deeper.

If your goal is to develop enterprise applications, you can continue with interfaces and polymorphism, object set queries, permissions, data updates, and model version management. If knowledge representation and automated reasoning interest you more, you can follow the path through RDF, RDFS, and OWL.

The two paths overlap, but there is no need to learn all of formal logic before creating your first maintenance work order. When you get to OWL, you will encounter a distinction that deserves particular attention: the absence of a recorded fact does not directly mean that the fact is false. This differs from the default behavior of many business programs, and should not be assumed to apply to every platform. SourceW3C: OWL's open-world assumption ^[1]

At this point, we can return to the original object-oriented analogy.

"Equipment is a class, and a pump is an instance" still holds, at least as a useful introduction. What we have added is how different systems identify that pump, where its status comes from, how work orders relate to it, and who can change those records under which conditions.

I would keep my own first learning outcome small: find a machine showing a problem, explain the evidence for that judgment, create a work order that follows the rules, and confirm the result of the operation.

Once that process works, "objects, relationships, rules, and actions" become more than a few familiar words. The next time I see "enterprise ontology," I have something concrete to question, one part at a time.