Concept
Ontology
A structured model of concepts, relationships, constraints, and meaning within a domain.
Position in the Trusted Data Framework
Ontology
Living Graph View
Ontology in the concept network
Drag nodes to adjust the view, double-click a node to expand its neighbourhood, and right-click a node to hide it while preserving the exploration context.
Relationship Matrix
Ontology as a network node
Builds on real-world objects, events, places, and responsibilities before turning them into formal concepts.
Provides shared meaning that the semantic layer can operationalise across data products, APIs, dashboards, and AI applications.
Defines graph schema, relationship semantics, and constraints.
Gives AI systems governed domain meaning for retrieval, interpretation, and explanation.
Depends on persistent entities and identifiers so concepts can be attached to stable things rather than ambiguous records.
Constrains valid representations and manages the impact of semantic change.
Concept Understanding
How to recognise Ontology
Without ontology, teams may still store data, but they cannot reliably share meaning across systems, decisions, and AI applications.
Ontology turns competing labels into explicit concepts and relationships that people, systems, and AI can interpret consistently.
Why it is not
A schema describes how data is stored. An ontology describes what the domain means.
An ER diagram models database entities and relationships. An ontology models business concepts, semantics, and constraints across systems.
A data dictionary documents fields. An ontology connects concepts, relationships, rules, and meaning.
Concept Relationships
How Ontology works with other concepts
Builds on real-world objects, events, places, and responsibilities before turning them into formal concepts.
A field inspection maps a real bridge component; the ontology defines whether it is an Asset, Component, Location, or Observation.
Where does the real-world boundary of each concept begin and end?
Provides shared meaning that the semantic layer can operationalise across data products, APIs, dashboards, and AI applications.
A shared Asset ontology becomes consistent asset definitions for reporting, semantic APIs, and AI copilots.
Which domain definitions must remain consistent across systems and teams?
Defines graph schema, relationship semantics, and constraints.
Asset, Location, Event, Document, and Risk classes become graph nodes and typed relationships.
Which relationships need to be explicit before the organisation can reason across data?
Gives AI systems governed domain meaning for retrieval, interpretation, and explanation.
A RAG assistant can distinguish an asset owner, maintainer, operator, and regulator instead of treating them as generic organisations.
What concepts must AI understand correctly before recommendations can be trusted?
Depends on persistent entities and identifiers so concepts can be attached to stable things rather than ambiguous records.
A building, asset, facility, and operational system can be distinguished only when identity rules are clear.
Which entities need persistent identity before semantic modelling can be trusted?
Constrains valid representations and manages the impact of semantic change.
Changing the definition of Critical Asset must trigger review across dashboards, risk models, and knowledge graph mappings.
Who can approve semantic change, and how is the impact assessed?
Definition
An ontology defines the core concepts in a domain and the relationships between them. It gives systems and people a shared model of meaning.
Why It Matters
AI systems need more than data fields. They need context, constraints, and relationships. Ontologies help organisations make data interoperable, explainable, and reusable across systems.
Role in the Trusted Data Framework
Ontology sits mainly in the Semantics layer. It connects information to knowledge by making domain meaning explicit and governable.
Practical Examples
- Defining common asset, location, event, and organisation concepts for a digital twin.
- Mapping inconsistent source-system terms to a shared business vocabulary.
- Supporting ontology-driven data integration for analytics and AI workflows.
Case Evidence
GBlocks' ontology (semantic/ontology.yaml) is
deliberately lightweight -- 19 concepts (grown from an initial 15) and a
small closed vocabulary of relationship types (extended from 10 to 12
when two new real relationship shapes appeared) -- but it encodes three
things worth noticing. First, confidence is part of the ontology itself:
the Transaction refers_to Property relationship states outright that
only 7% resolve to an exact matched identity, the rest fall back to a
coarser relationship, so a consumer knows how much to trust it before
using it. Second, governance facts live inside the model, not in
separate documentation -- the PhysicalFeature concept's own definition
notes that two of its three source tables are billed Premium products,
discovered only after the fact via a usage check, not assumed at design
time. Third, ontology discipline caught a duplicate before it ever
entered the model: while adding four new sources, a fifth candidate
dataset was recognised, via schema inspection, as a republication of a
source already loaded under a different publisher label -- and was
never ingested. Recognising when two differently-labelled sources
describe the same real-world concept is as much ontology work as naming
the concepts in the first place.
Consulting Questions
- Which business concepts must be shared across teams and systems?
- Where do source systems use different names for the same thing?
- Which relationships are essential for decision-making?
- Who owns and governs semantic change?
- How will the ontology be validated against real data?