An Ontology-Based Framework for Semantic Representation of the Cyber Range Domain

Abstract

Cyber Ranges (CRs) are complex socio-technical ecosystems, combining infrastructure resources, software services, learning mechanisms, and human-in-the-loop processes for cybersecurity training, education, and experimentation. However, their design and representation are conventionally described by diverse architectural representations and a lack of standardization, making them difficult to compare, integrate, and reason in an automated manner. This paper proposes a novel framework that uniquely integrates the structural, functional, informational, and decisional aspects of CR platforms, formalizing them into a common semantic framework. It models the architectural and learning characteristics of CRs, allowing the representation of design choices, operational processes, information resources, and capability development. The ontology is implemented using OWL 2 DL, which includes logical constraints and enables consistency checking and automated reasoning. Validation through instantiation and competency question assessment shows that the model allows for structured querying, traceability across abstraction levels, and capability-level reasoning. The findings indicate that ontology-based modeling can serve as a basis for more formalized CR configuration analysis and capability-focused evaluation of diverse CR platforms.

1. Introduction

The rapid digitalization that fuels the fourth industrial revolution and the emerging era beyond has transformed manufacturing, business processes, and Critical Infrastructures (CI) [1,2]. Apparently, this technological advance has unlocked new operational capabilities, but, on the downside, it has expanded the attack surface to a wide spectrum of threat actors. The high-profile cyberattacks, ranging from the famous Stuxnet [3] attack on the uranium centrifuges in Iran’s Natanz facility to the Industroyer [4] and Industroyer2 [5] attacks on power grid infrastructure, have clearly shown that cyber threats are no longer limited to the traditional Information Technology (IT) domain. At the same time, purely IT-oriented yet highly sophisticated attacks have also highlighted the issue of systemic risk for digitally interconnected environments. Notably, the SolarWinds supply-chain compromise [6,7] enabled adversaries to infiltrate thousands of organizations worldwide, including government agencies and major enterprises. Similarly, the Colonial Pipeline ransomware attack [8] highlighted how a cyber attack on purely IT-oriented environments can have a downstream effect on physical operations on a national scale. Collectively, these incidents highlight the evolving threat landscape across both cyber–physical and purely IT-based infrastructures. Thus, the need to enhance cyber preparedness for the broad range of stakeholders has never been more pressing.

Yet, in practice, executing cybersecurity assessments on actual systems, particularly those part of CIs, is prohibitively difficult and often inadmissible, considering that it could jeopardize system stability, continuity, and safety. In this direction, Cyber Ranges (CRs), as an evolution of traditional security testbeds, have emerged as a comprehensive and versatile solution that caters to a diverse audience, offering a multifaceted perspective on enhancing the overall cybersecurity posture [9,10]. Overall, CRs offer various capabilities, including but not limited to security research, competence building, and education. In simple terms, they can be utilized to raise awareness and educate personnel within an organization about cybersecurity best practices, serving also as valuable platforms for identifying vulnerabilities and devising suitable security controls to safeguard the under-scrutinized system.

Despite the merits of CRs, there is still no definitive agreement about their design, development, or evaluation in relation to existing guiding principles and standards. Several initiatives have been attempted toward developing architectural blueprints and reference models [9,11,12,13] and methodologies for assessing both existing platforms and new and emerging options [9,14]; however, these contributions tend to be disjointed and heterogeneous. For instance, among the many areas of CR research published to date, only one has utilized an ontology-based approach [15]. A related ontology representation effort is also introduced in [16,17] in the broader cybersecurity domain through the unified cybersecurity ontology referred to as the NIST Cyber Security Ontology; however, this work is primarily oriented toward Cyber Threat Intelligence (CTI) integration and attack-centric knowledge representation, rather than toward the semantic modeling of CRs. Yet, the ontology in [15] focused only on defining the structure and flow of exercise scenarios related to the field of cybersecurity and did not address questions pertaining to the overall architecture, operations, or organization of the entire CR ecosystem. Similarly, broader cybersecurity ontologies such as the NIST ontology [16,17] do not target the specific problem of formally representing heterogeneous CR environments.

This limitation becomes evident in practical settings where CR designers, operators, or evaluators are obliged to systematically describe and compare heterogeneous CR platforms, trace how architectural and operational choices enable training capabilities, or assess whether different CR implementations provide equivalent functional support despite relying on different technologies. However, existing approaches are centered on deployment automation, scenario specification, or attack-centric cybersecurity knowledge modeling and only partially support such tasks, as they do not provide a unified semantic representation that links design decisions, functional mechanisms, informational artifacts, and higher-level CR capabilities. Therefore, there is considerable opportunity for future research on the development of a unified ontology-based framework that encompasses the entire CR ecosystem and utilizes a formalized, semantically enriched, and machine-readable framework for synthesizing the diverse elements of the CR ecosystem and enabling both tools and human experts to interpret, relate, validate, and compare them systematically and transparently.

• Contribution: To fill this gap, this paper presents an ontology-based framework that organizes and semantically connects and relates the diverse layers, modules, functionalities, and roles involved in a CR ecosystem. Importantly, the proposed ontology does not constitute a direct representation or encoding of an existing architecture blueprint or taxonomy. Rather, it constitutes a semantic meta-model over architectural knowledge. In other words, structured classifications, taxonomies, or architectures of CRs are inherently semi-formal and lack logical semantics. The ontology introduced in this work aims to abstract and formalize such architectural knowledge into a machine-interpretable framework enriched with constraints, dependency relations, and inference mechanisms. Consequently, the contribution lies not in reproducing architectural diagrams in OWL, but in transforming architectural knowledge into a logically grounded model that supports automated reasoning, validation, and capability inference. The contribution of this work is structured in three phases as follows.

• Phase1 (Modeling): We develop the conceptual model of the core elements that constitute a CR. This includes translating widely used classifications and design aspects into a unified and computationally interpretable ontology that defines a common language for describing CRs in a consistent and unambiguous manner.
• Phase2 (Implementation): We implement the proposed conceptual model using Protégé [18] and formalize it in Resource Description Framework (RDF) and Extensible Markup Language (XML) formats, thereby producing a structured ontology that captures the relationships, dependencies, and compositional structures among the various design parameters of CRs. This implementation supports structured analysis, enhances transparency, and enables more informed and explainable decision-making during the CR design and evaluation process.
• Phase3 (Validation): We validate the proposed ontology through an indicative CR [19], demonstrating how the multi-layer modeling approach, which distinguishes between descriptive, operational, and capability-related aspects, provides a holistic and interpretable representation of CR ecosystems. This validation highlights the ontology’s ability to facilitate comparability and repeatability across heterogeneous CR platforms and use cases.

The rest of the paper is structured as follows. The next section reviews the relevant literature in this field. Section 3 presents the necessary background on CRs and ontology engineering, establishing the conceptual foundations of this work. Section 4 introduces the proposed CR ontology model, detailing its modeling scope, class hierarchy, properties, and logical axioms. Section 5 describes the formal implementation of the model in OWL 2 Description Logic (DL) using Protégé and discusses the technical realization of its reasoning mechanisms. Section 6 validates the ontology through the instantiation of a CR platform and the evaluation of representative competency questions via SPARQL queries. Section 7 presents the visualization interface of the proposed framework. Section 8 discusses the limitations of the proposed approach and outlines directions for future work. The last section concludes the paper.

2. Related Work

A substantial body of literature focuses on improving the automation, deployment, and scenario engineering capabilities of CRs. However, existing contributions address specific operational modules of CR ecosystems, emphasizing scenario development, infrastructure orchestration, and content automation.

The work in [20] introduced Nautilus, a tool that automates the packaging and deployment of CR exercises. Specifically, the authors provided a declarative description language to specify network topologies, services, vulnerabilities, and scoring logic to improve portability and reproducibility of exercises. Their contribution remains scenario-centric, namely, streamlining deployment workflows, and does not extend toward a formal representation of CR architectural elements or ecosystem-wide relationships. Similarly, in [21], the authors proposed the Cyber Range Instantiation System (CyRIS), allowing instructors to define CR configurations using high-level YAML specifications. Their approach automated virtual machine provisioning, network setup, and security content deployment. Although CyRIS aims to enhance repeatability and reduce manual effort, its orientation remains procedural and deployment-driven, rather than grounded in formal knowledge representation or ontological modeling.

