Ontology Design from Scratch: Building a Reasoning-Ready Business Semantics Layer

Core thesis: The problem is usually not the model. It is the absence of a shared, computable, constrainable layer of business semantics. Angle: From first principles to something runnable: five core parts, 12 design dimensions, an eight-step process, and how an agent should use an ontology.

1. Introduction: why learn ontology at all?

If you have worked on enterprise AI, data integration, or agents, this will feel familiar:

The same task, the same model, the same tools, the same data — and the results vary. The agent sometimes treats “cost centre” and “department” as one concept, sometimes conflates “product model” with “material code”. Run several agents in parallel and each insists it is right, while the conclusions contradict each other.

The problem is usually not the model, but the absence of a shared, computable, constrainable layer of business semantics. That layer is the ontology.

An ontology is not “a pretty relationship diagram”, and it is not “database tables copied into JSON”. It is a formal model of a domain: which concepts exist, how they relate, which states are impossible, how data maps onto them, and how agents may use them safely.

This article moves from beginner to advanced:

• Beginner: what an ontology is, what it is not, and its five core parts
• Intermediate: 12 design dimensions, an eight-step process, constraints and reasoning
• Advanced: time, identity, versions, multi-tenancy, provenance
• Production: agent tool contracts, RAG versus ontology, a maturity roadmap

2. Beginner: what exactly is an ontology?

2.1 One-sentence definition

An ontology is a formal description of the concepts, relations, constraints, and instances of a domain, so that humans and machines share a reasoning-ready understanding of it.

Unpacked:

• Class: which types exist in the domain, e.g. Account, JournalEntry, Party.
• Relation: how concepts connect, e.g. JournalEntry posts JournalLine.
• Axiom / Constraint: what must hold and what cannot, e.g. every journal entry's debits must equal its credits.
• Instance: a concrete object, e.g. the rent entry dated 2026-10-21.

2.2 TBox versus ABox

The single most important distinction in ontology engineering:

Layer	Name	Content	Example
Conceptual	TBox (Terminology Box)	Classes, relations, axioms, constraints	“A JournalEntry has at least one JournalLine”
Assertion	ABox (Assertion Box)	Concrete objects and facts	“JE#20261021-001 is a JournalEntry”

Many teams fail by mixing the two: hard-coding one invoice's amount into the schema, or smuggling business rules into a table. The result: rules cannot be reused, data cannot be validated, and agents cannot reason.

2.3 The Open World Assumption

Under OWL semantics, “not stated” does not mean “does not exist”.

For example: you know ACME is a Supplier, but nothing says whether it is also a Customer. Under the open world, you cannot infer “ACME is not a Customer”; you can only say “unknown”.

This is the opposite of the Closed World Assumption used by databases. In a database, “no row found” usually means “does not exist”; in an ontology, “not found” may simply mean “not stated yet”.

Practical advice: if you need “fail when missing” validation, use SHACL or business rules. Do not rely on OWL's open-world reasoning for data completeness checks.

2.4 What an ontology is not

• Not a database schema: a schema describes storage, an ontology describes meaning and constraints.
• Not a knowledge graph: a knowledge graph is the instantiated result (ABox); the ontology is its schema (TBox).
• Not a taxonomy: a taxonomy only has broader/narrower; an ontology also has relations, properties, and axioms.
• Not a glossary: a glossary only has terms and definitions; an ontology must be computable and verifiable.
• Not a prompt: a prompt instructs a model; an ontology is a semantic contract for systems and agents.

3. One picture: ontology, schema, knowledge graph, taxonomy, glossary

Concept	Core content	Reasoning	Typical use
Glossary	Terms + definitions	No	Shared language, documents
Taxonomy	Classes + broader/narrower	Limited	Navigation, tags, retrieval
Database schema	Tables, columns, foreign keys	No	Storage, transactions
Knowledge graph	Entities + relations + instances	Yes	Query, recommendation, link analysis
Ontology	Classes + relations + properties + axioms + constraints	Yes	Semantic layer, agent contract, data integration

