Skip to main content
Records Authority
Category: Classification and Taxonomy

Ontology

Also known as: semantic model, knowledge model
Simply put

In an information management context, an ontology is a shared, structured vocabulary that describes the things in an organization's environment and how they relate to one another, in a way that both people and computer systems can interpret consistently. It gives data meaning by connecting raw information to defined concepts, rather than leaving each dataset to be understood in isolation. The term also has a distinct and older meaning in philosophy, where it refers to the study of being and existence.

Formal definition

In data and information management, an ontology is a formal, machine-interpretable specification of a shared vocabulary comprising concepts (the entities or 'things' within a domain), their properties, and the relationships between them. It supports the systematic mapping of data to defined semantic concepts, enabling consistent interpretation across systems; as one source characterizes it, effective ontologies exist independently of the underlying data rather than being embedded within it. Practitioners should distinguish this applied, computational sense from the philosophical sense of ontology as the study of the nature and structure of being, and should note that the evidence here does not establish specific formal-logic requirements, standards, or recordkeeping-specific applications for the term.

Why it matters

In many organizations, the same information is stored across numerous systems, each with its own labels, structures, and assumptions. Without a shared vocabulary to connect these datasets, the meaning of data tends to be understood only in isolation, which makes it harder to combine information reliably or interpret it consistently across systems. An ontology addresses this by providing a shared, structured vocabulary that both people and machines can interpret in the same way, connecting raw information to defined concepts rather than leaving each dataset to stand alone.

For information and data management practitioners, the value lies in giving data meaning that persists across contexts. When concepts, their properties, and their relationships are described explicitly, systems can interpret data consistently instead of relying on implicit local knowledge. One characterization of effective ontologies is that they exist independently of the underlying data rather than being embedded within it, which supports reuse of the same semantic model across different datasets and systems.

A point of caution is warranted: the term carries a distinct and older meaning in philosophy, where it refers to the study of being and existence. Professionals should keep the applied, computational sense separate from the philosophical one to avoid confusion. It is also worth noting that the evidence considered here does not establish specific formal-logic requirements, standards, or recordkeeping-specific applications for the term, so claims in those areas should be treated with care.

Who it's relevant to

Data and information managers
Those responsible for making information usable across an organization's systems have a direct interest in ontologies, since a shared vocabulary supports consistent interpretation of data that would otherwise be understood only in isolation. An ontology can help connect raw information to defined concepts across multiple datasets.
Data architects and integration teams
Practitioners who design how systems and datasets fit together may use an ontology as a semantic layer that maps data to shared concepts, properties, and relationships. The idea that an effective ontology exists independently of the underlying data is particularly relevant to how such a reference layer is structured for reuse.
Records and governance professionals
Those working in recordkeeping and information governance should be aware of ontologies as a means of giving data consistent meaning across systems, while noting that the evidence here does not establish recordkeeping-specific applications. Any use in a records context would need to be evaluated against organizational policy and requirements rather than assumed.
Anyone encountering the term across disciplines
Because "ontology" has both an applied data-management meaning and an older philosophical meaning concerned with the nature of being and existence, readers moving between fields benefit from knowing which sense is intended. Conflating the two is a common source of confusion worth correcting.

Inside Ontology

Classes (Concepts)
The categories or types of entities that the ontology represents within a domain, such as record types, agents, functions, or business activities. Classes provide the structural backbone against which specific instances are described.
Properties (Attributes)
The characteristics or features associated with classes, describing what can be known or asserted about instances of a class. In a recordkeeping context these may include attributes relevant to authenticity, reliability, integrity, and usability.
Relationships
The defined connections between classes and instances, such as hierarchical (broader/narrower), associative, or provenance-related links. Relationships allow an ontology to express how records relate to the activities, agents, and contexts that generate them.
Instances (Individuals)
The specific, concrete members of classes, representing actual records, agents, or events rather than abstract categories. The distinction between class and instance parallels the distinction between a record type and an individual record.
Axioms and Constraints
The formal rules that govern how classes, properties, and relationships may be combined, supporting consistency and, in some implementations, machine reasoning. Constraints help enforce that assertions about records remain coherent within the modeled domain.
Controlled Vocabulary Alignment
The mapping between ontology terms and agreed terminology, which supports shared understanding across systems and users. This typically overlaps with, but is broader than, a taxonomy, since an ontology can express relationships beyond simple hierarchy.

Common questions

Answers to the questions practitioners most commonly ask about Ontology.

