Core Data Ontology (CDO) Overview

• Core Data Ontology (CDO) is a foundational, quadrimodal ontology that categorizes data into objects, events, concepts, and actions.
• The ontology employs an OWL 2 approach with a six-step engineering process to structure data semantics and support robust role-based access control.
• CDO underpins data-centric design by ensuring semantic interoperability, provenance, auditability, and secure handling across distributed systems.

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" (Johnson et al., 2024) and "Data-Centric Design: Introducing An Informatics Domain Model And Core Data Ontology For Computational Systems" (Knowles et al., 2024), 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 (Johnson et al., 2024).

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” (Johnson et al., 2024). 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 (Knowles et al., 2024).

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 (Johnson et al., 2024). 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 (Knowles et al., 2024).

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 (Johnson et al., 2024). 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 (Johnson et al., 2024). 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 (Knowles et al., 2024), 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 (Knowles et al., 2024)

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 (Knowles et al., 2024). 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 (Knowles et al., 2024). 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 (Johnson et al., 2024). This is said to contribute to weak interoperability, schema fragility, and insufficient preservation of meaning, integrity, authenticity, and context across the data lifecycle (Knowles et al., 2024). 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 (Johnson et al., 2024).

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 (Johnson et al., 2024). In (Knowles et al., 2024), 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 (Knowles et al., 2024). 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 (Johnson et al., 2024). 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 (Johnson et al., 2024).

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 (Johnson et al., 2024). 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 (Johnson et al., 2024).

The 2024 papers nonetheless identify several structural components. The core classes are Object, Event, Concept, and Action (Knowles et al., 2024). The ontology graph in Figure 1 of (Knowles et al., 2024) 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 (Knowles et al., 2024). 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 (Knowles et al., 2024), 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 (Johnson et al., 2024). These dates establish a development timeline but do not resolve the ontology’s missing formal details.

Two ontology design patterns are discussed explicitly in (Knowles et al., 2024). 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 (Knowles et al., 2024). 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 (Knowles et al., 2024). 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 (Johnson et al., 2024) 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 (Johnson et al., 2024).

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 (Knowles et al., 2024). 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 (Johnson et al., 2024). 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 (Johnson et al., 2024).

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 (Johnson et al., 2024). The robotics discussion in (Knowles et al., 2024) 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 (Knowles et al., 2024).

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

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

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 (Johnson et al., 2024). 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" (Jensen et al., 2024) 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 (Jensen et al., 2024). 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 (Jensen et al., 2024).

A second ambiguity concerns the acronym CDO itself. In "Binomial Approximation to Locally Dependent CDO" (Kumar et al., 2022), 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 (Kumar et al., 2022).

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 (Johnson et al., 2024)
• No explicit axiomatization: no detailed disjointness, restriction, or property-characteristic claims (Johnson et al., 2024)
• No reasoning evaluation: inferencing behavior, profile selection, and scalability under reasoning are not tested (Johnson et al., 2024)
• No implementation benchmark or deployment study: no empirical assessment of interoperability gains, security outcomes, or performance (Johnson et al., 2024)
• No formal policy bridge: role-based access control is claimed, but ontology-to-policy integration is not technically worked out (Johnson et al., 2024)
• No ontology alignment method: integration with existing ontologies and vocabularies is asserted, but mapping methods and conflict resolution are not specified (Johnson et al., 2024)
• No formalized handling of unstructured data: unstructured data is a primary motivation, but extraction pipelines and annotation procedures are not specified (Johnson et al., 2024)

The later paper (Knowles et al., 2024) 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 (Knowles et al., 2024).

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 (Johnson et al., 2024).