A common misconception is that “having a knowledge graph means having an ontology”. In practice:

• A knowledge graph without an ontology is usually a pile of untyped edges: queryable but not trustworthy.
• An ontology without instances is an empty schema: it cannot answer real questions.
• What actually works is ontology (TBox) + knowledge graph (ABox) + constraints (SHACL) + mapping.

4. The five core parts of an ontology

4.1 Class

A class is a type in the domain. For example:

• LegalEntity
• Account
• JournalEntry
• Party

Classes can form hierarchies: AssetAccount is a subclass of Account; CashAccount is a subclass of AssetAccount.

4.2 Instance

An instance is a concrete member of a class. For example Account#1000 is a CashAccount; JE#20261021-001 is a JournalEntry.

4.3 Relation

A relation describes a link between concepts. For example:

• JournalEntry posts JournalLine
• JournalLine debits Account
• Document supports JournalEntry
• Party counterpartyOf JournalEntry

Relations need cardinality: one-to-one, one-to-many, many-to-many, required or optional. A relation without cardinality carries no semantics.

4.4 Property

Properties describe a concept's own attributes, e.g. Account.code, JournalEntry.date, JournalLine.amount. Every property needs:

• a datatype (string, decimal, date, enum)
• a unit (HKD, USD, CNY)
• a value domain (an enum of account types)
• required or optional

4.5 Axiom / Constraint

Axioms are semantics that always hold; constraints are rules that data must satisfy.

Examples:

• The debit total of every JournalEntry must equal its credit total.
• JournalLine.account must exist and have is_active = true.
• JournalEntry.date must fall inside an open period.
• Foreign-currency entries must have fx_rate > 0.

An ontology without axioms and constraints is just an expensive glossary.

5. Design dimensions: 12 questions you must answer

There is no single standard for ontology design, but 12 dimensions work as a checklist. They are not academic categories; they are the questions most often skipped and most consequential in practice.

#	Dimension	Question you must answer	Output
1	Purpose and scope	What does this ontology solve? What is out of scope?	Scope statement, non-goals
2	Competency questions	Who asks what? Which tasks must an agent complete?	10–30 competency questions
3	Concepts and classes	Which classes? Which hierarchy?	Class taxonomy, definitions
4	Relations and cardinality	How do concepts connect? One-to-many? Required?	Relations, cardinality
5	Properties and domains	Which properties? Which units?	Properties, datatypes, enums
6	Axioms and constraints	What must hold? What is impossible?	Axioms, SHACL/OWL constraints
7	Events and states	Which business events? How do states transition?	Event types, state machine
8	Identity and resolution	How do multiple names for one entity merge?	Identity rules, canonical ID
9	Time and provenance	When is it valid? Who supplied it?	Temporal validity, provenance
10	Data mapping	How does it map to DB / API / documents?	Mapping table, ABox
11	Modules and standards	What can be reused? Which standards?	Modules, OWL/SKOS/JSON-LD
12	Governance and evolution	Who owns it? How does it change?	Owner, versioning, change log

5.1 Why competency questions come second

Because an ontology is not art: it exists to answer questions. Writing the CQs first prevents you from modelling concepts that will never be queried.

CQ examples:

• Which accounting period does this entry belong to?
• What is the debit balance of this account?
• Which transactions did this supplier have in the past 12 months?
• Which journal entry does this bank transaction correspond to?
• How many layers are there in this client's shareholding structure?

Every CQ should be expressible as a query over the ontology. If it is not, a concept or relation is missing.

6. The process: eight steps from question to verifiable model

6.1 Step one: purpose and scope

Write one sentence: “This ontology exists so that an agent can parse documents, generate journal entries, and stay auditable in bookkeeping tasks.”

