---
title: Core Data Ontology (CDO) Overview
url: https://www.emergentmind.com/topics/core-data-ontology-cdo
type: topic
---

# Core Data Ontology (CDO) Overview

Searching arXiv for recent and foundational papers on “Core Data Ontology” and closely related ontology/data-model work.
Core Data Ontology (CDO) denotes a foundational ontology proposed within a broader data-centric design paradigm for computational systems. In the 2024 papers "Redefining Data-Centric Design: A New Approach with a Domain Model and Core Data Ontology for Computational Systems" [2409.09058] and "Data-Centric Design: Introducing An Informatics Domain Model And Core Data Ontology For Computational Systems" [2409.19653], the CDO is presented as the formal ontological layer of an Informatics Domain Model that reorients system design away from node-centric organization and toward semantics native to data itself. Its organizing principle is a four-part, multimodal categorization of data into objects, events, concepts, and actions, intended to support semantic consistency, semantic interoperability, secure data handling, provenance, lineage, auditability, role-based access control, and scalability across distributed ecosystems [2409.09058].

## 1. Definition and scope

The CDO is described indirectly through its goals and functions rather than through a single compact formal definition. The 2024 formulation characterizes it as a **“granular, flexible core data ontology”** that **“systematically classifies data components within the model’s framework”** and **“provides a consistent reference for data architects and system designers, promoting coherent knowledge representation across distributed ecosystems”** [2409.09058]. A second formulation presents it as a **baseline ontology**, implemented as an **OWL 2 ontology**, that provides a **unified and standardized approach to knowledge representation** for computational systems [2409.19653].

Across these accounts, the CDO is not introduced as an application ontology for a single domain. It is instead a **core ontology intended as a foundational reference model**. Its stated role is to supply a common semantic structure that can organize data throughout its lifecycle and across heterogeneous systems, rather than leaving semantics to later curation, integration, or analytics [2409.09058]. The problem setting is explicitly architectural: conventional systems are described as **node-centric**, with emphasis on IP-addressable endpoints, transmission paths, and endpoint identity, whereas the proposed alternative treats data as the primary design unit [2409.19653].

This scope is deliberately broad but not fully formalized. The papers explicitly state that the ontology is explored as an **OWL 2 ontology**, yet they do not provide a full OWL serialization, a complete class/property signature, competency questions already translated into SPARQL, or a complete axiomatization [2409.09058]. This suggests that the CDO, in its current published form, is best understood as a conceptual and architectural core with an asserted ontological implementation medium, rather than as a fully documented ontology engineering artifact.

## 2. Foundational categories and internal structure

The CDO’s top-level structure is quadrimodal. The four foundational categories named throughout the 2024 papers are **objects**, **events**, **concepts**, and **actions** [2409.09058]. These are treated not merely as labels but as the minimum multimodal structure needed to describe data across its lifecycle in computational environments.

| Category | Role in the model | Examples stated in the papers |
|---|---|---|
| Objects | identifiable entities, assets, or structural data components | customer details, machine components, datasets, product attributes, citizens’ personal data |
| Events | occurrences, changes, interactions, or lifecycle moments | transactions, maintenance activities, research activities, purchase history |
| Concepts | meanings, categories, interpretations, and semantic groupings | risk categories, customer segmentation, quality control concepts, buying patterns |
| Actions | procedures, operations, algorithms, or interventions | fraud detection algorithms, real-time machinery adjustments, analysis methods, recommendation algorithms |

In [2409.19653], each category is given a more specialized semantic characterization. **Objects** are associated with **morphological structure**, **form**, **textual**, **attribute**, **schema**, **passive**, and **systemic**; **events** with **kinematical**, **causality**, **tractual**, **field**, **record**, **log**, **objective**, and **stemmatic**; **concepts** with **epistemological**, **knowledge**, **contextual**, **term**, **frame**, **subjective**, and **epistemic**; and **actions** with **dynamical intelligence**, **active**, **payload**, **packet**, **factual**, **value**, and **systematic**. These associations are part of the ontology’s internal semantic grammar rather than a conventional taxonomic hierarchy.

The papers also describe pairwise and composite correlations among the four categories. The explicit combinations are:

