What Ontology Really Is: Starting from "Apple" in an Enterprise Q&A Assistant

Suppose you are building an enterprise Q&A assistant. A user asks, "How much revenue did Apple make last year?"

To answer correctly, the system first has to establish that "Apple" here is a company, not a fruit. Then it runs into a subtler problem: the data is scattered across several systems, and they disagree about what the same word means. In the CRM, a "customer" is a company that has signed a contract. In the billing system, a "customer" is a payment account. In the support system, a "customer" is a person who called in. All three tables are named Customer, and each means something different.

People resolve these differences from context. Machines cannot. For a machine to know what something is, what it relates to, and which rules it follows, it needs an explicit, formal semantic model. That is ontology.

From philosophy to artificial intelligence

The word ontology comes from philosophy, where it studies existence itself: what kinds of things there are in the world, how they are classified, and how they relate to one another. The tradition reaches back to Aristotle's theory of categories.

In the 1990s, artificial intelligence borrowed the term. In 1993, Tom Gruber gave a widely cited definition: an ontology is an explicit specification of a conceptualization. In 1998, Studer and colleagues refined it into a formal, explicit specification of a shared conceptualization.

Four keywords sit inside that definition:

• Conceptualization: abstracting a domain and picking out the concepts and relationships that matter.
• Explicit: writing out the concepts, relationships, and constraints rather than hiding them in code or in someone's head.
• Formal: describing them in a language with strict semantics, so a machine can read them and reason over them.
• Shared: representing the consensus of a team, an industry, or a community—not the private convention of one system.

If you know object-oriented design or databases, start here: an ontology is a bit like a class diagram or an ER model, specifying which types, attributes, and relationships exist. The difference is that every statement in an ontology carries logical semantics, so a machine can derive conclusions that were never written down, and the definition can be reused across systems.

What an ontology is made of

Take a concrete example. The domain is a company, and it contains people, employees, managers, organizations, and departments.

The first element is the class, also called a concept. Classes form hierarchies: a manager is a kind of employee, and an employee is a kind of person. This "is a kind of" relation is called subclass of.

The second is the individual, also called an instance, meaning a concrete thing. Zhang San is a manager; the R&D department is a department. Individuals connect to classes through a type relation.

The third is the property. Object properties link two individuals, as in "Zhang San manages the R&D department" or "Li Si works in the R&D department." Data properties link an individual to a concrete value, as in "Li Si's hire date is March 1, 2021."

The fourth is the axiom, meaning constraints and rules. For example, the domain of "manages" is Manager and its range is Department; every employee works in at least one department; and people and departments are disjoint—nothing can be both a person and a department.

Class and property definitions plus axioms form the data layer of the ontology, known in description logic as the T-Box. The concrete individuals and facts form the assertion layer, the A-Box. Remember these two terms; they come back when we discuss knowledge graphs.

What language expresses it

An ontology needs a standard language. W3C developed a set of standards in its Semantic Web project, usually drawn as a layer cake. Read it from the bottom up.

The bottom layer is the IRI, which gives every thing a globally unique identifier. As long as two systems use the same IRI, they mean the same thing—the foundation of cross-system data integration.

Above it is RDF. RDF represents all knowledge as triples of subject, predicate, and object. "Zhang San manages the R&D department" is one triple; many triples linked together form a graph.

RDFS adds the most basic schema vocabulary on top of RDF: classes, subclasses, and the domain and range of properties. With that alone you can describe a simple class hierarchy.

OWL (Web Ontology Language) is grounded in description logic and is more expressive. It can declare disjoint classes, cardinality restrictions, inverse properties, and transitive properties, and it can compose existing classes into new ones.

Here is an ontology written in a special syntax. The first two lines define the classes Employee and Manager and their subclass relation; the middle defines the domain and range of the "manages" property; the last two lines are facts about Zhang San.

Queries use SPARQL, which reads like SQL but matches graph patterns. Data validation uses SHACL, which can check constraints such as "every employee must have a hire date."

There is a pitfall engineers step into easily here: OWL adopts the open-world assumption. In a database, a missing record is often taken to mean the statement is false. In OWL, what is not written down is merely unknown—not false. For example, the ontology says every employee works in at least one department, while Li Si's data has no department. A database constraint would raise an error, but an OWL reasoner concludes that Li Si must belong to some department and simply does not yet know which one. If you want to check whether the data is complete, use SHACL, which validates under a closed-world approach.

Reasoning: the biggest difference from ordinary data models

A reasoner reads the ontology and the data and automatically derives implicit facts according to logical rules. A few patterns are common.

First, reasoning along the class hierarchy. Zhang San is a manager, a manager is a subclass of employee, and an employee is a subclass of person. So the reasoner can conclude that Zhang San is also an employee and a person.

Second, reasoning from domain and range. Suppose the data contains only "Wang Wu manages the marketing department" and says nothing about who Wang Wu is. Because the domain of "manages" is Manager and its range is Department, the reasoner infers that Wang Wu is a manager and the marketing department is a department.

Third, reasoning from property characteristics. "Reports to" can be declared transitive: if the test group reports to R&D, and R&D reports to the technology center, then the test group also reports to the technology center. "Manages" and "is managed by" can be declared inverse, so writing one direction makes the other hold automatically.