Also write the non-goals: “No tax filing, no payroll, no consolidated statements.”

6.2 Step two: competency questions

Write 10–30 CQs covering the main users and agent tasks. Do not start with 200; start with the 20 most painful ones.

6.3 Step three: concepts and classes

Extract nouns from the CQs, documents, the DB schema, and APIs. Every concept needs:

• a unique ID
• a Chinese name and an English name
• a one-sentence definition
• a parent class
• synonyms
• examples and counter-examples

6.4 Step four: relations and cardinality

For every relation ask:

• Which concept points to which?
• One-to-one, one-to-many, many-to-many?
• Required or optional?
• Is there an inverse relation?

6.5 Step five: properties and domains

Use Decimal for money, ISO 8601 for dates, ISO 4217 for currencies. Every property needs a unit and a value domain.

6.6 Step six: axioms and constraints

Start with impossible states, then required states. For example:

• Debits not equal to credits → impossible
• An entry inside a closed period → impossible
• A non-existent account → impossible
• A foreign-currency entry with no exchange rate → impossible

6.7 Step seven: data mapping

Map ontology concepts onto real data:

• Account.code ← accounts.code
• JournalEntry.date ← journal_entries.date
• Document.source ← file path / page / bbox

Mapping must preserve provenance: where each instance came from, when it was captured, who confirmed it.

6.8 Step eight: validation and versioning

Validate with CQs and real tasks:

• CQ query hit rate
• agent task accuracy
• constraint pass rate
• query latency
• maintenance cost

Then version it: v0.1, v0.2, each change recording the reason and the impact.

7. Hands-on: build a minimal accounting ontology in 30 minutes

7.1 The eight core entities

• LegalEntity: the legal entity
• Account: the ledger account
• Party: counterparties
• Document: source documents
• JournalEntry: the journal entry header
• JournalLine: the entry lines
• Period: the accounting period
• Currency: the currency

7.2 Turtle skeleton (excerpt)

@prefix ex: <https://example.com/accounting#> .
@prefix owl: <http://www.w3.org/2002/07/owl#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .

ex:JournalEntry a owl:Class .
ex:JournalLine a owl:Class .
ex:Account a owl:Class .

ex:posts a owl:ObjectProperty ;
    rdfs:domain ex:JournalEntry ;
    rdfs:range ex:JournalLine .

ex:debits a owl:ObjectProperty ;
    rdfs:domain ex:JournalLine ;
    rdfs:range ex:Account .

ex:JournalEntry rdfs:subClassOf [
    a owl:Restriction ;
    owl:onProperty ex:posts ;
    owl:minCardinality 2
] .

7.3 SHACL constraints (excerpt)

@prefix sh: <http://www.w3.org/ns/shacl#> .
@prefix ex: <https://example.com/accounting#> .

ex:JournalEntryShape a sh:NodeShape ;
    sh:targetClass ex:JournalEntry ;
    sh:property [
        sh:path ex:date ;
        sh:datatype xsd:date ;
        sh:minCount 1
    ] .

ex:JournalLineShape a sh:NodeShape ;
    sh:targetClass ex:JournalLine ;
    sh:property [
        sh:path ex:amount ;
        sh:datatype xsd:decimal ;
        sh:minExclusive 0
    ] .

Cross-row constraints such as balanced debits and credits are better expressed in SPARQL or application rules; a simple SHACL property shape cannot say “the sum of all lines must match”.

7.4 A JSON Schema tool contract for the agent

{
  "type": "object",
  "required": ["date", "currency", "lines"],
  "properties": {
    "date": {"type": "string", "format": "date"},
    "currency": {"type": "string", "enum": ["HKD", "CNY", "USD"]},
    "lines": {
      "type": "array", "minItems": 2,
      "items": {"type": "object", "required": ["account_code", "debit", "credit"]}
    }
  }
}

The agent validates against this schema before calling the bookkeeping tool. That is far more reliable than writing “please ensure debits equal credits” in a prompt.