- `Scheme = Object + Concept`
- `Reason = Action + Event`
- `Cause = Action + Object`
- `Method = Action + Concept`
- `Goal = Concept + Event`
- `Effect = Object + Event` [2409.19653]

Two of these combinations receive special emphasis. **Consensual Scheme** is defined as the alignment of objectual structure and conceptual interpretation, while **Sovereign Reason** is the relation between action and event that drives system behavior and functionality [2409.19653]. The article does not provide formal axioms for these constructs, but it consistently treats them as structural correlations internal to the ontology.

A notable aspect of the presentation is that the four categories are both ontological classes and architectural lenses. This suggests that the CDO is intended to serve simultaneously as a semantic classification system and as a design discipline for modeling what data is, what happens to it, what it means, and what is done with it.

## 3. Relationship to the Informatics Domain Model and the data-centric paradigm

The CDO is inseparable from the broader **Informatics Domain Model** in which it is embedded. The relationship is explicit: the **Informatics Domain Model** supplies the conceptual architecture, and the **Core Data Ontology** supplies the formal representation of that architecture [2409.19653]. In this arrangement, the domain model is the theory of data-centric design, while the ontology is the representational mechanism through which the theory becomes machine-usable.

The motivating contrast is between **node-centric** and **data-centric** system design. The papers argue that traditional architectures prioritize network nodes, endpoint identity, and transmission security while treating data semantics as secondary [2409.09058]. This is said to contribute to weak interoperability, schema fragility, and insufficient preservation of meaning, integrity, authenticity, and context across the data lifecycle [2409.19653]. By contrast, the proposed data-centric paradigm begins with **what the data is, what happens to it, what it means, and what can be done with it**—that is, precisely the four modalities of the CDO [2409.09058].

The design consequences are stated concretely. The implied workflow is: begin with data semantics rather than network nodes; classify data into the four modalities; use the ontology as a shared reference model; and apply that model to governance, access control, interoperability, analytics, and automation [2409.09058]. In [2409.19653], this is reframed as a shift from **identity management first** to **data management first**, from **network location dependence** to **semantic and structural grounding**, and from **node security** to **data security, provenance, and auditability**.

A specific example used to illustrate this shift contrasts two roles: an **event notary**, who certifies and records events in a trackable sequence, and an **action tracker**, who oversees and evaluates systematic actions [2409.19653]. In the proposed model, access is scoped to the modalities relevant to those roles rather than to undifferentiated systems or databases. This is presented as a governance and security consequence of the ontology’s quadrimodal classification rather than a standalone access-control mechanism.

The papers also tie the CDO to the prevalence of unstructured data, stating that around **80% of recorded data** is unstructured [2409.09058]. The argument is that semantic organization must therefore occur “from the outset,” and the CDO is the mechanism proposed to impose that organization early in system design [2409.09058].

## 4. Ontological representation, engineering choices, and formal status

The published account of the CDO makes a strong implementation claim—**OWL 2 ontology**—while remaining relatively sparse in explicit formal specification [2409.09058]. What is explicit is that the ontology is intended to be machine-readable, class-based, and suitable for semantic web tooling and distributed knowledge representation. What is absent includes complete syntax listings, explicit object-property and data-property declarations, cardinality restrictions, profile claims, named modules, and reasoning benchmarks [2409.09058].

The 2024 papers nonetheless identify several structural components. The core classes are **Object**, **Event**, **Concept**, and **Action** [2409.19653]. The ontology graph in Figure 5 of [2409.19653] also includes supporting elements such as **Data**, **Schema**, **Attribute**, **Form**, **Track**, **Record**, **Log**, **Stemma**, **Field**, **Effect**, **Cause**, **Scheme**, **Goal**, **Reason**, **Method**, **Behaviour**, **Perspective**, **Value**, **Packet**, **Payload**, **Notice**, **Fact**, **Context**, and **Frame**. The paper primarily emphasizes the four principal classes; the remainder appear as supporting semantic nodes rather than a fully documented hierarchy.