A reasoner can also check consistency. If someone labels the R&D department as a "person" while the ontology says people and departments are disjoint, the reasoner reports a contradiction. It is like running unit tests over your data at the logical level.

Common reasoners include HermiT, Pellet, and ELK. Note that the more expressive the language, the higher the computational cost of reasoning. That is why OWL 2 defines three sublanguages—EL, QL, and RL—to trade expressiveness against performance. EL suits large medical terminology bases, QL suits query rewriting over relational databases, and RL suits implementation with a rule engine.

Five areas where ontologies actually land

The first is biomedicine, the most mature application area. The Gene Ontology describes gene function with unified terminology, split into three branches—molecular function, biological process, and cellular component—and researchers worldwide use it to annotate data. The clinical terminology system SNOMED CT contains more than 350,000 concepts and is used for electronic health record coding; its logical definitions are expressed in OWL.

The second is Schema.org. Google, Microsoft, Yahoo, and Yandex launched it jointly in 2011, defining hundreds of types such as Product, Organization, Event, and Recipe. When sites embed this markup in their pages, search engines can understand the content and show rich results such as prices and ratings.

The third is enterprise data integration. In finance, FIBO defines concepts such as contracts, securities, and counterparties through a unified financial business ontology. Data platforms like Palantir use an ontology as a semantic layer: they map data scattered across systems into business objects such as orders, customers, and equipment, along with their relationships, and then build analytics and applications on top.

The fourth is industry and the IoT. In a digital twin, the ontology describes the relationships among equipment, sensors, and spatial locations. W3C's SOSA and SSN ontologies specialize in sensors and observations, while Brick Schema describes the equipment and measurement points in a building.

The fifth is new uses in the era of large language models. One is constraining information extraction with an ontology, letting an LLM pull triples from text according to predefined classes and relations so the output is more consistent. Another is GraphRAG, where the ontology determines the structure of the knowledge graph and helps retrieve more relevant context. The third is giving agents a semantic layer so they understand business concepts and executable operations accurately, reducing the chance of error.

How ontology differs from a knowledge graph

In 2012 Google launched its Knowledge Graph with the slogan "Things, not Strings"—identify things, not just character sequences. The term caught on. At its core is a large graph of entities and relations, such as "Da Vinci created the Mona Lisa" or "the Mona Lisa is held by the Louvre."

In the terms above, an ontology is mainly the T-Box: it defines which classes and relations exist and which rules apply. A knowledge graph is mainly the A-Box: a large number of concrete entities and facts, usually with a schema layer—and that schema layer is often an ontology.

In engineering terms, an ontology is like a database schema plus constraints and business rules; a knowledge graph is like a database populated according to that schema. Or: the ontology is the city plan, and the knowledge graph is the city once it is built.

Look at a few dimensions:

• Focus: ontology cares whether concepts and semantics are accurate; a knowledge graph cares whether facts are comprehensive and connections rich.
• Scale: ontologies typically have tens to tens of thousands of classes, while the facts in a large knowledge graph can reach billions.
• Construction: ontologies are generally designed top-down by domain experts and emphasize consensus; knowledge graphs are mostly extracted bottom-up from databases, web pages, and text, emphasizing coverage and automation.
• Technology: ontologies use RDFS, OWL, and reasoners; knowledge graphs can live in RDF triple stores or, commonly, in property graph databases such as Neo4j, which usually lack formal semantics.

The two are not opposed. DBpedia is a good example: it extracts massive numbers of entities from Wikipedia—that is a knowledge graph—and it also maintains the DBpedia ontology, which defines hundreds of classes such as Person, Place, and Work—that is an ontology. The ontology gives the knowledge graph semantics and constraints; the knowledge graph grounds the ontology in real data.

When choosing, judge it this way: if you need to unify semantics across systems, check consistency, or perform logical reasoning, the ontology is the focus. If the goal is question answering, recommendation, search, or retrieval augmentation for an LLM, you can start with a knowledge graph and strengthen its ontology layer as needed.

How to start building one

A common approach begins with competency questions: first list the questions the ontology must answer, such as "which departments' employees are involved in a given project," and use them to set the scope. Then reuse existing ontologies as much as possible—Schema.org, FOAF, FIBO—rather than reinventing the wheel. Next, organize the terms, build the class hierarchy, define properties and constraints, and enter instances. Finally, validate with a reasoner and SHACL, then iterate back to the competency questions.

For tooling, Protégé from Stanford University works for modeling, RDFLib in Python or Apache Jena in Java for programming, and GraphDB, Stardog, or Amazon Neptune for storage and querying. You can also have an LLM draft the terms and class hierarchy first and then have a domain expert review it.

Beginners make three common mistakes:

1. Modeling a part as a subclass. For example, modeling an engine as a subclass of a car, when an engine is a component of a car.
2. Confusing classes and instances. The R&D department is an instance of Department, not a subclass of it.
3. Over-modeling. Trying to be comprehensive from the very start.

Summary

An ontology is a formal, explicit specification of a shared conceptualization. It is composed of classes, individuals, properties, and axioms, expressed with RDF, RDFS, and OWL, and it uses reasoners to derive implicit knowledge. A knowledge graph is a graph carrying massive facts, and the ontology is its semantic skeleton. Once you understand ontology, looking at knowledge graphs and enterprise semantic layers reveals the common logic behind them.