Automation-oriented approaches were further explored in [22], where Infrastructure-as-Code (IaC) techniques were combined with CR platforms to enable reproducible vulnerability injection aligned with OWASP Top 10 categories [23]. Likewise, the authors in [24] proposed a Scenario Definition Language (SDL) built upon TOSCA [25] to declaratively model systems, vulnerabilities, and user roles and to enable automated deployment and runtime verification. Their efforts advanced scenario authoring and infrastructure orchestration, but they remain confined to implementation-level automation. The work in [26] surveyed automation practices in modern CR platforms, identifying common capabilities such as infrastructure provisioning, orchestration, adversary emulation, and performance scoring. While this study highlighted automation as a key enabler of scalability and fidelity, it did not introduce any kind of formal or machine-interpretable model for CR design or representation.

Model-driven and language-based automation has also been explored in [27], with the authors proposing Domain-Specific Language (DSL)-based scenario descriptions combined with logical validation and orchestration components. More recently, the authors in [28] leveraged Large Language Models (LLMs) enhanced with Retrieval-Augmented Generation (RAG) to automate scenario creation. Although these works aim to enhance automation and content generation, they focus solely on operational workflows rather than structured CR engineering models. Among the surveyed literature, the work in [15] represented a step toward formalization by proposing an OWL/RDF-based ontology for cybersecurity exercise scenarios. The proposed model supports semantic representation and SPARQL-based querying of scenario knowledge. However, its scope is limited to scenario modeling without extending to the broader CR ecosystem, including architectural layering, infrastructure orchestration, lifecycle processes, cross-layer dependencies, or capability modeling.

A relevant recent effort is the unified cybersecurity ontology proposed in [16], also referred to as the NIST Cyber Security Ontology [17], aiming to provide a common semantic framework for cybersecurity knowledge integration. Specifically, the ontology brings together heterogeneous cyber threat intelligence sources, including MITRE ATT&CK, D3FEND, MITRE ENGAGE, CWE, and CVE, to support SPARQL-based querying and inference for threat analysis. Therefore, its contribution is primarily situated in attack-centric and threat-intelligence-oriented settings, where the objective is to correlate tactics, techniques, vulnerabilities, weaknesses, products, and countermeasures. In contrast, the present work is not centered on CTI, but on the broader semantic representation of the CR domain as an engineered ecosystem, capturing decisional, functional, informational, and capability-related aspects. Accordingly, the two ontologies serve different domains of application: the NIST Cyber Security Ontology supports semantic integration for cybersecurity knowledge and threat analysis, whereas the proposed ontology is intended for formal representation and reasoning in heterogeneous cyber range environments.

As summarized in

Table 1. Comparative overview of representative works on Cyber Range design and automation.

Ref.	Year	Focus	Scenario Modeling	Infr. Orch.	Knowledge Model	Coverage
[20]	2021	Exercise packaging & deployment	Y	Y	N	Partial
[21]	2016	CR instantiation automation	Y	Y	N	Partial
[22]	2025	IaC-based scenario deployment	Y	Y	N	Partial
[24]	2020	Declarative scenario specification (SDL)	Y	Y	N	Partial
[26]	2021	Automation survey & orchestration	N	Y	N	Limited
[27]	2022	Model-driven scenario automation	Y	Y	N	Partial
[28]	2024	LLM-assisted scenario generation	Y	N	N	Limited
[15]	2021	Scenario ontology modeling	Y	N	Y	Scenario-only
[16,17]	2023	Unified cybersecurity ontology for CTI	N	N	Y	None
This Work	2026	Ontology-based CR engineering	Y	Y	Y	End-to-end

, existing research concentrates on automation mechanisms, infrastructure orchestration, and scenario execution, but does so from different and often partial perspectives. Specifically, works such as [20,21,22,24,27] focus on the specification, packaging, instantiation, or deployment of CR scenarios, typically relying on declarative models, IaC techniques, or model-driven automation workflows. Similarly, the work in [26] emphasizes orchestration and automation challenges at the infrastructure level, while [28] explores LLM-assisted generation of CR scenarios. Although these approaches enhance usability, repeatability, and operational scalability, they remain largely implementation-driven and functionally scoped, without introducing a semantically unified representation of the CR ecosystem. On the other hand, the ontology-oriented work of [15] takes an important step toward semantic formalization, but its scope is confined to cybersecurity exercise scenario structure and flow, rather than the broader CR environment. Likewise, the NIST unified cybersecurity ontology in [16,17] provides a valuable semantic framework for CTI integration, but its domain of application is cybersecurity knowledge representation in attack-centric settings, rather than CR engineering and analysis. In contrast, the ontology proposed in this work is intended to model the CR domain itself at a higher level of abstraction, capturing decisional, functional, informational, and capability-related aspects within a common semantic structure. In this way, the proposed approach differs from prior work not merely by introducing an ontology, but by providing a domain-level semantic framework that supports structured CR representation, cross-layer traceability, capability-oriented reasoning, and more consistent comparison across heterogeneous CR platforms.

3. Background

This section provides a brief, but concise overview of CR and ontologies, serving as a prerequisite and facilitating the subtle comprehension of the subsequent discussion and analysis in Section 4 and Section 5.

3.1. Cyber Ranges

To ground this discussion, we adopt the work in [9] as a cornerstone. Their study proposed a reference architecture for CR design and development, consolidating state-of-the-art standards and guidelines, classifying core CR components across structural, functional, and informational layers, and introducing a preliminary evaluation formula for assessing architectural conformance. Importantly, as a highly relevant input to this study, the work in [9] consolidated different CR aspects through a quad-level classification, condensing the functional and informational aspects of common CR platforms in a structured manner. Moreover, the same classification incorporated decisional aspects, essential for the CR designer’s preliminary architectural decisions before committing to any engineering or implementation actions. Generally, the classification of Figure 1, as adapted from [9], serves as an invaluable input for the construction of the ontology model later introduced in Section 4.

Observe from Figure 1 that each of the four horizontal dimensions outlines the CR aspects based on the different categories, that is, broad aspects, core infrastructure, Range Learning and Management System (RLMS), and user-oriented aspects. From a vertical standpoint, the same aspects are further classified into decisional, functional, and informational. Specifically, decisional aspects relate to the decision-making processes and strategic considerations important for the CR design phase, establishing a solid basis for making informed engineering and implementation choices. As depicted in the figure, they are further divided into infrastructure- and scope-decisional. The first class of decisional aspects includes the domain of application, type of infrastructure, virtualization technology, delivery model, scope, and governance; simply put, all decisions purely related to the infrastructure of the CR. The second class of decisional aspects regards the methods, evaluation practices, curricula type, and target didactics, and finally, defines user types and teams. Together, both infrastructure- and scope-decisional aspects are carefully considered by the CR designer to establish the purpose of the CR and to determine how it should ultimately be instantiated. Subsequently, depending on the infrastructure and scope decisions, the CR designer focuses on the functional and informational aspects of the CR. Namely, the core infrastructure’s functional and informational aspects are resolved consistently with the infrastructure decisions. Accordingly, the RLMS functional and informational aspects are decided based on the infrastructure decisions and the scope decisions pertaining to the purpose of the CR, as well as the learning methods, evaluation practices, curricula type, and target didactics. Last, the user-oriented functional and informational aspects are determined in conformity with the infrastructure decisions and the scope decisions per the user types and teams.

3.2. Ontologies

