Ontology
Explains what it means to attach meaning to a table and how an ontology differs from a schema.
Open the participation table and four columns appear: emp_no, prj_cd, rl_cd, join_dt. emp_no looks like an employee, but nothing in the table says what rl_cd is. A dataset gives you column names and types and stops there, so the meaning is re-interpreted with every question. An ontology is the layer where that interpretation is written down once, outside the table.
Once an ontology is defined, emp_no becomes the identifier of the concept employee, and the same employee scattered across several tables is treated as one object. A schema fixes the shape of the data; an ontology fixes what the data means.
What the schema cannot answer
A schema tells you that emp_no is text and cannot be empty. That is enough for a machine to store and validate the data.
It falls short when a person asks a question. Whether emp_no in the participation table and staff_id in the team roster point to the same object, or whether one row means one employee or one assignment, is not in the schema. That reading usually lives in someone's head or in a query comment, and it has to be asked again when that person moves on. The ontology is the place to leave the reading next to the data.
Meaning written in three layers
In an ontology, one concept carries a name, an alias, and a description. Each serves a different reader.
| Item | Who it is for |
|---|---|
| Name | The identifier the system references. It does not change after creation |
| Alias | The label a person reads on screen |
| Description | A sentence recording what this concept refers to |
That the name is fixed after creation is a property rather than a limitation. References must not break, so the identifier stays put while the human-facing wording moves to the alias. The description looks minor but is where an ontology parts ways with a schema. One sentence such as an employee on staff, identified by employee number saves the next person from asking the same question.
One ontology per collection
An ontology is not a separate store but a layer attached to a collection. Creating a collection creates its ontology scope, and every entity and relation belongs to a collection.
This makes the validity range of meaning identical to the collection. A project defined in an HR collection and a project defined in a sales collection can be different concepts despite the shared name, and the system does not mix them. If a concept must be shared, reviewing the collection layout is better than forcing the ontologies to match.
Model and data move separately
Defining an ontology does not create a single row. Building the structure and filling in real data are separate acts, and the filling is done by pipelines.
Ontology design therefore does not have to wait for the data to be complete. Once you decide which concepts exist and how they are distinguished, the concepts survive later changes to the source tables. Collect data first and attach meaning afterwards, and the table layout becomes the concept, so the reading shifts every time the source changes.