Different teams can use the same word to mean different things, or different words to describe the same thing. This guide explains how an ontology gives business information a shared structure and meaning, providing a foundation for knowledge graphs and Intelligent Decision Support Systems (IDSS).
In a manufacturing plant, production planning may describe an operation as “ready” because a machine and operator are available. Procurement may consider it ready because materials have arrived. Quality assurance may still be waiting to release the material for use.
Each team is describing part of the situation. A useful operational model needs to bring those perspectives together and make the meaning of “ready” explicit.
An ontology helps define the concepts and relationships needed to do that.
A shared model of how your business works
In business software, an ontology is an explicit model of the kinds of things in a domain, their properties and the relationships between them.
A domain is the area being modeled: construction delivery, hospital operations, manufacturing or creative production, for example.
For a manufacturing business, an ontology might define production orders, operations, operators, skills, materials, machines, tooling and quality releases. It also describes how they relate:
- An operator is assigned to a production operation.
- An operator has particular skills.
- An operation requires particular skills and quality releases.
- An operation forms part of a production order.
This provides a consistent way to describe information arriving from different teams and systems. It makes the meaning of the connections available to both people and software.
The building blocks of an ontology
Entity types
Entity types, often called classes, describe categories such as Production order, Operation, Person, Asset or Approval.
They can include more specific categories. A CNC machine may be a type of Equipment, while a Milling operation may be a type of Operation. This allows shared characteristics to be defined at a broader level and more specific characteristics to be added where needed.
Properties
Properties describe characteristics such as a task's planned start date, a delivery's arrival time or an asset's identifier.
Clear definitions matter. A “completion date” might mean the planned finish, actual physical completion or acceptance by the customer. Treating these as distinct properties avoids combining values that answer different questions.
Relationships
Relationships describe how entities connect: a material lot is used in an operation, a machine is located at a plant, or a person holds a qualification.
Direction and meaning matter. A person who approves a production operation has a different relationship from a person assigned to perform it, even if both records contain the same person's name.
Definitions and logical statements
An ontology can describe categories, relationships and logical statements about them. A shared definition of Equipment, for example, can allow systems to recognize a CNC machine as equipment without maintaining separate lists for every question.
Operational requirements need additional care. Checking whether an operator is available, suitably qualified and permitted to start an operation requires relevant records and configured validation or planning rules. Defining a relationship in an ontology does not, by itself, enforce that requirement in a live system.
How is an ontology different from a knowledge graph?
An ontology describes the model and its meaning. A knowledge graph represents connected information using that model.
In our manufacturing example, Operator is a type in the ontology. Alex Chen is a particular operator. Operation is a type; housing machining is a particular operation.
The ontology defines the “assigned to” relationship. The knowledge graph records that Alex Chen is assigned to housing machining for production order PO-1042.
| Question | Ontology | Knowledge graph |
|---|---|---|
| What does it describe? | Entity types, properties and the meaning of relationships | Specific entities, recorded values and their connections |
| Manufacturing example | An operation forms part of a production order | Housing machining forms part of production order PO-1042 |
| Why is it useful? | Establishes consistent meaning across teams and systems | Provides connected information for queries, analysis and decisions |
The distinction is useful even when the ontology and business records are managed together. Read our companion whitepaper, What is a knowledge graph?, for a closer look at connected operational data.
Why a shared vocabulary is only the beginning
A glossary explains what words mean. A taxonomy organizes concepts into categories. An ontology can include both, while also expressing the relationships between concepts in a form software can use.
For example, classifying a CNC machine as equipment is useful. Connecting it to its work center, machining capabilities, maintenance status, tooling and the operations that require it provides a basis for operational questions.
A database schema also describes structure. An ontology emphasizes the business meaning that can span several source systems. The approaches can work together: operational applications continue to hold their records while mappings connect those records to the shared model.
Different industries need different operational models
Some concepts, such as people, organizations, resources and locations, recur across industries. Their relationships and operational requirements differ.
| Industry | Example ontology concepts | A question the model helps frame |
|---|---|---|
| Building & Construction | Projects, work packages, crews, work zones, deliveries and inspection hold points | What must be in place before a crew can start a work package? |
| Healthcare & Aged Care | Facilities, rosters, staff qualifications, care requirements, rooms and clinical equipment | How do planned staffing and facility readiness relate to the care required? |
| Banking & Finance | Legal entities, ownership, facilities, collateral, exposures and covenants | Which exposures share ownership or collateral relationships? |
| Heavy Industry & Energy | Plant assets, work orders, isolations, permits, spares and contractor assignments | Which prerequisites govern a maintenance activity during a shutdown? |
| Manufacturing | Production orders, bills of materials, work centers, tooling and operator skills | Which materials, equipment and skills does a production order require? |
| Media & Production | Projects, tasks, departments, artists, skills, bookings and shared resources | How do project requirements relate to available people and production capacity? |
These examples illustrate the scope of a model. Answering the questions requires the corresponding data, permissions and analytical capabilities.
An industry-specific ontology provides a starting point. It still needs to be adapted to an organization's terminology, workflows and decision requirements.
How information is mapped to an ontology
Source systems rarely describe the business in exactly the same way. One application may refer to a component, another to a part and another to a stock item. Those terms may overlap, but they are not always interchangeable.
During data ingestion, relevant source fields and relationships are mapped to the shared model. For example:
- A procurement supplier record maps to an Organization with a supplier role.
- A manufacturing execution system record maps to an Operation belonging to a Production order.
- A quality-system release maps to a Quality release record linked to the relevant material lot and operation.
Mapping also needs to distinguish identities, units, statuses and dates. Two records with similar names should not automatically become one entity, and a planned quality check should not be treated as a completed quality release.
Information can arrive through APIs, database connections, files, event streams or authorized MCP tools. When an AI agent submits a record through MCP, that record still needs to fit the agreed model and applicable validation rules.
The ontology gives incoming information a common meaning; ingestion and governance processes establish how it is matched, checked and maintained.
Turning shared meaning into decision support
An ontology makes operational questions more precise. It identifies the entities and relationships that a decision depends on.
Return to the question: “Can housing machining for production order PO-1042 start tomorrow?”
A useful model connects the operation to its assigned operator, required skills, material lots, machine, tooling and quality releases. The knowledge graph holds the relevant assignments and recorded statuses. Configured rules can then check those records against the requirements for the planned start.
An unreleased material lot can be flagged for review. A conflicting machine booking can be investigated. A planner can compare an alternative sequence in a scenario sandbox.
Each component has a role: the ontology defines meaning, the graph connects records, and validation, analysis and planning tools evaluate the available information. Authorized people review the proposed response.
Keeping meaning consistent as the business changes
Terminology, workflows and requirements evolve. A company may introduce a new asset category, change an approval process or acquire a business with different naming conventions.
An ontology therefore needs ownership and change management. Changes should be reviewed for their effect on source mappings, existing records, reports and automated workflows.
Time matters as well. A qualification valid last month may have expired today. An operation's quality-release requirements may have changed since its original plan.
JanusKS knowledge graphs include temporality, allowing teams to review retained historical states. Where definitions or operational rules change, preserving the relevant versions and effective dates helps teams interpret earlier records using the context that applied at the time.
This supports meaningful comparisons between previous plans, recorded outcomes and current assumptions.
What makes an ontology useful?
A useful ontology begins with the decisions the organization needs to support. It should be understandable to the people who know the operation and precise enough for the software that uses it.
Start with a defined use case, agree the relevant terminology and model the connections needed to answer it. Test those definitions against real records and exceptions before extending the scope.
Practical priorities include:
- Clear meaning: distinguish similar concepts, such as planned completion and customer acceptance.
- Appropriate scope: include the detail needed for the decision without modeling everything at once.
- Traceable mappings: understand how source records become entities, properties and relationships.
- Governed changes: assign responsibility for definitions and review their impact when they change.
- Data quality: identify missing, conflicting or outdated information rather than treating it as established fact.
An ontology helps teams make their assumptions explicit. It still requires business expertise to determine whether those assumptions reflect how the operation should work.
How JanusKS uses ontologies
JanusKS uses industry-specific ontologies and knowledge graphs as foundations of its Intelligent Decision Support System (IDSS) platform.
Projectal applies this approach to media and entertainment, connecting people, departments, skills, projects, tasks, bookings, resources and financial information. The shared model helps management assess staffing, scheduling and commercial questions across connected records.
For other industries, the approach starts with their own entities, relationships and operational requirements. Ingestion brings relevant information together, temporality preserves recorded history, and planning, analysis and AI-assisted capabilities help teams evaluate their options.
An ontology gives those capabilities a common language for the business. Its value is realized when that shared meaning supports clearer questions, more consistent information and better-informed decisions.
Build an ontology and IDSS for your business
Contact JanusKS to discuss an industry-specific ontology, knowledge graph and Intelligent Decision Support System for your organization. We can work with your team to define the concepts and relationships that matter, connect the relevant information and develop decision-support capabilities around your operational requirements.