Regarding ontologies, they can be defined as “[..] explicit formal specification of a conceptualization” [29]. In detail, an ontology formally represents and describes a given concept or system, along with all the relevant relationships among the entities that constitute the system of interest, aiming to disentangle and abstract it in a machine-interpretable manner [30]. Additionally, ontologies facilitate the exchange of semantic information between the system of interest and Humans-in-the-Loop (HitL), providing a common language and outlining all the concepts and inter-concept relations in a formal logic representation. In a nutshell, ontologies can be expressed as graphs, whose vertices represent the concepts of interest and edges denote the relationships among them. Typically, such an ontology graph is structured hierarchically, similar to classes in object-oriented programming or structured tables in relational databases. Altogether, this formal representation allows the automated or machine-aided extraction and aggregation of knowledge from different sources and possibly in different formats [29].

Importantly, ontologies are fundamental entities for achieving interoperability among diverse organizations and stakeholders within—but not exclusively—the Semantic Web, as they are designed to formally capture domain knowledge. Simply put, their function is to make direct and implicit semantics clear in a generic and shared manner, thus providing a common basis for agreement and communication within a specific domain. To this end, Semantic Web technologies provide formal representation languages, such as RDF and the Web Ontology Language (OWL), enabling the description of the entity of interest through well-defined concepts and relationships rather than textual descriptions. Consequently, ontologies can be applied to a wide range of domains, including scientific knowledge portals, information management and integration systems, electronic commerce, and web services. Within a certain domain, they are primarily used for communication and knowledge sharing, logical inference and reasoning, and knowledge base development. Based on existing literature [31], we identify and summarize the benefits of developing and using ontologies in knowledge modeling as follows.

• Provide a shared and common understanding of structured information among HitL and machines or software agents.
• Support the reuse of domain knowledge across applications and systems.
• Enable interoperability among heterogeneous models and domain-specific vocabularies.
• Facilitate and simplify communication among HitL, computational systems, and between them.
• Offer expressive capabilities for capturing contextual knowledge from diverse and heterogeneous sources.

Specifically in the realm of CRs, ontologies can play a key role in addressing their inherent complexity, heterogeneity, and multidimensionality. As discussed in Section 3.1, CRs integrate diverse infrastructural components, functional modules, pedagogical mechanisms, operational workflows, and stakeholder roles. To this end, an ontology-based approach can enable the formalization of these elements into a unified, semantically enriched representation, making their interdependencies, constraints, and design rationale explainable and machine-interpretable to a large extent. Subsequently, supporting systematic reasoning over CR ecosystems could facilitate the comparison and validation of different CR implementations, possibly in tandem with existing evaluation approaches [14], thereby enhancing transparency during design and evaluation decision-making. Ultimately, ontology-based representation can serve as a cornerstone for interoperability among heterogeneous CR platforms, enabling knowledge reuse, automated analysis, and tool-assisted support for CR composition, capability assessment, and lifecycle management.

4. Ontology Model

This section introduces the conceptual foundation of the proposed CR ontology model. It first defines the modeling scope and abstraction boundaries of the ontology, and then presents the detailed model design, including its core classes, properties (relationships), and logical constraints that structure CR ecosystems in a semantically coherent manner.

4.1. Modeling Scope

The purpose of the ontology model that this section introduces is to provide a formal, semantically rich representation of CR ecosystems, capturing both their structural composition and the rationale behind their design. As discussed in Section 1 and Section 3, CRs are inherently complex socio-technical systems, combining heterogeneous infrastructure components, software services, learning mechanisms, operational workflows, and human roles. Existing CR frameworks and reference architectures describe these elements largely in a semi-formal manner, limiting machine interpretability, comparison, and automated reasoning.

Namely, although the quad-level classification of Figure 1 can serve as a value domain input, the ontology does not merely mirror this classification. Instead, it introduces an additional semantic layer that explicitly models dependencies, constraints, and cross-layer interactions that are not formally captured in the original taxonomic representation. Simply put, the ontology serves as a semantic abstraction layer that governs how architectural elements relate, constrain one another, and collectively enable higher-level capabilities.

To address these limitations, the ontology model is designed to serve as a conceptual bridge between high-level CR design decisions and their engineering and implementation, remaining generic to a certain degree to be able to accommodate diverse CR implementations and application domains. In simple terms, the ontology does not aim to prescribe a specific CR instance; instead, it establishes a common conceptual and semantic foundation upon which different CR configurations can be consistently described, analyzed, and compared. In this regard, based on the vertical classification of CR aspects, as shown Figure 1, the ontology modeling scope can be defined as follows.

• Decisional aspects: They represent strategic, organizational, and architectural choices made at early CR design stages. In this sense, they define the purpose, scope, and constraints of the CR, including decisions related to infrastructure, including the delivery model, governance, and virtualization technologies, as well as decisions regarding the CR scope, such as target audience, pedagogical objectives, and evaluation practices. Collectively, decisional aspects condition and influence all subsequent functional and informational elements of the CR.
• Functional aspects: They capture the operational behaviors, services, and mechanisms provided by the CR to realize its intended objectives, as defined by the decisional aspects. Specifically, this class of aspects describes what the CR does at runtime, including functionalities such as simulation and emulation, orchestration and automation, monitoring, learning management, and user interaction.
• Informational aspects: They describe the data-centric dimension of the CR, encompassing the information objects that are generated, consumed, processed, or stored during its operation. Typical informational elements include scenarios, configuration artifacts, logs, telemetry data, learning content, and evaluation results. Keep in mind that informational aspects are explicitly linked to the functional aspects that produce or consume them.
• Capabilities: They express higher-level competencies enabled by the CR through the combined realization of decisional, functional, and informational aspects. Rather than referring to individual components or services, capabilities designate what the CR is able to support (e.g., attack simulation, defensive training, or incident response evaluation).

The ontology is designed with comprehensiveness in mind to provide a semantically rich reference model for the CR domain; not every CR deployment must instantiate its full conceptual extent. In this mindset, the model is intended to support progressive adoption, whereby smaller or less mature CR platforms may rely on a lightweight core subset of concepts and relations sufficient to describe their essential decisional, functional, informational, and capability-related characteristics. As a practical recommendation, a simplified adoption profile may focus on the core CR entity together with the essential decisional, functional, informational, and capability-related concepts to describe the platform at a high level. More specialized branches, such as detailed pedagogical, orchestration, evaluation, or technology-specific modeling constructs, may then be incorporated only when justified by the intended use case. This flexibility can be manipulated in both directions: the proposed ontology framework can be applied in a minimal manner for small-scale CRs, while also being incrementally enriched with additional aspects and semantic detail to accommodate more complex, feature-rich, or large-scale CR deployments.

Note that, from a modeling perspective, the ontology is formulated as a domain-specific artifact, i.e., focusing on the CR domain rather than on task-, sector-, or application-specific processes. In this context, it emphasizes: (i) clear conceptual boundaries between different CR aspect categories, (ii) semantic relationships between them, and (iii) minimal coupling to implementation technologies. At present, the ontology captures agent-related aspects only at the level of roles and functional participation within the CR, rather than through explicit modeling of cognitive, behavioral, or decision-making characteristics. Extending the model toward richer agent representations constitutes a possible direction for future work, especially in training scenarios involving adaptive behavior, expertise progression, or autonomous decision support. Note that the above-discussed design choices are deliberate, as they facilitate the subsequent instantiation of the model in OWL using Protégé, where classes, object properties, and constraints can be directly derived from the conceptual entities introduced in the modeling phase. Consequently, each of these entities, later defined in Section 4.2, is formulated with a one-to-one or one-to-few mapping to ontology primitives (e.g., classes, object properties, and constraints), ensuring coherence between the conceptual model introduced in this section and its formal implementation in the following Section 5. Summarizing, the model establishes the basis for machine-supported reasoning and explainable design and evaluation processes, aptitudes that are otherwise difficult to achieve using purely textual, descriptive, or diagrammatic representations.

4.2. Model Design

This subsection outlines the CR ontology model in terms of (i) the class hierarchy, (ii) object and datatype properties, and (iii) axioms that capture core constraints and enable reasoning. The model is defined to align with the classification of Figure 1 and the modeling scope as defined in Section 4.1, i.e., it represents how the vertical classification of infrastructure-decisional and scope-decisional aspects, as well as functional and informational aspects relates to the classification’s horizontal—broad aspects of the CR, core infrastructure, RLMS, and user-oriented—layers. Figure 2 provides a high-level, consolidated visual representation of the proposed CR ontology. The upper part of the figure presents the high-level conceptual structure, where the CyberRange entity acts as the central aggregation point for decisional, functional, and informational aspects, as well as for the capabilities supported.