8. Intermediate: constraints, reasoning, and ontology patterns

8.1 How OWL and SHACL divide the work

Tool	Purpose	World assumption	Best for
OWL 2	Class reasoning, equivalence, subclasses, property characteristics	Open world	Semantic inference, classification
SHACL	Data validation, required fields, value ranges, cardinality	Closed world	Data quality, agent input validation
JSON Schema	API parameter validation	Closed world	Tool contracts
SPARQL	Queries and cross-row constraints	Depends on the query	Reporting, reconciliation, audit

Practical advice: use SHACL/JSON Schema for “must be correct”, and OWL for “may be inferred”. Do not use OWL for data integrity checks.

8.2 Ontology patterns

• Upper ontology: BFO, SUMO, schema.org. They give common categories, but do not force-fit them.
• SKOS: glossaries, synonyms, taxonomies. Good for tags and retrieval.
• Event pattern: Event → Actor → Object → Time. Good for transactions, audit, logs.
• Role pattern: a Party can be a Customer, a Supplier, and an Employee at once. Model roles, not subclasses.
• Time pattern: ValidFrom / ValidTo. Never overwrite history.
• Provenance pattern: Entity → Activity → Agent, following W3C PROV.

8.3 The limits of reasoning

Reasoning is powerful but not universal:

• It can classify, check consistency, and derive indirect relations.
• It cannot replace business rules, handle vague language, or guarantee that data is true.
• Large-scale reasoning is slow; agent scenarios usually need only “fetch a subgraph and reason locally”.

9. Advanced: time, identity, versions, multi-tenancy, provenance

9.1 The time dimension

Every accounting fact, contract, shareholding, and exchange rate has a validity period. Storing only the current value is wrong. Do this instead:

• ValidFrom / ValidTo
• as-of queries
• event time versus record time
• a version chain

9.2 Entity resolution

One supplier may appear under several names, several IDs, and several bank accounts. You need:

• a canonical ID
• an alias table
• matching rules (name, tax ID, address, bank account)
• a human confirmation queue

Without entity resolution, the ontology simply accumulates duplicate entities.

9.3 Versioning and modularity

• an ontology version number (v0.1, v0.2)
• a change log (who changed what, why, which CQs were affected)
• module boundaries (core, accounting, tax, banking)
• a backward-compatibility policy

9.4 Multi-tenant isolation

• The TBox can be shared; the ABox must be isolated per tenant.
• One graph, schema, or namespace per tenant.
• Enforce the tenant filter in the query layer, not only in the application layer.

9.5 Provenance

Every fact must be able to answer:

• Which document did it come from?
• Which page, which bounding box?
• Which agent or human confirmed it?
• When was it written?
• Has it been modified?

This matters most for accounting and audit.

10. Agents and ontologies: a tool contract, not prompt stuffing

10.1 Three tools

Do not stuff the whole ontology into a prompt. Give the agent three tools:

• search_concepts(query): find concepts by name or synonym
• get_relations(concept_id, depth): fetch a subgraph
• validate_payload(schema_id, payload): validate tool arguments

The agent fetches on demand and uses immediately, which avoids blowing up the context window.

10.2 RAG versus ontology

Need	RAG	Ontology
Find relevant documents	Strong	Weak
Entity resolution	Weak	Strong
Relational reasoning	Weak	Strong
Parameter validation	Weak	Strong
Auditability	Medium	Strong

The best combination: RAG finds material, the ontology constrains meaning, the agent decides.

10.3 Multiple agents sharing one ontology

If every agent keeps its own “ontology”, you effectively have none. You need one shared ontology service, so that all agents collaborate through the same concept IDs, relations, and constraints.

10.4 Evaluation

• CQ hit rate
• entity resolution accuracy
• tool parameter validation pass rate
• agent task success rate
• query latency
• maintenance cost

