An ontology is what happens when classification stops asking only “Which box?” and starts asking “What kinds of things exist here, what can be true about them, and how are they allowed to relate?”
A taxonomy may say that a sparrow is a bird and a bird is an animal. An ontology can also represent that the sparrow inhabits a place, has biological traits, belongs to a species, was observed by a person, appears in a photograph, and is protected under a particular rule in a particular jurisdiction.
It moves from a tree of categories toward an explicit model of a domain.
That makes ontologies powerful for libraries, science, medicine, archives, education, enterprise data, knowledge graphs and AI systems.
Quick answer: what is an ontology?
An ontology is a formal or semi-formal representation of the kinds of entities in a domain, their properties, the relationships between them, and often the rules or constraints that govern those relationships.
- Classes: kinds of things.
- Instances: particular things.
- Properties: characteristics of things.
- Relationships: typed connections between things.
- Constraints: rules about what may or must be true.
- Identifiers: stable references to entities and concepts.
- Inference: new statements derived from explicit statements and rules.
- Provenance: where claims came from and under which authority.
Ontologies extend the classification ideas in How to Categorise Anything. A taxonomy organises categories. A controlled vocabulary stabilises terms. An ontology makes the domain’s entities and relations explicit.
1. Start with entities
An ontology begins by deciding what kinds of things deserve identity in the model.
In education, entities may include student, teacher, lesson, assessment, concept, school, resource and curriculum. In medicine, they may include patient, condition, symptom, test, treatment, clinician and encounter. In an archive, they may include person, organisation, document, event, collection, location and rights statement.
If everything is represented as text in one field, relationships become difficult to reason about.
2. Classes describe kinds of things
A class is a category used to group entities that share a meaningful type.
- Student
- Teacher
- School
- Document
- Disease
- City
- Animal
Classes can participate in hierarchies, but the ontology does not end with hierarchy.
3. Instances are particular members
A class says “city”. An instance says “Singapore”. A class says “book”. An instance says one particular edition or copy. A class says “student”. An instance refers to one actual learner.
Keeping class and instance separate prevents a common category error: treating a type and a member as the same level of object.
4. Properties describe entities
Properties may include:
- name;
- date;
- height;
- language;
- status;
- population;
- publication year;
- confidence score.
Not every property should become a category. Ontologies provide a place for descriptive facts without forcing them into the class tree.
5. Relationships connect entities
This is where ontology becomes much more expressive than a simple taxonomy.
- teacher teaches student;
- document was authored by person;
- city is located in country;
- medicine treats condition;
- road connects places;
- claim is supported by evidence;
- organisation owns asset.
Each relationship has meaning. “Teaches” is not the same as “owns”, “part of” or “located in”.
6. Typed relationships reduce ambiguity
A link between two nodes is not enough if the system does not know what the link means.
Typing relationships allows machines and humans to distinguish cause, ownership, location, authorship, containment, membership, similarity and dependency.
This is one reason knowledge graphs become more useful when edges carry semantics rather than merely connectivity.
7. Domain and range constrain relationships
A relationship may be defined so that certain classes are expected on each side.
For example:
authored by: Document → Person or Organisation
This makes nonsensical statements easier to detect.
8. Hierarchy still matters
Ontologies can contain class hierarchies:
- Animal → Mammal → Cetacean
- Document → Report → Annual Report
- Transport Vehicle → Rail Vehicle → Train
The difference is that the hierarchy sits inside a wider network of properties and relationships.
9. Multiple inheritance can represent genuine overlap
Some classes legitimately inherit from more than one broader class.
A teaching hospital may be both a hospital and an educational institution. A research dataset may be both a digital resource and a research output.
Multiple inheritance should reflect real semantics, not compensate for a poorly separated facet system.
10. Roles should not always become classes
A person can be a teacher in one context, a parent in another, a patient in another and an author in another.
Sometimes these are better represented as roles or relationships rather than permanent types.
Ontology design should distinguish intrinsic type from contextual role.
11. State deserves explicit representation
Active, inactive, damaged, recovered, archived and retired describe changing conditions.
An ontology can model state as a property, an event-derived condition or a linked state entity depending on how much history and reasoning the domain requires.
12. Events are different from objects
An earthquake is an event. A fault line is a physical feature. A report about the earthquake is a document. A rescue agency is an organisation. A casualty count is an observation or claim.
Mixing these into one entity type makes relationships difficult to express accurately.
13. Claims are different from facts about the world
Knowledge systems often need to represent what a source says without asserting that the claim is unquestionably true.
An ontology can distinguish:
- entity;
- claim about entity;
- source making the claim;
- evidence supporting it;
- confidence or dispute status.
This is essential in history, science, medicine and any domain where knowledge is revised.
14. Identity is a design problem
When are two records about the same thing?
Two spelling variants may refer to one person. Two editions may refer to one intellectual work but remain different publication entities. Two companies may share a brand but be legally distinct.
Ontology design needs an explicit identity policy.
15. Stable identifiers support identity
Names change, but identifiers can remain stable.
This is why controlled vocabularies and ontologies work well together. The article How Controlled Vocabularies Work explains how labels can vary while concept identity remains stable.
16. Constraints make the model testable
An ontology may specify constraints such as:
- a person has at most one date of birth;
- a published document must have a publication date;
- a school must be located in at least one place;
- a parent relationship connects compatible entity types.
Constraints help detect invalid or incomplete data.
17. Necessary conditions can define classes
A class may require certain properties or relationships.
For example, a “published article” may be defined as a document that has a publication event and a public status. The exact rule depends on the domain.
Formal definitions can support automated classification.
18. Sufficient conditions can support inference
If the ontology defines a class through sufficient conditions, a reasoner may infer membership automatically.
If every object that is a mammal and lives primarily in marine environments belongs to a defined class, new entities meeting the criteria can be classified without a human manually attaching the label.
19. Inference derives new statements
Suppose:
- Every mammal is an animal.
- A whale is a mammal.
The system can infer that the whale is an animal.
Inference can make knowledge graphs more powerful, but only if the rules are trustworthy.
20. Inference can also propagate mistakes
A wrong class assignment near the top of the graph can produce many derived errors.
The more inference a system performs, the more important provenance, validation and test suites become.
21. Open-world reasoning changes the meaning of absence
Many knowledge-graph systems use an open-world assumption: if a fact is not recorded, it does not automatically mean the fact is false.
If the graph does not say a person speaks Japanese, the correct conclusion may be “unknown”, not “does not speak Japanese”.
This is fundamentally different from many closed database applications where absent membership can imply non-membership.
22. Closed-world rules still matter operationally
Some applications need explicit closed-world behaviour.
A security list may say only authorised users may enter. A competition roster may treat absence as not registered. A workflow may require every case to be assigned exactly one state.
The ontology and application logic should make the assumption visible.
23. Cardinality controls how many relationships are allowed
Relationships may be:
- exactly one;
- zero or one;
- one or more;
- zero or more.
Defining cardinality prevents silent ambiguity about whether multiple values are valid.
24. Symmetric relationships behave differently
If A is married to B, then B is married to A. If A is adjacent to B, B is adjacent to A.
Other relationships are directional. If A authored document B, document B did not author A.
Ontologies can make these relationship characteristics explicit.
25. Transitive relationships enable chains
If a neighbourhood is within a city and the city is within a country, a system may infer that the neighbourhood is within the country.
Not every relationship is transitive. “Friend of” should not automatically propagate through chains.
Formal relationship semantics prevent dangerous assumptions.
26. Inverse relationships improve navigation
If a document was authored by a person, the inverse view is that the person authored the document.
Representing inverses explicitly allows traversal in both directions without inventing two unrelated relationship types.
27. Provenance should attach to claims
For consequential knowledge, store who asserted a statement, from which source, when and under what confidence.
This allows a graph to contain competing claims without collapsing them into one anonymous “fact”.
28. Time belongs inside ontology design
Relationships change.
A person works for an organisation during a period. A city has a population at a date. A country has a legal status during a period. A document changes access state.
Without temporal modelling, the graph may silently treat yesterday’s relationship as eternally true.
29. Events can model change through time
Instead of overwriting a property, an ontology can represent the event that changed it.
A company renamed. A person joined an organisation. A manuscript was transferred to a library. A law came into force. A disease was reclassified.
Event modelling preserves history.
30. Ontologies and facets complement each other
The article How Faceted Classification Works explains how independent dimensions improve retrieval. An ontology can provide the semantic backbone that defines those dimensions, their values and their relations.
Facets are often the user-facing projection. Ontology can be the deeper model underneath.
31. Ontologies and controlled vocabularies complement each other
Controlled vocabulary answers how concepts are named and found. Ontology answers how concepts are structured and related.
Together they provide both linguistic stability and semantic structure.
32. Ontologies should not model everything
A common failure is trying to encode the whole universe before delivering one useful application.
Start with the domain and the questions the model must answer.
A small ontology that supports real retrieval and reasoning is better than a grand ontology nobody can maintain.
33. Competency questions guide design
Before building, write questions the ontology must answer.
- Which teachers teach this student?
- Which documents support this claim?
- Which medical tests are associated with this condition?
- Which cities are located in this country?
- Which resources are suitable for this curriculum level?
These questions provide a concrete test of whether the model is sufficient.
34. Ontology design needs governance
Changes to classes and relationships can affect many records and applications.
Define who may:
- add a class;
- change a definition;
- deprecate a relationship;
- alter a constraint;
- approve mappings;
- publish a new version.
Ontology governance is knowledge governance.
35. Version the ontology
Classes split. Definitions change. Relationships are refined. Constraints become stricter. New entity types appear.
Store versions and effective dates so old data remains interpretable.
36. Crosswalk ontology versions carefully
A class in Version 1 may map exactly to one in Version 2, become broader, become narrower, split into several concepts or disappear.
Do not assume a rename is always an exact equivalence.
37. Test ontology consistency
Use test cases to detect contradictions and impossible combinations.
If two classes are declared mutually exclusive and one instance is inferred into both, the inconsistency needs review.
Formal tooling can help, but human domain review remains essential.
38. Test ontology usefulness, not only logical elegance
An ontology can be logically beautiful and operationally unhelpful.
Measure whether it improves:
- retrieval;
- integration;
- reasoning;
- data validation;
- AI routing;
- human understanding.
The ontology exists to serve a knowledge job.
39. Ontologies help machines traverse meaning
An AI system can use an ontology to move from a query to a concept, from a concept to related entities, from those entities to evidence and from evidence to an answer.
This makes retrieval more structured than pure keyword matching and more controllable than unconstrained semantic similarity.
40. The deeper idea
Classification asks which things belong together.
Ontology asks what the things are, how they can connect, what the connections mean and what can be inferred from the structure.
A taxonomy gives the shelves. An ontology begins to describe the world that the shelves are about.
Final answer
Build ontologies around explicit entities, classes, properties and typed relationships. Distinguish objects from events, roles, states and claims. Give identity stable identifiers. Add constraints only where they are meaningful. Preserve provenance and time. Use inference carefully. Version structural change. Test whether the ontology actually answers the questions the domain needs answered.
The purpose is not to turn reality into a perfect graph. It is to create enough shared structure that humans and machines can navigate the same domain without silently meaning different things.