The direction of the arrows is intentional, aiming to convey the role of each category. Specifically, decisional aspects are modeled as pointing towards the CyberRange, reflecting that they represent external design-time choices and constraints that shape and define the CR before its realization. In contrast, functional and informational aspects are modeled as emanating from the CyberRange, as they describe operational behaviors and data artifacts that are instantiated and produced by the CR at engineering and runtime phases. Another interpretation for the arrow direction is that decisional aspects represent upstream constraints in the ontology, semantically governing the instantiation of functional and informational aspects and, by extension, the capabilities supported by the CR.

The lower part of the figure depicts how these aspects are systematically specialized across the three horizontal layers of a CR ecosystem, namely the infrastructure, RLMS, and user-oriented layers; the fourth horizontal class of Figure 1, i.e., the broad aspects of the CR, is not depicted as a separate specialization. In the ontology, these aspects are already captured within the decisional aspects and directly associated with the CyberRange entity. Introducing an additional specialization would therefore duplicate decisional constructs without adding semantic differentiation, while disrupting the orthogonality between horizontal layers and vertical aspect types. This layered refinement illustrates the alignment between the ontology and the quad-level CR classification, showing how each aspect type is consistently instantiated at different architectural levels. Together, the two parts of the figure bridge high-level conceptual modeling and layered architectural realization, clarifying how design-time intent propagates to operational functionality, information production, and ultimately to supported CR capabilities.

4.2.1. Classes (Concepts)

At the core of the proposed ontology are the classes that represent the building blocks of a CR ecosystem. Each class corresponds to a fundamental entity that supports the design, implementation, or operation of a CR. The class hierarchy is designed to be both expressive and modular, enabling semantic clarity and reuse across diverse CR types. In this context, the ontology follows a core abstraction as follows: it introduces a root class, CyberRange, which acts as the container entity for each modeled CR instance. This class is semantically enriched by three major abstract categories that capture the essential dimensions of CR design, as summarized below.

• DecisionalAspect: Represents high-level architectural and strategic decisions made during CR conception, such as technology selection or CR focus.
• FunctionalAspect: Encapsulates runtime behaviors, services, and technical modules that operationalize the CR’s objectives (e.g., monitoring, automation).
• InformationalAspect: Covers the data-related artifacts involved in the CR, including configurations, telemetry, logs, or learning content.

To ensure fidelity with the layered structure of CR ecosystems, the model further divides both FunctionalAspect and InformationalAspect into three layer-specific subclasses, matching the infrastructure, RLMS, and user-oriented groups of aspects, as depicted in Figure 2. This layered modeling enables precise annotation of which part of the CR stack is responsible for a given function or produces a particular type of data.

• InfrastructureFunctionalAspect, RLMSFunctionalAspect,
  UserOrientedFunctionalAspect
• InfrastructureInformationalAspect, RLMSInformationalAspect,
  UserOrientedInformationalAspect

In parallel, DecisionalAspect is divided into two subclasses that reflect the two primary domains of CR planning. These distinctions ensure that each design-time decision is associated with the appropriate architectural or instructional concern.

• InfrastructureDecisionalAspect: Includes choices like virtualization technology, infrastructure type, or delivery model.
• ScopeDecisionalAspect: Covers decisions regarding pedagogical strategies, user types, curricula, and evaluation methods.

For each sub-dimension of the decisional aspects (e.g., governance model, learning method), the ontology defines controlled (dedicated) classes that act as vocabularies. For instance, the class Governance represents possible governance structures (e.g., autonomous, federated), while Learning Method captures different instructional paradigms (e.g., self-paced, instructor-led). These controlled vocabularies will later be populated with OWL individuals in the validation phase, detailed in Section 6.

The ontology also introduces the class Capability, which is used to describe what the CR is ultimately able to support, including attack simulation, incident response evaluation, or Capture-the-Flag (CtF) exercises. Unlike lower-level aspects, Capability entities emerge from the composition of decisional, functional, and informational elements. As such, they play a central role in linking design intent to platform resources and serve as useful anchors for reasoning and comparison across CRs. Finally, to enable concrete mapping of functions and services to technical modules or actors, the ontology includes two grounding classes. These grounding entities are intended to bridge the abstract model with concrete platform instantiations and usage scenarios.

• Component: A generic abstraction for tangible software or infrastructure elements, further specialized as InfrastructureComponent, RLMSComponent, and  UserOrientedComponent.
• UserEntity: Represents human actors or groups participating in the CR, with common roles such as Trainee, Instructor, and Team.

4.2.2. Properties (Relationships)

So far, classes define the conceptual entities of the ontology. Consequently, this subsection introduces the properties that delineate how they are semantically connected. In the proposed CR ontology model, properties establish structural dependencies between classes, capture descriptive annotations, and enable logical reasoning over CR configurations. Two main categories of properties are introduced: object and datatype properties. All object and datatype properties are defined with explicit domain and range constraints in the OWL implementation, later detailed in Section 5, ensuring semantic consistency and enabling automated validation in Protégé. Collectively, they transform the ontology from a static classification scheme into a structured, machine-interpretable model that supports reasoning over CR design decisions, operational behavior, and capability realization.

• Object Properties. Object properties describe relationships between instances of ontology classes. Namely, they formulate the semantic backbone of the model, allowing a CyberRange to be represented as a structured and interrelated ecosystem rather than as an isolated conceptual entity.

At the highest level, aggregation properties link a CyberRange to its defining elements. The properties hasDecisionalAspect, hasFunctionalAspect, and hasInformationalAspect associate a CR instance with the respective aspects that characterize its design and operation, as illustrated in Figure 2. Similarly, supportsCapability connects a CyberRange to the Capability concepts it ultimately enables. For reasoning completeness, inverse properties (e.g., isDecisionalAspectOf, isFunctionalAspectOf, isInformationalAspectOf) are defined to facilitate bidirectional navigation and querying in Protégé, later used in the ontology implementation phase in Section 5. Beyond aggregation, the ontology introduces dependency properties that reflect the internal logic of CR design. The properties constrainsFunction, constrainsInformation, and constrainsUsers model how decisional aspects shape the functional and informational and users’ realization and participation in the CR, respectively. For example, a specific delivery model may restrict the orchestration mechanisms that can be deployed. At the same time, a particular learning method may determine which informational artifacts must be generated for evaluation purposes.

To ensure that controlled vocabulary classes are semantically integrated into the ontology, specialization properties are introduced to connect decisional aspects with their corresponding sub-dimensions. For infrastructure-decisional aspects, properties such as hasGovernance, hasDeliveryModel, hasInfrastructureType, hasVirtualization Technology, hasDomain, and hasScope link the abstract decisional entity to the appropriate controlled vocabulary classes. Similarly, scope-decisional aspects are connected through properties such as hasLearningMethod, hasEvaluationPractice, hasCurriculaType, hasPurpose, targetsDidactics, definesUserType, and definesUserTeam. These relations ensure that decisional knowledge is not merely taxonomical but explicitly instantiated and queryable within the ontology. Runtime behavior and data flow are modeled through the properties producesInformation and consumesInformation, which define the interaction between functional and informational aspects. These relationships capture how specific functionalities generate logs, telemetry, learning content, or evaluation results, and how they consume configuration artifacts or user inputs. Inverse counterparts (e.g., isProducedBy) are defined to enhance traceability and consistency in reasoning.