A number of named relations are visible in the ontology graph and are explicitly listed in the paper. These include `hasAttributes`, `hasForm`, `hasLineage`, `isLogged`, `traces`, `isCausal`, `demonstrates`, `isDefinedBy`, `isAddressedBy`, `isAffectedBy`, `capturedAs`, `enteredAs`, `hasKnowledge`, `accessedBy`, `exchangedThrough`, `initiates`, `defines`, `isJustifiedBy`, `processes`, `hasIntelligence`, `describedBy`, `instanceOf`, `isExpressedAs`, `constitutes`, `isDocumentedIn`, `isTransmittedBy`, `isFramedBy`, `hasValidity`, `formsBasisOf`, `isBasisFor`, `isContextual`, `contextualizes`, `isTextual`, `isTractual`, `isStemmatic`, `isSystemic`, `occursIn`, `hasStructure`, `hasCausality`, `utilizes`, `underpins`, and `triggers` [2409.19653]. Their intended semantics are described informally through the graph structure and surrounding prose rather than by OWL axioms.

The methodology reported for ontology development is more concrete than the final ontology specification. In [2409.19653], the authors state a six-step ontology engineering process: **Informal Competency Questions**, **Design**, **Reuse**, **Implementation**, **Formal Competency Questions**, and **Evaluation**. Steps **1 through 4** were reported as completed; steps **5 and 6** were identified as future work. The same paper states that the research underpinning the Informatics Domain Model began in **July 2020**, while CDO development began in **April 2023**. A related paper states that the broader conceptual research began in **mid-2020** and that the ontology was developed in **2023** [2409.09058]. These dates establish a development timeline but do not resolve the ontology’s missing formal details.

Two ontology design patterns are discussed explicitly in [2409.19653]. For multilingual or local-vocabulary alignment, the authors considered both a **mapping ontology pattern** and a **content ontology pattern**, choosing the latter because the former was judged too strong for their use cases. For change tracking, a **time-indexed content pattern** is used to capture prior state, resulting state, and timestamp. The example given is the logging of a transition from `:fuji_apple` to `:apple` [2409.19653]. This is one of the few points where the article moves from architectural aspiration to a specific ontology engineering choice.

## 5. Capabilities, governance functions, and application domains

The capabilities most consistently attributed to the CDO are **semantic interoperability**, **granular data classification**, **search and discovery**, **provenance**, **lineage**, **auditability**, **role-based access control**, **data-centric security**, and support for **AI and multimodal data** [2409.19653]. These are architectural claims rather than benchmarked properties, but they define the ontology’s intended use.

**Semantic interoperability** is treated as a central objective. The healthcare example in [2409.09058] argues that if hospitals, clinics, and research institutions share a common ontology, then patient records, diagnostic data, treatment histories, and research findings can be exchanged “without loss of meaning.” More generally, the CDO is described as a shared semantic model or reference layer across distributed ecosystems [2409.09058].

**Provenance and auditability** are assigned primarily to the event modality. Events represent state changes, evidence trails, logs, and temporal occurrences, while the ontology graph includes relations such as `hasLineage`, `isLogged`, and `traces` [2409.19653]. The time-indexed event pattern is intended to preserve previous state, final state, and timestamp for changes in ontological instances. This is tied in the paper to AI and legal contexts where traceability matters.

**Role-based access control** is described as a major governance consequence of data-centric categorization. Instead of granting access primarily by system or node identity, access can be tailored according to user roles and responsibilities relative to semantic categories of data [2409.09058]. The papers do not provide a formal policy ontology or implementation bridge from OWL classes to authorization rules, and they explicitly identify that gap as an open challenge [2409.09058].

**AI support** is discussed in several ways. The retail example links objects to product attributes, events to purchase history, concepts to preferences and buying patterns, and actions to recommendation algorithms [2409.09058]. The robotics discussion in [2409.19653] associates the ontology with semantic mapping of physical objects, object classification using computer vision, fusion of visual data with linguistic context, and situational awareness for autonomous systems. The authors also state that the integration of object and concept layers can improve “real-world data classification, labeling, and semantic interpretation” in AI systems [2409.19653].

The cross-domain examples are broad rather than deeply instantiated. They include:

