What is an ontology, and does your business need one

An ontology is a definition of the entity types that exist in a business, the properties each type carries, the relationships allowed between types, and how types relate in a hierarchy, such as an \"Employee\" being a kind of \"Person.\" It is the structural backbone underneath a knowledge graph: the graph is the actual data.

Ontology versus schema versus data dictionary versus semantic layer

These four terms get used loosely and interchangeably, which causes real confusion, so it helps to separate what each one actually describes.

For the wider context, see our knowledge graph glossary of 40 terms.

A data dictionary is documentation: a list of tables, fields, and what each field means in plain language. It describes data that already exists in a specific system and does not define relationships or enforce anything, it is a reference document for humans.

A relational schema is the structure of a database: tables, columns, data types, and foreign keys that enforce referential integrity within that database. It defines relationships, but only the ones that specific database needs, and only in the shape that database's tables require, joins and all.

A semantic layer sits on top of one or more schemas and defines business metrics in consistent terms, so "revenue" or "active customer" means the same thing no matter which report or dashboard references it. It is focused on calculation consistency for reporting, not on modeling entities and relationships as a general-purpose structure.

An ontology is broader than any of these three. It defines entity types (not specific systems' tables), the properties each type can carry, and the relationships allowed between types, independent of which database or system eventually stores the data. An ontology can describe entities that live in several different systems at once, which is why it is the natural foundation for a knowledge graph that spans a CRM, an ERP, and a support tool together.

A worked mini-ontology for a mid-market company

Consider a mid-market services company. Its ontology might define these entity types and the relationships allowed between them:

Customer has many Accounts (a customer can have multiple billing accounts)
Account has many Orders and many Invoices
Order generates one or more Invoices
Invoice can be linked to zero or more Tickets (a billing dispute, for example)
Customer can raise many Tickets, each Ticket assigned to one Employee
Employee works on one or more Projects
Project is linked to one Account (the account the work is being delivered for)

Each entity type also carries defined properties: a Customer has a name and an industry, an Invoice has an amount and a due date, a Ticket has a status and a priority. The ontology does not store any actual customer's name or any real invoice amount, it defines that these properties are allowed to exist and what type of value they hold. The actual records, "Acme Corp," invoice #4021 for a specific amount, live in the graph itself, resolved from source systems using the techniques described in entity resolution.

This small ontology is already enough to answer a real cross-system question: which accounts with an open billing ticket also have a project currently in progress, a question that touches Ticket, Invoice, Account, and Project without a single new join being written, because the relationships already exist as defined edges.

Who owns the ontology

In practice, ontology ownership sits between whoever understands the business relationships (often operations, finance, or a data lead) and whoever is implementing the systems that generate the underlying data. Neither side alone tends to get it right: a purely technical owner defines relationships that are structurally clean but do not match how the business actually thinks about its entities, and a purely business owner defines relationships that sound right in a meeting but do not map cleanly onto anything a system can enforce.

The healthier pattern is a small group, often one person from operations or finance paired with whoever owns the data platform, that reviews and adjusts the ontology as new questions come up, rather than a single owner who defines it once and moves on. Ontologies that nobody owns tend to drift out of sync with how the business actually operates within a year or two.

The over-engineering failure mode

The most common mistake in ontology work is building an exhaustive, fully generalized model before a single real question has been answered with it. A team spends weeks defining every conceivable entity type and relationship a company might ever need, anticipating requirements nobody has actually asked for yet, and the result is a large, abstract structure that is hard to explain, harder to maintain, and often wrong in ways that only show up once real data and real questions are run against it.

A better sequence is the reverse: start from a specific question that matters right now, define only the entity types and relationships needed to answer it, get an answer, and extend the ontology as the next real question requires a new entity type or relationship. This produces a smaller ontology that matches what the business actually asks, rather than a comprehensive one that matches what someone imagined the business might ask.

When a lightweight generated ontology is enough

Not every company needs a hand-modeled ontology built by a committee. For many mid-market companies, an ontology inferred from the structure of the source systems already connected, a CRM's account and contact model, an ERP's order and invoice model, a support tool's ticket model, covers the entity types and relationships needed to answer most cross-system questions without a dedicated modeling project. A generated ontology like this can be refined over time as gaps appear, rather than designed exhaustively up front.

This lightweight approach trades some precision, a hand-modeled ontology can capture business-specific nuance that a generated one misses, for speed: a generated ontology can support a real answer within minutes of connecting the first system, rather than after weeks of modeling meetings. For a company whose questions are common ones, which accounts are at risk, where is spend concentrated, which projects are behind, the generated version is often sufficient, and hand modeling is best reserved for entities that are genuinely specific to how that business operates.

How an ontology supports inference

Because an ontology defines allowed relationships and hierarchies in advance, a system built on it can infer facts that were never explicitly stated. If the ontology defines that an Employee assigned to a Ticket belonging to an Account means that Employee has worked with that Account, a question like "which employees have the most contact with at-risk accounts" can be answered by traversing the defined relationships, without anyone having manually recorded "this employee has contact with this account" anywhere. This is the practical payoff of the modeling work: a well-defined ontology lets new questions be answered by tracing existing structure, in the same way described in how it works, rather than by collecting new data or writing new logic for each one. Related terms are defined in the concepts glossary.

Comparison: data dictionary vs. relational schema vs. semantic layer vs. ontology

Aspect	Data dictionary	Relational schema	Semantic layer	Ontology
What it describes	Field-level documentation for humans	Tables, columns, and keys in one database	Consistent metric definitions for reporting	Entity types, properties, and allowed relationships
Expresses relationships	No, descriptive only	Yes, but limited to that database's tables	Partially, mostly through metric logic	Yes, as a defined, cross-system structure
Supports inference	No	No	No	Yes, by traversing defined relationships
Scope	Single system	Single database	Metrics layered over one or more schemas	Entities across any number of systems
Maintenance cost	Low, but easily out of date	Moderate, tied to database changes	Moderate to high, grows with metric count	Low if scoped to real questions, high if over-built
Who maintains it	Whoever wrote the documentation	Database or platform engineers	Analytics engineering	Joint ownership between business and data roles

Where SIGNLD fits

SIGNLD maintains an ontology as part of the private knowledge graph it builds from the systems a company connects. Rather than requiring a modeling project before any question can be answered, SIGNLD infers a working ontology from the structure of the connected systems, including spreadsheets treated as first-class sources, and refines it as more systems are added. Connections are read-only across 800+ integrations, a first system typically connects in about 15 minutes, and the first answer, returned as a Decision Brief with the finding, evidence linked to source records, a confidence score, and a recommended action, generally follows within minutes rather than after weeks of ontology design work.

Key takeaways

In practice, ontology ownership sits between whoever understands the business relationships (often operations, finance, or a data lead) and whoever is implementing the systems that generate the underlying data.
Not every company needs a hand-modeled ontology built by a committee.
Most small companies do not need a hand-modeled, formally documented ontology.
A taxonomy is a hierarchy of categories, useful for classification, such as organizing products into categories and subcategories.
An ontology that misses a relationship simply cannot answer questions that depend on it, which usually surfaces as a missing or incomplete answer rather than a visibly broken one.

FAQ

Is an ontology the same thing as a knowledge graph?

No. The ontology is the set of rules, entity types, properties, and allowed relationships. The knowledge graph is the actual data, the specific customers, invoices, and tickets, stored as nodes and edges that conform to those rules.

Do small companies need a formal ontology?

Most small companies do not need a hand-modeled, formally documented ontology. A lightweight, inferred structure covering the entity types already present in their systems is usually enough to answer common cross-system questions, and formal modeling is worth the investment only once specific, recurring gaps appear.

How is an ontology different from a taxonomy?

A taxonomy is a hierarchy of categories, useful for classification, such as organizing products into categories and subcategories. An ontology includes hierarchy but also defines properties and, importantly, the relationships allowed between different entity types, which a taxonomy alone does not cover.

Who should decide what counts as an entity in the ontology?

The people who understand how the business actually operates, often finance or operations, should define which entities matter, while the team implementing the data platform defines how those entities map onto actual source records. Neither group should do this work in isolation.

What happens if the ontology is wrong?

An ontology that misses a relationship simply cannot answer questions that depend on it, which usually surfaces as a missing or incomplete answer rather than a visibly broken one. An ontology that models a relationship incorrectly can produce a plausible-looking but wrong answer, which is why ontology changes should be reviewed against real questions rather than assumed correct on first draft.

Try SIGNLD free to see the ontology SIGNLD infers from your own systems, or see how it works.