Capability realization is expressed through the property enablesCapability, linking functional or informational aspects to the Capability concepts they contribute to. Identically to aggregation properties, its inverse (e.g., isSupportedByAspect) strengthens interpretability during validation and reasoning. When combined with aggregation properties, this structure enables inference patterns whereby a CyberRange can be automatically classified as supporting a specific capability based on its declared aspects. Finally, grounding relations such as hasComponent and hasUserEntity connect abstract aspects to implementation modules and human actors. These properties link the conceptual model with tangible system elements and user roles, enhancing explainability and applicability. They allow functional aspects defined at a conceptual level (e.g., monitoring or orchestration) to be explicitly associated with the components that realize them within a specific CR deployment. Similarly, linking user-oriented aspects to user entities (e.g., trainees, instructors, or teams) enables the ontology to capture the structure of human participation within the CR. Altogether, this grounding ensures that the ontology remains not only theoretically coherent but also directly mappable to real CR implementations and operational configurations.

• Datatype Properties. In contrast to object properties, datatype properties connect ontology instances to literal values (e.g., strings, identifiers, or numeric attributes). They are primarily used for descriptive annotations rather than structural reasoning. Core metadata properties such as hasName and hasDescription provide human-readable labels and explanations for ontology entities. Versioning and traceability are supported through properties such as hasVersion and hasID. Additional optional attributes, including hasPriority, hasLevel, hasTimestamp, or hasDuration, may be used to annotate complexity, criticality, or temporal characteristics when required by specific use cases.

4.2.3. Axioms (Constraints)

While classes define the structural vocabulary of the ontology and properties define how entities are connected, axioms provide the logical rules that govern their behavior. In the proposed CR ontology, axioms ensure semantic consistency, enforce modeling constraints, and enable automated reasoning within OWL-compliant tools such as Protégé. These constraints formalize the intended interpretation of the model and prevent ambiguous or inconsistent CR descriptions. Regarding disjointness axioms, to preserve conceptual clarity and avoid unintended overlaps between modeling dimensions, we define several disjointness constraints. The three primary aspect categories, DecisionalAspect, FunctionalAspect, and InformationalAspect, are declared pairwise disjoint. This enforces the vertical separation of concerns described in Section 3.1, ensuring that a given element cannot simultaneously represent a design decision, a runtime behavior, and a data artifact.

Similarly, layer-specific subclasses within each aspect pillar are declared mutually disjoint (e.g., InfrastructureFunctionalAspect, RLMSFunctionalAspect, and UserOrientedFunctionalAspect). This guarantees that each aspect instance belongs to exactly one architectural layer, maintaining alignment with the quad-level CR classification of Figure 1. Additionally, the class Capability is defined as disjoint from all aspect and component classes, reinforcing its role as an emergent abstraction rather than a structural or operational element. For completeness and to avoid unintended classification overlap, the classes Component and UserEntity are also declared disjoint, ensuring a clear separation between technical implementation modules and human actors within the CR ecosystem.

Concerning domain and range restrictions, all object properties are defined with explicit domain and range constraints to ensure semantic correctness. For example, hasDecisionalAspect is restricted to link a CyberRange to instances of DecisionalAspect, while producesInformation connects instances of FunctionalAspect to InformationalAspect. Likewise, specialization properties such as hasGovernance or hasLearningMethod are constrained to associate decisional aspects with their corresponding controlled vocabulary classes. These domain and range specifications serve two purposes. First, they guide consistent ontology instantiation. Second, they allow reasoning engines to infer implicit class memberships. For instance, if an individual is linked via producesInformation, it can be inferred to belong to the class FunctionalAspect.

With respect to cardinality constraints, minimum cardinalities are introduced to ensure that a CR description is structurally complete. Each CyberRange must be associated with at least one decisional, one functional, and one informational aspect, reflecting the modeling assumption that a valid CR instance must incorporate design intent, operational behavior, and data manifestation. Similarly, each Capability must be enabled by at least one functional or informational aspect, formalizing the notion that capabilities cannot exist independently of the mechanisms that realize them. Where appropriate, maximum cardinality or functional property constraints are additionally applied. In particular, infrastructure decisional specialization properties are modeled as functional when only a single value is logically admissible per CR instance (e.g., hasDeliveryModel, hasVirtualizationTechnology). Other properties remain non-functional to preserve modeling flexibility in cases where multiple values may be valid. It should be noted that these cardinality constraints ensure minimum structural completeness while remaining compatible with OWL’s semantics, meaning that the absence of explicitly asserted relationships does not imply their non-existence.

To enhance navigability and reasoning expressiveness, several object properties are defined with explicit inverse counterparts. For example, hasDecisionalAspect is paired with isDecisionalAspectOf, and producesInformation with consumesInformation. These inverse relations enable bidirectional querying and strengthen traceability within CR descriptions. Another central reasoning mechanism of the ontology refers to the inference of supported capabilities from declared aspects. For example, the following is formalized through a property-chain axiom (1).

$$\mathtt{hasFunctionalAspect}\circ \mathtt{enablesCapability}\Rightarrow \mathtt{supportsCapability}$$

(1)

This rule states that if a CyberRange has a functional aspect that enables a specific capability, then the CR is inferred to support that capability. Similar reasoning patterns can be applied to informational aspects. Through such axioms, the ontology supports automated capability classification, comparability across CR instances, and explainable validation of CR configurations. Together, these axioms transform the ontology from a descriptive schema into a logically grounded knowledge model. They ensure that CR descriptions remain consistent, complete, and semantically interpretable, while enabling automated reasoning over design decisions, operational characteristics, and emergent capabilities.

4.2.4. Summary of Ontology Elements

Table 2. Summary of Core Ontology Elements for the Cyber Range Ontology Model.

Element Type	Name	Description
Classes (Concepts)
Class	CyberRange	Root entity representing a complete CR instance
Class	DecisionalAspect	Abstract class for design-time decisions
Class	FunctionalAspect	Abstract class for runtime behaviors and services
Class	InformationalAspect	Abstract class for data artifacts and information objects
Class	Capability	Emergent competencies enabled by the CR
Class	Component	Abstract technical module implementing functional aspects
Class	UserEntity	Human actors participating in CR activities
Subclass	InfrastructureDecisionalAspect	Infrastructure-related design decisions
Subclass	ScopeDecisionalAspect	Pedagogical and audience-oriented decisions
Subclass	InfrastructureFunctionalAspect	Infrastructure-layer functionalities
Subclass	RLMSFunctionalAspect	RLMS-layer functionalities
Subclass	UserOrientedFunctionalAspect	User-facing services and mechanisms
Subclass	InfrastructureInformationalAspect	Infrastructure-generated data artifacts
Subclass	RLMSInformationalAspect	RLMS-related informational artifacts
Subclass	UserOrientedInformationalAspect	User-facing or user-generated artifacts
Subclass	InfrastructureComponent, RLMSComponent, UserOrientedComponent	Layer-specific component implementations
Controlled Classes	Governance, DeliveryModel, InfrastructureType, VirtualizationTechnology, Domain, Scope	Infrastructure decisional vocabularies
Controlled Classes	LearningMethod, EvaluationPractice, CurriculumType, Purpose, Didactics, UserType, UserTeam	Scope decisional vocabularies
Object Properties
Aggregation	hasDecisionalAspect/isDecisionalAspectOf	Links CR to decisional aspects (inverse defined)
Aggregation	hasFunctionalAspect/isFunctionalAspectOf	Links CR to functional aspects (inverse defined)
Aggregation	hasInformationalAspect/isInformationalAspectOf	Links CR to informational aspects (inverse defined)
Aggregation	supportsCapability	Declares capabilities supported by a CR
Dependency	constrainsFunction	DecisionalAspect → FunctionalAspect
Dependency	constrainsInformation	DecisionalAspect → InformationalAspect
Dependency	constrainsUsers	DecisionalAspect → UserEntity
Runtime Flow	producesInformation/consumesInformation	FunctionalAspect → InformationalAspect (inverse defined)
Capability Realization	enablesCapability/isSupportedByAspect	Functional/InformationalAspect → Capability (inverse defined)
Grounding	hasComponent	Links FunctionalAspect to implementing Component
Grounding	hasUserEntity	Associates aspects or CR with UserEntity
Specialization	hasGovernance, hasDeliveryModel, hasInfrastructureType, hasVirtualizationTechnology, hasDomain, hasScope	Infrastructure decisional specialization
Specialization	hasLearningMethod, hasEvaluationPractice, hasCurriculaType, hasPurpose, targetsLearningObjective, targetsDidactics, definesUserType, definesUserTeam	Scope decisional specialization
Datatype Properties
Metadata	hasName, hasDescription	Human-readable annotations
Traceability	hasID, hasVersion	Identification and version control
Annotation	hasPriority, hasLevel	Complexity or criticality attributes
Optional	hasTimestamp, hasDuration	Temporal annotations when required
Axioms and Constraints
Disjointness	Aspect Classes Disjoint	$DecisionalAspect$$\perp FunctionalAspect\perp InformationalAspect$
Disjointness	Layer Subclasses Disjoint	Infrastructure ⊥ RLMS ⊥ UserOriented subclasses
Disjointness	Capability Disjointness	$Capability\perp$ Aspect ⊥ Component; Component ⊥ UserEntity
Domain/Range	Property Restrictions	Explicit domain and range constraints for all object properties
Cardinality	Structural Completeness	Each CR has ≥1 decisional, functional, informational aspect
Cardinality	Capability Support	Each Capability enabled by ≥1 aspect
Inverse Properties	Bidirectional Reasoning	$producesInformation\equiv consumesInformatio{n}^{-1}$
Property Chain	Capability Inference	$hasFunctionalAspect\circ enablesCapability\Rightarrow supportsCapability$

