Enterprise data ontology: a practical guide to documents and ERP
Understand enterprise data ontology through objects, properties, relationships, and shared definitions. Explore assets, products, teams, and a practical document and ERP example.
An enterprise data ontology is a shared model for describing real-world objects and relationships in data. It defines the types of objects involved, their properties, and how they connect. Its scope can include products, equipment, customers, teams, documents, and business processes.
Collecting more records does not necessarily make operations easier to understand. Data fields alone may not explain which tasks depend on an asset, which orders contain a product, or which team owns an activity and follows a particular procedure. An ontology makes those meanings and connections explicit.
Objects, properties, relationships, and definitions
| Element | What it defines | Examples |
|---|---|---|
| Objects | Types and their meanings | Products, assets, teams, activities, documents |
| Properties | Information describing an object | Location, quantity, status, time |
| Relationships | How objects connect | Equipment used in a task, products in an order |
| Definitions | Shared meanings and conditions | Completion, object identity, when a relationship applies |
Defining the type “equipment” is distinct from connecting a particular record for “Asset B.” Establish shared meanings, then connect records using that model. W3C OWL 2 is one language for formal representations; enterprise ontologies do not all have to use OWL.
Its scope extends across industries and data types
The objects and relationships depend on the business question. Facility operations may connect assets, tasks, and inspections. Product supply may connect suppliers, products, inventory, and orders. Organizational knowledge may connect work, teams, and guidance. A manufacturing or service process can also be modeled through its stages, sequence, inputs, and states.
Such a model can support finding evidence and analyzing status or dependencies. Creating it does not automatically provide analytics, prediction, or operational actions. Those capabilities and their data requirements need separate design.
Why companies describe ontology differently
The common core is a model of meanings and relationships. Products differ in the functionality they include under that name. For example, Palantir's Ontology maps data and models to business objects and also encompasses actions and functions. Evaluate modeling, integration, analysis, and operational actions separately instead of assuming that the term implies every capability of a particular platform.
One illustrative document and ERP workflow
Consider a fictional equipment upgrade for Customer A. The contract uses that customer name, while ERP identifies the account as C-104. The project register and sensor-parts purchase order live elsewhere.
| Source | Recorded objects | What to verify first |
|---|---|---|
| Maintenance contract | Customer A and contract terms | Customer identity, contract version, validity |
| ERP account list | Account C-104 | Official name and shared identifier |
| Project register | Equipment upgrade | Related contract and owner |
| ERP orders | Sensor-parts order | Project ID, item, acceptance status |
Similar names are not sufficient evidence that records refer to the same organization. They could represent different legal entities or branches. Agree on an account ID, business identifier, or approved mapping before treating them as one object.
The business question extends beyond finding an order: “Which project does this order belong to, and which contract terms apply?” Answering it requires shared identities, relationships, and original source records. All records in this example are fictional.
What this example needs to define
Objects and properties include customers, contracts, projects, orders, and owners, plus contract versions, validity dates, and order status. Define what each object means and how it is distinguished.
Relationships describe how objects connect. A customer signs a contract; a project runs under that contract; an order belongs to the project. Consider the evidence and effective dates of each connection.
Definitions and rules describe how meaning and results are checked. Specify which contract version applies, what record establishes acceptance, and who reviews an uncertain link.
Establishing account identity is one part of this example. Ontology is not limited to finding duplicate customers; the broader purpose is to model connected work and its applicable meanings and conditions.
A glossary or data model may be enough
A glossary can be a useful starting point when people need a shared vocabulary. For consistent reporting, metric definitions and data models may be the more direct priority.
An ontology becomes worth exploring when questions repeatedly require shared identities, relationships, and exceptions across sources. Select one workflow, such as customers, contracts, and orders, before attempting to model an entire organization. A narrow scope makes acceptance criteria easier to define.
A relationship model does not guarantee a correct answer
An outdated contract, incorrect account mapping, or missing project ID remains a problem after you build a model. Distinguish a confirmed absence of a relationship from records that have not been reviewed.
Source evidence, update times, and access permissions also need separate checks. Permission to view a project should not automatically expose its restricted contract. Accuracy depends on the actual records and retrieval and validation processes, as well as their representation.
What to prepare for an adoption discussion
Bring one business question, a list of relevant records, identifiers that connect the objects, and a person who can confirm the definitions. A concrete scope, such as tracing a sensor-parts order to its project and applicable contract terms, makes the required connections easier to discuss.
Continue with ontology, knowledge graphs, and RAG and the ontology adoption checklist. Wissly Ontology Beta illustrates assets and operations, products and supply, and teams and knowledge, alongside the questions to review for adoption.