How to Create an Ontology from an Existing Database
Key takeaways
- A schema gives you most of the structure and none of the agreement.
- Generate the first draft automatically. The value is in what people change afterwards, not in the generation.
- Foreign keys become relationships, but only a person can say which ones carry business meaning.
- Do one schema, not the estate. The instinct to do all of them is what kills these programmes.
If you want to know how to create an ontology from a database, the honest first answer is simple. Point a model at the schema and see what comes back. That is a good first step. It takes minutes, and anyone warning you off it is making this harder than it is.
What follows is what happens after that draft lands, because the draft is a candidate and not yet a model anyone can rely on.
How much of it do you already have?
More than you think, and the people saying so are not all on the same side of this argument. A substantial fraction of an ontology already exists in the systems you own, distributed across schemas, reference tables, validation rules and glossaries that were written for other reasons. The work is consolidation more than creation. That is broadly right.
There is a stronger version worth taking seriously. The semantics are already present in how the data gets used, which "transforms semantic modeling from coding into curation." Also largely right, and it describes most of the work accurately.
The automated route is fast and getting faster. One vendor markets going from a plain-English description to a deployed, governed model "in hours, replacing the six-to-thirty-six-month projects", It pairs generation with automated validation. It does not claim generation alone. That is a harder claim to dismiss than pure generation would be, and dismissing it would be wrong.
So the question is not whether to derive. It is what derivation leaves out.
How do you turn a schema into an ontology? Seven steps
1. Inventory what the database already asserts. Primary and foreign keys, uniqueness and check constraints, enumerations, not-null rules, naming conventions. A well-constrained schema contains more of an ontology than its owners usually realise, and this inventory is also the honest measure of how much work is left.
2. Generate a first draft. Use the tooling. This step is commoditised and pretending otherwise is not credible. If you want the established method vocabulary, published cloud-vendor guidance covers R2RML, OBDA and Ontop. The path for mapping relational data into this shape is mature and well documented.
3. Resolve entities before anything else. The same rule as building an ontology for AI, and more acute here. A database carries the same real-world thing under different keys in different tables, and a different key again in the system next door. Until customer means one thing, every relationship you model on top of it is a relationship between the wrong things. Nothing will error to tell you so.
4. Lift the relationships the schema cannot express. This is where most of the value is, and it is the step a generated draft does worst.
A foreign key says two rows are related. It does not say how. It never says that a helicopter is an aircraft, so anything true of aircraft is true of helicopters without a join. It cannot carry a constraint that travels with the meaning, so the rule survives being loaded somewhere else. And it says nothing about identity across systems. Those three things are the difference between a data model and an ontology. They are also exactly what cannot be derived from a schema that never contained them.
5. Take the draft to the people who own the terms, and record what they decide. A generated model is a description of what the database currently does. It becomes authoritative when somebody with standing agrees to it, and writes that agreement down. What was decided. Who decided. What it replaced. When it gets looked at again.
This is not ceremony. The schema encodes decisions nobody remembers making, some of which were workarounds for a system that was decommissioned years ago. The review is where those get noticed, and it is the only step that produces anything the organization can stand behind later.
6. Constrain with SHACL and validate against real data. Validation will immediately show you where the model and the data disagree, and on a first run the model is usually the one that is wrong. That is a cheap and useful way to find out that the agreement in step 5 was less settled than it sounded.
7. Keep a mapping back to the source. So that when the schema migrates, the divergence is detectable. Without it you have a model that was true about a database that no longer exists, and nothing will tell you when that happened. Keeping the two in step over time is its own discipline.
What makes this go well
| Schema element | What it usually becomes | The judgement a person has to make |
|---|---|---|
| Table | A class | Is this a business concept, or a storage convenience like a junction or staging table |
| Column | A property | Does it carry meaning, or is it an audit field nobody models |
| Foreign key | A relationship | Is this a real business relationship or plumbing between two tables |
| Check constraint, enum | A SHACL constraint | Is the rule still correct, or did the data outgrow it years ago |
| Primary key | An identifier | Does it identify the thing across systems, or only inside this one |
| Table name | A label | Is this the word the business uses, or an abbreviation nobody can expand |
The right-hand column is the whole exercise. Generation handles the left two reliably and the third badly. It cannot touch the rest. No later release closes that gap. A schema records how data was stored. The questions in that column are about what the organization agreed, and that was never written down there.
Do one schema. Leave the estate alone. The instinct to do all of them at once is the same instinct that kills modelling programmes generally, and it fails for the same reason.
Put the generated draft in version control from the first commit. Then the diff between what the model proposed and what people agreed is visible. That diff is the most valuable artifact the exercise produces. It records precisely where the database and the business disagree, and the rest of the programme runs on it.
What the derived model has to stay connected to
- The schema it came from. A migration upstream should reach whoever owns the affected definition.
- The data, through constraints. Rules you lifted from check constraints become SHACL shapes, and a shape that is never run is a comment.
- The other systems holding the same entities. Deriving from one schema gives you one system's view of a customer, which is the view the whole exercise exists to transcend.
- The people who ratified it. Each decision in the right-hand column above is somebody's call, and it needs their name and the date attached.
Express the result in RDF, OWL, SKOS and SHACL. The modelling tool's own format dies with the tool, and open standards make those connections survive it. The derived model outlives the database it came from, which is usually the point of deriving it.
Reuse a published model where one fits. Deriving everything from local table names bakes in local vocabulary, including the abbreviations nobody can expand any more. Where a standard model covers part of your domain, mapping onto it is cheaper than inventing a parallel one. It also makes the result legible to anyone outside the team.
What goes wrong
A derived model inherits the schema's mistakes. Including the ones the organization has quietly worked around for a decade. Derivation without a review step does something worse than preserving bad modelling. It launders it. A known workaround becomes an authoritative-looking definition with formal syntax around it. Step 5 exists for this.
The slide toward someone else's platform is real, and it is gradual. One practitioner described the whole trajectory in a single paragraph. First, hand-modelled files. Then files generated by pointing an agent across databases. Then serving those files over a protocol so the agent can read them, which "worked well but cumbersome". Then noticing that a lakehouse vendor offers a feature that "automatically scans the datasets and updates the triples and vocabulary."
Every one of those moves is locally sensible. The endpoint is a model that lives in a vendor's runtime, in a vocabulary that vendor defines, refreshed without anyone being asked. That may be the right trade for you. It should be a decision somebody takes.
Do not confuse two different failure modes. A model inventing semantics out of nothing is one problem. A model grounded in actual data usage is a different and better position, and one platform vendor argues for exactly that: a semantic foundation "grounded in data usage, not LLM assumptions." The objection to usage-grounded derivation has nothing to do with accuracy. Usage tells you what people currently do. It does not tell you what anyone agreed they should do, and that is the gap step 5 closes.
A note on where this sits: this page starts from a schema you already have and works toward an agreement. If you are starting from a decision the business is arguing about and working toward a model, that is the other direction, and it is a different method.
So what should I take away?
My schema already encodes an ontology nobody agreed to, and it is running my business right now. Generating the draft is free. The value is what my people change afterwards.
So the generated model is not the deliverable. The deliverable is the diff between what the database asserts and what my experts will sign. Keeping that signed version true as the schema moves underneath it is ontology management, and it is what TopQuadrant builds.