recapitulates the structural elements of the proposed CR ontology, grouping them into classes, object and datatype properties, and axioms that define its semantic backbone. The class hierarchy reflects the quad-level CR classification, distinguishing decisional, functional, and informational aspects, while preserving their specialization across infrastructure, RLMS, and user-oriented layers.

A deliberate modeling choice concerns the treatment of leaf elements of the classification of Figure 1. Decisional leaves (e.g., Governance, Purpose, Didactics) are represented as controlled vocabulary classes, since they correspond to categorical design-time selections that are relatively stable, comparable across CR implementations, and suitable for structured reasoning. In contrast, functional and informational leaves (e.g., orchestration modules, scenario development mechanisms, interfaces) are instantiated as individuals under the respective aspect subclasses (e.g., InfrastructureFunctionalAspect, RLMSFunctionalAspect, UserOrientedFunctionalAspect, and their informational counterparts) or, where structurally appropriate, modeled as extensible subclasses within these layer-specific categories. This design preserves alignment with the baseline classification while maintaining flexibility, allowing diverse CR implementations to introduce platform-specific modules or data artifacts without modifying the ontology schema. The object properties listed in the table capture aggregation, dependency, specialization, runtime data flow, capability realization, and grounding relations, enabling traceability from design-time decisions to operational functionality and emergent capabilities. Finally, the axioms enforce disjointness, domain and range constraints, cardinality conditions, inverse relations, and capability inference patterns, ensuring logical consistency and supporting automated reasoning within Protégé.

In addition to the structural overview provided in Table 2, Figure 3 offers a consolidated visual representation of the ontology’s core elements and their interrelations through the corresponding object properties. While Table 2 enumerates the classes, properties, and axioms in a structured textual form, the figure illustrates how these elements are instantiated within the modeling framework introduced earlier through Section 4.1 to Section 4.2 and recapitulated in Table 2. Essentially, Figure 3 complements the tabular summary by visually illustrating how the listed classes and object properties are organized and connected within the ontology. In other words, it depicts the CyberRange entity at the center and its explicit links to decisional, functional, and informational aspects, their layer-specific specializations, and the associated capabilities, rather than presenting the elements in isolation, as summarized in the table.

5. Implementation

The CR ontology introduced in Section 4 was implemented in OWL 2 DL using Protégé. The conceptual model was translated into formal OWL classes, object properties, datatype properties, and logical axioms. The ontology was serialized in RDF/XML format to ensure interoperability with standard Semantic Web tools and reasoning engines. All primary classes of Table 2 were declared as OWL classes. Layer-specific specializations were implemented using rdfs:subClassOf relationships, preserving the orthogonal vertical–horizontal structuring of the model. Controlled vocabulary elements corresponding to decisional leaves (e.g., DeliveryModel, LearningMethod, Governance) were modeled as dedicated subclasses under their respective decisional branches. Grounding classes for technical artifacts and human actors were implemented through the use of Component and UserEntity specializations. Figure 4a presents the inferred class hierarchy as visualized in Protégé. The figure confirms the structuring of vertical abstraction pillars and their horizontal refinements across infrastructure, RLMS, and user-oriented layers.

Object properties were defined with explicit domain and range constraints to enforce semantic correctness. Aggregation, dependency, runtime flow, capability realization, and specialization properties were implemented according to the design summarized in Table 2. Figure 4b illustrates the object property hierarchy in Protégé, showing the complete set of relationships supporting CR aggregation and capability inference. Logical constraints were encoded using OWL disjointness axioms, qualified minimum cardinality restrictions for structural completeness of CyberRange instances, and functional object properties for infrastructure decisional specialization. The ontology was validated using the HermiT 1.4.3.456 reasoner in Protégé, confirming logical consistency and correct enforcement of modeling constraints, as shown in Figure 5. At this point, it is important to notice that this reasoning capability is one of the principal advantages of the proposed ontology. Namely, unlike traditional architectural representations, which, as the reader may recall from Section 1, remain descriptive and require manual interpretation, the OWL 2 DL formalization enables automated logical verification and inference over CR configurations, beyond just structured querying (e.g., SPARQL queries). Specifically, reasoning provides the following capabilities.

• Consistency checking: The reasoner automatically detects violations of disjointness axioms, domain and range constraints, and cardinality restrictions.
• Structural completeness: The reasoner verifies that each CyberRange instance satisfies minimum cardinality requirements, ensuring the presence of decisional, functional, and informational aspects as mandated by the ontology model introduced in Section 4.
• Implicit classification: The reasoner infers class memberships based on asserted object property relations and their declared domain and range constraints.
• Capability inference: The reasoner applies property-chain axiom (1) to propagate enabled capabilities from functional aspects to the corresponding CyberRange instance.
• Constraint enforcement: The reasoner ensures that decisional aspects semantically constrain admissible functional and informational realizations, maintaining coherence between design-time decisions and runtime behavior.

These reasoning mechanisms elevate the ontology from a structured vocabulary to a logically grounded validation and inference framework capable of supporting explainable CR configuration analysis. Note that, at this stage, reasoning operates exclusively at the schema level (i.e., over classes and axioms), since no CR instances have yet been introduced. Consequently, the reasoner performs ontology classification and constraint verification but does not produce instance-level inferences. More expressive reasoning outcomes, such as automatic capability inference for specific CR configurations, require the introduction of individuals and are demonstrated in the validation phase, presented later in Section 6.

From a technical standpoint, the ontology conforms to the OWL 2 DL, ensuring decidability and compatibility with standard DL reasoners. The use of qualified cardinality restrictions, inverse object properties, functional properties, and property-chain axioms remains within the expressive bounds of SROIQ(D) [32], allowing complete reasoning under HermiT without compromising computational tractability. The ontology was exported in RDF/XML syntax using the OWL Application Programming Interface (API) integrated in Protégé, enabling straightforward reuse, extension, and integration with external Semantic Web frameworks. No custom rules, Semantic Web Rule Language (SWRL) expressions, or non-standard extensions were introduced, ensuring portability and compliance with standards.

6. Validation

To validate the expressive adequacy and reasoning capabilities of the proposed CR ontology, a CR platform, namely KYPO [19], was instantiated as an ontology individual. The objective of this validation phase is threefold: (i) to demonstrate structural completeness of the model at the instance level, (ii) to verify automated reasoning over capability realization, and (iii) to evaluate the ontology using representative competency questions expressed in the SPARQL protocol.

