Table of Contents

Introduction

The Common Core Ontologies (CCO) are a set of mid-level ontologies built on top of the Basic Formal Ontology (BFO), providing standardized, reusable building blocks for creating domain-specific ontologies. Think of CCO as a set of standardized Lego pieces that engineers can use to build more specific models for different engineering domains, ensuring consistency and interoperability across systems.

CCO serves as a critical foundation for digital engineering (DE) efforts, enabling the creation of interoperable domain ontologies that can be reused across different projects and organizations.

Overview

CCO is a collection of mid-level ontologies (MLOs) designed to bridge the gap between high-level top-level ontologies (like BFO) and domain-specific ontologies. It provides a standardized set of terms and relations that can be reused across multiple engineering domains, promoting interoperability and reducing redundant ontology development efforts.

The CCO framework includes twelve ontologies that aim to represent and integrate taxonomies of generic classes and relations across all domains of interest. These ontologies cover areas such as spaces, events, qualities, time, and information, making them highly applicable to engineering domains.

CCO is part of the DEFII (Digital Engineering Framework for Integration and Interoperability) framework, which uses ontologies to enable semantic interoperability across different engineering models and tools.

The CCO ecosystem is designed to work with BFO as the top-level ontology, creating a coherent and interoperable ontology ecosystem. This relationship is crucial for ensuring that domain-specific ontologies can be integrated with other ontologies and systems.

graph TD A[Top-Level Ontology] --> B[BFO] B --> C[Mid-Level Ontology] C --> D[CCO] D --> E[Domain-Specific Ontology] E --> F[Armaments Ontology] E --> G[Soldier System Ontology] E --> H[Vehicle Ontology] D --> I[Common Core Artifacts Ontology] D --> J[Common Core Information Ontology] D --> K[Common Core Spatial Ontology]

Position in Knowledge Hierarchy

Broader concepts: - Part III (is-a)

Details

Structure and Content

CCO consists of twelve interrelated ontologies that cover various aspects of domain knowledge. These include:

Ontology

Description

Common Core Artifacts Ontology

Defines artifacts, their functions, and properties

Common Core Information Ontology

Handles information content entities and their relationships

Common Core Spatial Ontology

Provides spatial concepts for location and orientation

Common Core Temporal Ontology

Defines temporal concepts and relations

Common Core Qualities Ontology

Handles qualities like mass, shape, and size

Common Core Events Ontology

Describes events and processes

Common Core Relations Ontology

Defines general relations between entities

Common Core Roles Ontology

Handles roles and designations

Common Core Processes Ontology

Describes processes and their components

Common Core Measurement Ontology

Provides measurement concepts and units

Common Core Activities Ontology

Defines activities and their properties

Common Core Functions Ontology

Handles functions and their realization

Ontology Development Principles

When using CCO, ontology developers should follow these key principles:

  1. Reusability: CCO provides standardized terms that can be reused across different domains, reducing redundant development efforts.

  2. Coherence with BFO: All CCO ontologies are developed in alignment with BFO principles, ensuring philosophical and logical consistency.

  3. Modular Design: CCO is designed as a set of modular ontologies that can be combined as needed for specific applications.

  4. Domain-Specific Customization: While CCO provides a foundation, domain-specific ontologies can extend and refine these terms as needed.

When developing a domain-specific ontology, start by identifying which CCO ontologies provide the most relevant terms and relations. Then, extend or refine these as needed for your specific domain, rather than starting from scratch.
The CCO occasionally makes commitments that might need to be refined by more domain-appropriate Subject Matter Experts (SMEs). While CCO provides a solid foundation, it’s important to validate and refine terms as needed for your specific application.

Practical applications and examples

CCO in the DEFII Framework

The DEFII framework uses CCO as a foundational building block for creating domain-specific ontologies. In the DEFII framework, CCO serves as a mid-level ontology that domain-specific ontologies can build upon.

For example, when developing an armaments ontology, developers can import relevant CCO ontologies (like Common Core Artifacts and Common Core Functions) and extend them with armaments-specific terms.

The DEFII framework specifies three categories of interfaces: Direct Interface, Mapping Interface, and Specified Model Interface, which leverage CCO-aligned data for interoperability.

Soldier System Ontology Example

In the soldier system ontology example, CCO was used as follows:

  1. Developers identified relevant CCO ontologies for the soldier system domain (e.g., Common Core Artifacts for clothing items, Common Core Functions for clothing capabilities)

  2. They extended these CCO ontologies with soldier-specific terms while preserving the CCO IRIs

  3. This ensured that the soldier system ontology could interoperate with other ontologies built on CCO

The soldier system ontology example demonstrates how CCO provides a foundation for creating domain-specific ontologies while maintaining interoperability with other ontologies in the ecosystem.
graph LR A[CCO] --> B[Common Core Artifacts] A --> C[Common Core Functions] B --> D[Article of Clothing] C --> E[Cold-Weather Function] C --> F[Water-Resistant Function] D --> G[Winter Coat] D --> H[Waterproof Jacket] E --> G F --> H

CCO in IoIF Workflows

In the IoIF (Armaments Interoperability and Integration Framework) workflow, CCO is used to:

  1. Create a standardized foundation for domain-specific ontologies

  2. Enable interoperability between different engineering models

  3. Support automated reasoning through standardized relations and properties

  4. Provide a common vocabulary across different engineering domains

When developers create a new domain-specific ontology (e.g., for armaments), they typically:

  1. Import relevant CCO ontologies

  2. Extend them with domain-specific terms

  3. Use the CCO terms to tag their SysML models

  4. Use the IoIF framework to enable interoperability

To use CCO effectively, start by identifying which CCO ontologies provide the most relevant terms for your domain. Then, use Protégé to import and extend these ontologies rather than creating new terms from scratch.

Associated Diagrams

figure_26.png
figure_97.png
figure_163.png
figure_73.png
figure_162.png
figure_50.png
figure_110.png
figure_49.png
figure_51.png
figure_98.png
figure_96.png