- **Financial services**: customer details, transactions, risk categories, fraud detection algorithms [2409.09058]
- **Healthcare**: patient records, diagnostics, treatment histories, research findings [2409.09058]
- **Manufacturing**: machine components, maintenance activities, failures, quality control categories, automated machinery adjustments [2409.09058]
- **Research institutions**: datasets, experimental results, research activities, thematic areas, analysis methods [2409.09058]
- **Retail and AI**: product attributes, purchase history, preferences, recommendation algorithms [2409.09058]
- **Government**: citizens’ personal data, aggregate statistical data, role-based access to sensitive versus public information [2409.09058]
- **Smart cities and energy**: distributed, multi-source interoperability and scalability [2409.09058]

These examples show intended applicability, but the papers do not present formal case studies with complete ontology fragments, empirical interoperability evaluations, or deployment benchmarks.

## 6. Comparative context, limitations, and terminological ambiguities

The CDO is best situated by comparison with both ontology engineering work and conceptual data modeling. The papers themselves emphasize that the ontology is a semantic backbone for a broader data-centric architecture, not a complete logic-based ontology language [2409.09058]. That characterization aligns with a comparison to the **Concept-Oriented Data Model (CODM)** in "Principles of the Concept-Oriented Data Model" [0801.0139], which describes a structural-semantic framework built from concepts, items, dimensions, and references rather than from description-logic axioms. CODM’s sharp distinction between schema and semantics, its treatment of relations as subconcepts, its typed-reference architecture, and its canonical semantic flattening make it a plausible point of comparison for the CDO’s architectural ambitions [0801.0139]. This suggests that the CDO shares with CODM an emphasis on structural semantics and integration, while remaining much less formally specified at the data-model level.

At the same time, the CDO should not be conflated with the **Common Core Ontologies (CCO)**. The paper "The Common Core Ontologies" [2404.17758] does not use the name “Core Data Ontology,” and explicitly states that no ontology by that name appears there. The most relevant CCO module for data-centric work is the **Information Entity Ontology**, supported by modules for qualities, units, artifacts, time, and relations [2404.17758]. The distinction matters because CCO is a documented mid-level ontology suite extending BFO, whereas the CDO is proposed as a separate foundational ontology for data-centric computational design [2404.17758].

A second ambiguity concerns the acronym **CDO** itself. In "Binomial Approximation to Locally Dependent CDO" [2203.12895], **CDO** refers to **collateralized debt obligation**, a structured credit product, not to an ontology. In technical literature, this acronym therefore remains context-sensitive and potentially misleading [2203.12895].

The published limitations of the CDO are substantial and explicit. The main ones are:

- **Lack of formal ontology specification**: no full OWL listing, no detailed class or property axioms, no complete taxonomy tree [2409.09058]
- **No explicit axiomatization**: no detailed disjointness, restriction, or property-characteristic claims [2409.09058]
- **No reasoning evaluation**: inferencing behavior, profile selection, and scalability under reasoning are not tested [2409.09058]
- **No implementation benchmark or deployment study**: no empirical assessment of interoperability gains, security outcomes, or performance [2409.09058]
- **No formal policy bridge**: role-based access control is claimed, but ontology-to-policy integration is not technically worked out [2409.09058]
- **No ontology alignment method**: integration with existing ontologies and vocabularies is asserted, but mapping methods and conflict resolution are not specified [2409.09058]
- **No formalized handling of unstructured data**: unstructured data is a primary motivation, but extraction pipelines and annotation procedures are not specified [2409.09058]

The later paper [2409.19653] adds that the ontology engineering process remains incomplete because **formal competency questions** and **evaluation** are future work. It also notes that the ontology did not actually reuse existing ontologies during construction, despite reuse being part of the stated methodology. This gives the CDO centralized control over its main classes, relationships, and properties, but may limit immediate alignment with established semantic standards [2409.19653].

Taken together, these constraints indicate that the CDO currently occupies an intermediate position: more than a manifesto, because it defines a stable quadrimodal structure, reports methodology, names classes and relations, and claims OWL 2 implementation; less than a mature ontology suite, because its logical commitments, mappings, constraints, and validation evidence remain incomplete. Its most defensible characterization is therefore as a foundational, quadrimodal ontology proposal for data-centric computational systems whose primary contributions are architectural reframing and semantic organization around **objects**, **events**, **concepts**, and **actions** [2409.09058].

Source: https://www.emergentmind.com/topics/core-data-ontology-cdo