As presented in [19], KYPO is an open-source cyber range platform designed for hands-on cybersecurity training and cyber defense exercises. Architecturally, it relies on virtualized infrastructure resources for sandbox provisioning and isolation, enabling the deployment of reproducible training environments. The platform incorporates mechanisms for scenario definition and lifecycle management, automated orchestration of training instances, remote user access through a web-based interface, and collection of telemetry and evaluation data. Its design supports multi-user and multi-team execution modes, facilitating both individual and collaborative exercises. Note that KYPO was selected for validation purposes due to its high citation impact in the CR literature, comprehensive architectural documentation [19,33,34,35,36,37], and well-defined modular design, which collectively provide sufficient publicly available technical detail to support ontology instantiation.

Figure 6 illustrates the object property assertions of the instantiated individual KYPO_CyberRangePlatform as visualized in Protégé after reasoning. The upper portion of the panel displays the explicitly asserted relations linking the CR instance to its decisional, functional, and informational aspects. In contrast, the supportsCapability relations highlighted in yellow correspond to inferred object property assertions generated by the reasoner. These inferred relations are not directly asserted in the ontology but are derived from the composition of hasFunctionalAspect and enablesCapability, as formalized by the property-chain axiom (1). The figure therefore provides direct evidence of successful ABox-level [38] reasoning and confirms that capability realization is correctly propagated to the CR instance level. To further assess the ontology’s queryability and semantic coherence, three representative Competency Questions (CQ) were formulated and evaluated using SPARQL queries executed within Protégé, as shown in Figure 7, Figure 8 and Figure 9.

CQ1. Which functional aspects are associated with the instantiated CR platform? The results shown in Figure 7 confirm that the instantiated CR is associated with three functional aspects, corresponding to infrastructure-level sandbox provisioning, scenario lifecycle management, and user-oriented remote access mechanisms. The query outcome verifies the structural completeness of the instantiation with respect to the functional dimension of the ontology, demonstrating that functional aspects are explicitly retrievable through object property assertions. This confirms that the aggregation relation hasFunctionalAspect is correctly instantiated and queryable, enabling transparent inspection of the operational capabilities embedded within the CR configuration.

CQ2. Which capabilities are enabled by each functional aspect? The results depicted in Figure 8 reveal the mapping between functional aspects and the capabilities they enable. The query confirms that each functional aspect contributes to one or more higher-level competencies, thereby enacting the linkage between runtime behavior and emergent CR capabilities. This mapping illustrates the internal traceability supported by the ontology, demonstrating how operational mechanisms realize distinct training and execution capabilities. The outcome validates the correct instantiation of the enablesCapability relation and provides the logical foundation for the subsequent inference of CR-level supported capabilities.

CQ3. Which capabilities are supported by KYPO? The results shown in Figure 9 present the reconstructed set of capabilities supported by the instantiated KYPO platform. Although the supportsCapability relation is not explicitly asserted in the RDF graph, the query faithfully reproduces the entailment defined by the property-chain axiom (1) through the composition of hasFunctionalAspect and enablesCapability. Therefore, the returned capabilities correspond to those inferred by the reasoner at the ABox level, confirming semantic consistency between logical inference and query-based retrieval. This outcome demonstrates that the ontology enables capability-level assessment of a CR configuration and supports transparent traceability from operational mechanisms to emergent competencies. A direct SPARQL query over supportsCapability returned no results, as this relation is inferred by the reasoner and not materialized in the asserted RDF graph. Therefore, the competency question was reformulated according to the entailment pattern of the property-chain axiom (1):

• Key Takeaways: KYPO was selected as an illustrative instantiation case because it is open-source, well-documented, and sufficiently rich to exercise the proposed ontology’s structural and reasoning mechanisms, as previously mentioned. However, it should be noted that the ontology itself is not restricted to virtualized CRs such as KYPO. Namely, at the schema level, it explicitly models architectural variation through decisional aspects such as domain, infrastructure type, delivery model, governance, and virtualization technology, which semantically constrain the admissible functional and informational realizations of a CR. Simply put, this design allows the same ontology to describe hybrid cyber–physical ranges, distributed or federated environments, and other architectural configurations. Accordingly, the present validation should be interpreted as a proof-of-instantiation and reasoning feasibility, rather than as an exhaustive empirical coverage of heterogeneous CR architectural paradigms.

Moreover, the validation demonstrates that the proposed ontology supports the consistent instantiation of CR platforms while preserving logical soundness under OWL 2 DL semantics. The successful execution of the HermiT reasoner confirms that structural constraints and disjointness axioms are maintained at both schema and instance levels. Moreover, capability support is automatically inferred through the defined property-chain axioms, validating the intended reasoning mechanisms for propagating operational functionality to CR-level competencies. The formulation and execution of competency questions via SPARQL further illustrate that the ontology correctly enables the structured retrieval of design-time and runtime knowledge. In other words, these findings confirm that the proposed model operates not merely as a static classification scheme, but as a logically grounded, machine-interpretable knowledge framework capable of supporting CR configuration analysis, traceability across abstraction layers, and capability-based evaluation.

7. Visualization

To complement the ontology model presented in Section 4 and the Protégé-based implementation introduced in Section 5 with a more practical and accessible interaction layer, we also developed a lightweight web-based visualization interface. The motivation for this component is to facilitate non-expert stakeholders, such as CR instructors, evaluators, and managers, who may benefit from the ontology’s reasoning outputs without interacting directly with OWL editors, DL formalisms, or raw SPARQL endpoints. Essentially, the visualization layer serves as an application-oriented interface that translates semantic structures and query results into an interpretable, operationally useful form.

Specifically, the interface is implemented as a simple web application in which a user uploads an ontology instance file in OWL/RDF format, after which the system parses the uploaded knowledge base and enables interactive querying and result inspection. Namely, the frontend provides a dashboard-style overview of the uploaded ontology, including indicative statistics about detected entities and aspect-related elements, as well as a dedicated prompt area for user-defined SPARQL queries. Query execution is handled by a lightweight backend service that loads the uploaded ontology, evaluates the submitted SPARQL query, and returns the corresponding result bindings to the interface for visualization. In this way, the interface serves as a bridge between ontology-based knowledge representation and user-facing decision support.

Functionally, the visualization layer is intended to support three complementary forms of interaction, each of which is reflected in the interface snapshots shown in Figure 10 and Figure 11. First, as illustrated in Figure 10, it offers an overview of the uploaded CR ontology instance through a set of interface components. These include the file-upload panel, allowing the user to submit an OWL/RDF ontology instance; a summary section reporting indicative counts of detected entities and aspect-related elements; an entity browser that lists extracted ontology identifiers and supports quick inspection of the uploaded model contents; an inferred-capabilities panel presenting selected CR capabilities together with indicative confidence levels and dependency cues; and a warning section highlighting potentially missing semantic elements or weakly supported CR characteristics. In this way, the overview page provides an immediate high-level picture of the modeled CR configuration without requiring direct interaction with ontology editors or raw RDF structures.

Second, as shown in Figure 11, the interface enables direct exploration of semantic relations through user-submitted SPARQL queries, making it possible to retrieve structured information from the knowledge base without manually interacting with the ontology engineering tools used in Section 5 and Section 6. In particular, the query panel consists of a dedicated text area for SPARQL input, an execution control, a status field indicating the outcome of the submitted query, and a tabular results component that displays the returned bindings in a readable form. The depicted SPARQL query is identical to the second CQ (Figure 8) of Section 6. The prototype was evaluated in a local testbed, the main software and hardware characteristics of which are summarized in

Table 3. Summary of the testbed used for the visualization prototype.

Component	Description
Frontend framework	React 19.2.4
Frontend build tool	Vite 8.0.3
Backend language	Python 3.9.11
Backend framework	Flask 3.1.3
RDF/SPARQL library	RDFLib 7.6.0
Operating system	MS 11 10.0.26200
Processor	Intel(R) Core(TM) i7-10700 CPU @ 2.90 GHz
Memory	16 GB RAM
Open-Source Repository	[39]

.

8. Limitations & Future Work

The proposed ontology provides a formally grounded and semantically coherent representation of CR ecosystems; however, several limitations must be acknowledged, and corresponding directions for future research are outlined to guide its further extension and refinement.