11. Case study: with and without an ontology

Take the same task: “generate a rent journal entry from a document”.

11.1 Without an ontology

• The agent sees “rent” and guesses an account.
• It treats the landlord as a Supplier, though sometimes it is just a Party.
• The amount may be captured from a watermark or a minimum balance.
• Debits and credits may not balance, and nothing checks them.
• Several agents produce different accounts, with no arbitration.

11.2 With an ontology

• Account has a type and a value domain; rent can only map to rent-type accounts.
• Party has roles; landlord, supplier, and customer stay distinct.
• Document has provenance; every amount traces back to a page and a bounding box.
• JournalEntry has an axiom: debits must equal credits.
• All agents share the same concepts and constraints, so their conclusions are comparable.

The difference is not a smarter model. It is that the semantic layer keeps errors out.

12. Twelve common traps

1. No CQs: modelling for its own sake.
2. Treating the ontology as a database schema.
3. Concepts with names but no definitions.
4. Relations with no cardinality.
5. A TBox with no ABox mapping.
6. No entity resolution, so entities duplicate.
7. Ignoring the time dimension.
8. No provenance, so nothing is auditable.
9. Overusing OWL reasoning, so queries crawl.
10. No owner and no versioning.
11. Stuffing the entire ontology into a prompt.
12. Every agent maintains its own ontology, and the semantics drift.

13. Maturity roadmap

Level	Name	Characteristics	Best for
L0	Glossary	Terms + definitions	Shared language
L1	Taxonomy	Broader/narrower	Navigation, tags
L2	Ontology	Classes + relations + properties	Data integration
L3	Constraints and reasoning	SHACL / OWL	Data quality, audit
L4	Agent-ready	Tool contracts + versions + audit	Multi-agent, production

Do not chase L4 on day one. Reach L2, solve one real task, then upgrade.

14. A 30/60/90-day rollout plan

14.1 Days 1–30: definition and prototype

• Write 20 CQs
• Build 8–12 core classes
• Build 6–10 relations
• Prototype against one real task

14.2 Days 31–60: constraints and mapping

• Add SHACL / JSON Schema
• Map to the DB and APIs
• Add provenance
• Define identity rules

14.3 Days 61–90: agents and governance

• Three agent tools
• A shared ontology service for multiple agents
• Versioning and a change log
• Measure CQ hit rate and task success rate

15. Conclusion: the ontology is the operating system of meaning

An ontology is not a diagram and not a document. It is:

• the shared language of people and machines
• the tool contract for agents
• the guardrail for data quality
• the common ground for multi-agent collaboration
• the semantic layer for audit and traceability

Getting started is easy: write CQs, define classes, add relations. Mastery is hard: get identity, time, versions, and governance right, and make it run inside a real system.

Three sentences to remember:

1. Ask the questions before naming the concepts.
2. Constrain before you reason.
3. Start small, then widen.

16. Appendix: standards and tools

• Standards: RDF, RDFS, OWL 2, SHACL, SKOS, JSON-LD, SPARQL, PROV-O
• Methodologies: Ontology 101, NeOn, METHONTOLOGY, competency questions
• Tools: Protégé, TopBraid Composer, GraphDB, Neo4j, Stardog
• Practice: schema.org, BFO, SUMO, Palantir Ontology

Ontology design has no single right answer. The only tests are: can it answer questions, can it be verified, can it be maintained.

Next steps

Build the five artefacts for real, all in one folder:

1. CQ list: 15 competency questions, each expressible as a query;
2. Ontology file: an ontology.ttl with fewer than 30 classes;
3. Shape file: a matching shapes.ttl with 3 SPARQL constraints;
4. Test data: 10 deliberately invalid records that must all be rejected;
5. Tool contract: the three interfaces search_concepts, get_subgraph, and validate_payload.

Once that exists, you have a semantic layer an agent can use safely — not a pile of noun definitions.