Is an ontology the same as a taxonomy or classification scheme?
No, though the terms are often conflated. A taxonomy or classification scheme typically arranges concepts into hierarchical categories, often for the purpose of grouping records by function or subject. An ontology is generally broader in scope: it models not only categories but also the properties of entities and the many types of relationships between them, allowing more complex representations of how concepts connect. A classification scheme can be viewed as one component that an ontology may incorporate, but an ontology usually expresses richer semantic relationships than a hierarchy alone. The distinction depends on how each artefact is defined and used within a given organization.
Does adopting an ontology mean the same thing as managing metadata?
Not exactly, and the two should not be treated as interchangeable. Metadata describes attributes of records, such as their context, structure, and management history, and supports properties like authenticity, reliability, integrity, and usability. An ontology provides a formal model of concepts and relationships that can inform how metadata is defined and interpreted, but it is not itself the metadata attached to individual records. In practice an ontology may underpin or give meaning to a metadata scheme, while metadata remains the applied description of specific records. The relationship between the two typically depends on how an organization designs its information architecture.
How does an ontology relate to records management functions such as classification and retention?
An ontology can provide a shared conceptual model that supports functions such as classification, and it may help clarify the relationships between business activities, records, and their contexts. Depending on organizational policy, this can assist in aligning records with retention rules and disposition decisions. However, an ontology does not by itself perform retention or disposition; those actions typically rely on retention schedules, policy, and governance controls. The value of an ontology in this setting usually lies in supporting consistent understanding rather than in replacing established recordkeeping instruments.
What should an organization consider before developing an ontology for recordkeeping?
Organizations often consider the intended scope, the business functions to be represented, the existing classification schemes and metadata in use, and the resources available to maintain the ontology over time. Because an ontology can be complex to build and sustain, it is generally advisable to assess whether the added semantic richness serves a defined need, such as improved interoperability or search. The appropriate approach typically depends on organizational maturity, sector, and the systems that will consume the ontology. Governance and ongoing stewardship are often as important as the initial design.
How can an ontology support interoperability across systems?
An ontology can offer a common set of defined concepts and relationships that different systems reference, which may help reduce ambiguity when information is exchanged. Where systems share or map to an agreed ontology, the meaning of terms can be interpreted more consistently across boundaries. In practice the degree of interoperability achieved depends on the extent to which participating systems actually adopt or map to the ontology, as well as on the underlying technical standards. Interoperability benefits are typically realized through deliberate alignment rather than through the existence of an ontology alone.
Who is typically responsible for maintaining an ontology once it is in place?
Responsibility often falls to roles concerned with information architecture, metadata governance, or information management, sometimes in collaboration with subject matter experts who understand the business functions represented. Because concepts and relationships can change as an organization evolves, ongoing maintenance is generally required to keep the ontology accurate and useful. The specific allocation of responsibility depends on organizational structure and governance arrangements, and it is often defined within broader information governance accountability rather than resting with any single function.

Common misconceptions

An ontology is just another name for a taxonomy or classification scheme.
A taxonomy typically arranges terms in a hierarchical structure, whereas an ontology can also model non-hierarchical relationships, properties, and constraints. An ontology often encompasses a taxonomy but generally expresses a richer set of connections than hierarchy alone.
Building an ontology is primarily a recordkeeping activity equivalent to records classification or file plan design.
An ontology is a broader conceptual model of a domain and may serve information governance, data management, or knowledge organization purposes. Records classification concerns the control of records as evidence across their lifecycle, and while an ontology may inform such classification, the two are distinct in scope and intent.
An ontology, once built, is a fixed and authoritative representation of reality.
An ontology is a model reflecting particular choices, domain scope, and purpose, and it typically requires maintenance as the domain, terminology, or organizational needs change. Depending on organizational policy, different ontologies may model the same domain differently for different objectives.

Best practices

Define the scope and purpose of the ontology explicitly before modeling, stating which domain, classes, and relationships fall inside and outside its boundaries.
Distinguish clearly between classes and instances so that abstract categories (such as a record type) are not conflated with concrete members (such as an individual record).
Align ontology terms with any existing controlled vocabularies or taxonomies in use, documenting the mappings to support shared understanding across systems and stakeholders.
Where the ontology supports recordkeeping, preserve the properties that make something a record, ensuring that modeled relationships can express context, provenance, and other attributes relevant to authenticity, reliability, integrity, and usability.
Document the axioms and constraints that govern relationships, and validate the model for internal consistency, particularly where machine reasoning is intended.
Treat the ontology as a maintained artifact, reviewing and updating classes, properties, and relationships as the domain, terminology, or organizational requirements evolve.