• Abstraction Level. The ontology is conceptualized and instantiated at a domain abstraction level and does not capture low-level implementation details of specific CR platforms. Namely, it models architectural, functional, informational, and decisional aspects in a technology-agnostic manner. Consequently, highly platform-specific configurations, deployment scripts, infrastructure-as-code artifacts, or detailed runtime orhestration logic are intentionally abstracted. This design choice enhances generalizability and cross-platform comparability, but it limits direct operational automation or platform-level configuration assembly without additional extensions. In this context, future research may focus on extending the ontology with optional implementation-level modules that align CR functional aspects with concrete deployment descriptors (e.g., container orchestration manifests, virtualization templates, or network configuration schemas). Specifically, structured deployment artifacts, such as Terraform specifications, Ansible playbooks, Yet Another Markup Language (YAML)-based descriptors, or virtualization templates, could be processed through dedicated parsers and schema-mapping layers to extract infrastructure entities, services, dependencies, and configuration parameters, which could then be transformed into ontology individuals and semantic relations. Such extensions could facilitate automation of CR deployment workflows while preserving the abstraction principles of the existing ontology.
• Scalability of Instance-Level Reasoning. The current validation does not assess the computational scalability of the proposed framework under large ABox populations that may be generated by dynamic runtime artifacts, extensive configuration data, or assessment-related information. In such settings, performance overhead would be expected to arise both from repeated instance-level OWL reasoning over growing volumes of asserted individuals and from SPARQL query execution over increasingly populated knowledge bases. This is particularly relevant in large-scale, multi-team, or federated CR environments, where both inference cost and query response time may become critical practical factors. Therefore, the ontology is currently more appropriate as a semantic abstraction layer over curated runtime summaries than as a direct reasoning and query mechanism over raw high-frequency operational streams. In this direction, a meaningful future avenue is investigating benchmark-driven scalability assessment, including incremental reasoning strategies, query optimization and indexing techniques, and hybrid semantic architectures in which large-volume runtime telemetry is pre-processed externally and only semantically relevant aggregates or events are injected into the ontology for higher-level inference and scalable knowledge-base access.
• Expressiveness Boundaries. Although the ontology conforms to the OWL 2 DL, supporting decidable reasoning, its expressive power is bounded by DL semantics. That is, complex procedural constraints, dynamic workflows, temporal sequencing of CR activities, or conditional logic between events beyond the native representational scope of DL-based ontologies. Such behaviors would require rule-based extensions (e.g., SWRL) or integration with process-oriented formalisms. Future extensions may investigate the integration of rule-based reasoning mechanisms or alignment with process modeling frameworks (e.g., BPMN-derived ontologies or temporal logics) to represent dynamic CR workflows and event-driven behavior.
• Absence of Quantitative Evaluation Modeling. The ontology emphasizes structural and semantic relationships rather than quantitative evaluation metrics. Performance indicators, scalability measurements, resource utilization metrics, or detailed learning analytics are not formally encoded beyond optional datatype annotations. As a result, quantitative assessment of CR effectiveness remains outside the current modeling scope. Future research may incorporate dedicated evaluation and performance modeling modules, potentially through alignment with metric-oriented ontologies, learning analytics vocabularies, or evaluation formulas, such as the ones introduced in [14]. Such extensions would help the formal representation of CR attributes and support maturity assessment and benchmarking across heterogeneous platforms.
• Structural Capability Inference. Capability inference is currently based on structural composition through property-chain axioms, as highlighted in the property-chain axiom (1). This mechanism supports automated classification and traceability; however, it does not evaluate the qualitative adequacy, performance level, or maturity of the supported capability. Therefore, the ontology determines whether a capability is structurally supported, but not the degree to which it is effectively realized. Future work may explore the incorporation of graded or weighted capability models, integrating qualitative assessment criteria or maturity-level ontologies. Specifically, a theoretically feasible extension would involve associating capability-supporting entities with quantitative indicators through datatype properties, thereby enabling threshold-based classification of maturity levels within OWL 2 DL. In this way, inferred capabilities could be further qualified according to their degree of readiness, coverage, automation, or similar evaluation dimensions. However, more expressive mechanisms, such as weighted metric aggregation and temporally ordered reasoning over capability realization, would require complementary rule-based or process-oriented semantic extensions beyond the native scope of OWL 2 DL. Ultimately, such enhancements could allow reasoning not only about capability presence but also about capability quality, effectiveness, or operational readiness.
• Scope of Empirical Validation. While current validation confirms logical consistency and structural integrity through an illustrative case-study instantiation, broader empirical validation across heterogeneous CR deployments would further strengthen the versatility of the proposed model. Although the selected CR platform provides a representative and well-documented example, future validation efforts may involve instantiating the ontology across multiple CR platforms with diverse architectural paradigms and conducting comparative capability analyses. For example, extending validation to CR instances with heterogeneous architectural characteristics, including CPS-oriented and federated deployments [40,41], would support assessment of the ontology’s portability and the stability of its reasoning patterns across substantially different CR implementations.
• Quantitative Assessment of the Ontology. The current study validates the ontology primarily through logical consistency, illustrative instantiation, and competency-question-driven querying, but it does not provide a quantitative evaluation of the framework itself in terms of performance, usability, or empirical benchmarking across multiple CR instances. As a result, the practical applicability of the proposed approach is assessed qualitatively rather than through quantitative metrics. Therefore, future work may investigate benchmark-based evaluation protocols, comparative instantiation studies, and user-oriented assessment methods to more rigorously evaluate the utility, scalability, and applicability of the ontology in diverse CR settings.
• Human-in-the-Loop Semantics. The current ontology captures agent-related aspects only at the level of roles (UserType and UserTeam) within the CR environment, without modeling HitL semantics. In this context, cognitive, behavioral, and expertise-related characteristics of agents, including decision-making patterns, learning progression, or adaptive responses, remain outside the present scope of the framework. In this direction, future work can investigate richer semantic representations of human and autonomous agents in CR settings, particularly for scenarios involving adaptive training, intelligent assistance, or cognitively informed evaluation processes.
• Visualization Prototype Maturity. The web-based visualization layer introduced in Section 7 is currently implemented as a lightweight PoC interface intended to demonstrate the practical feasibility of exposing ontology content and SPARQL-based reasoning outcomes to non-expert stakeholders. As such, it does not yet constitute a full-featured production environment and presently offers only a limited set of interaction mechanisms, centered on ontology upload, dashboard-style summaries, and ad hoc SPARQL query execution. Future work may therefore extend this layer with richer visualization and interaction capabilities, including predefined CQ templates, graphical dependency views, capability-oriented dashboards, result filtering and export, and comparative visual analytics across multiple uploaded CR ontology instances.

9. Conclusions

This paper introduced an ontology-based framework for the formal representation of CR ecosystems. To the best of our knowledge, this is the first attempt to formally model a CR ecosystem using a domain ontology that represents its structural, functional, informational, and decisional aspects in a unified semantic framework. In contrast to the current state of affairs, where architectural descriptions are mostly semi-formal, our approach offers a semantically rich and machine-processable representation that not only encodes the structural makeup but also the design intent of CR platforms. The ontology is structured along two orthogonal dimensions: a vertical abstraction distinguishing decisional, functional, and informational aspects and emergent capabilities, and a horizontal specialization that spans infrastructure, RLMS, and user-oriented layers. This two-fold organization ensures that the ontology is consistent with widely accepted CR categorizations and maintains a clear and modular conceptualization. The model is implemented in OWL 2 DL using Protégé, incorporating domain and range constraints, disjointness axioms, cardinality restrictions, inverse properties, and property-chain rules, enabling logical validation and automated reasoning over CR configurations. The validation process was performed by instantiating a representative CR platform, verifying structural completeness, consistency under reasoning, and automated capability derivation. Furthermore, competency questions expressed in SPARQL confirmed the ontology’s suitability for structured querying and traceability analysis across design-time and runtime dimensions. Overall, the results indicate that the proposed ontology transcends static classification and functions as a logically grounded knowledge framework for CR modeling. The proposed framework lays the foundation for systematic comparison and capability-based evaluation of heterogeneous CR implementations.