Core Ontology Usability: From a Formalized Knowledge Base to the Development of a System of Systems Domain Understanding

Abstract

This paper describes the step-by-step processes towards the formalization of a core ontology for missions and capabilities in systems of systems, and the development of a specific system of systems domain ontology from the formalized ontology. The study traces the ontology development process through the SABIOx methodology’s requirements, setup, capture, design, and implementation phases. In this process, we demonstrate the core ontology’s usability and reusability. Usability refers to the ontology’s adequacy for specific use as a reference point for SoS knowledge exploration for development and operational purposes, and reusability refers to the ontology’s adequacy for several uses, such as facilitating the understanding of different domain-specific systems of systems. This demonstration is done in three steps: formalization of the core ontology, exploration of the usefulness of this formalization, and development of a domain ontology from the core ontology. These result in: the incorporation of systematic ontology development processes; the application of ontology tools for machine readability; coherence and consistency checking of the ontology artifact; querying support for the ontology knowledge base; and testing of the core knowledge with a domain-specific system of systems. An alignment of these aspects provides different points of view of how a system of systems can be formulated, how the concepts collectively describe the development of an SoS emergent behavior, and how the ontology knowledge base can be explored to support decision frameworks guiding a system of systems.

1. Introduction

This study implements a formalization and usability assessment of an ontological approach to understanding System of Systems (SoS). An SoS is a system that implements its emergent behavior by leveraging the capabilities of independent constituent systems (CS). SoS are characterized by the diversity, heterogeneity, operational and managerial independence, and the evolutionary development of their CS [1]. These characteristics highlight the need for different thinking principles for SoS, compared to traditional integrated systems, where systems engineering problem-solving approaches suffice. This is because an SoS brings different perspectives to interaction, interdependence, integration, and objectives of a system.

SoS are characterized by different pain points, i.e., areas of interest that constrain SoS development and operation. Some pain points relate to how systems engineering efforts can be applied towards SoS capabilities, interdependencies, collaboration patterns, leadership, and thinking principles [2]. What then is a reasonable approach to create a theoretical understanding of the development and operations of an SoS? How can one create a holistic view that governs interrelationships and processes, while allowing one to envision both the structural and dynamic aspects of an SoS? One approach is to leverage the art of systems thinking that allows one to develop a framework for analyzing the synergy of the interaction of parts [3], knowing that the whole is greater than the sum of the parts. This comes with the need to facilitate the understanding of holism in SoS. How can we then use systems thinking for a more generalized solution to formulate and explain the essence of an SoS? Addressing this question points us towards knowledge representation for SoS to pave the way towards creating and supporting SoS thinking principles.

1.1. Research Problem

This study seeks to support SoS thinking principles by developing SoS knowledge representation through an ontology-driven approach. Various studies have explored knowledge representation in SoS, including a metamodel for SoS ontologies [4], the use of ontology frameworks to describe SoS emergence [5], and SoS architecture principles [6]. However, these studies do not explicitly seek to create a core understanding of SoS, a gap that is addressed in this study. This study is motivated by what INCOSE envisions as the future of systems engineering (SE) [7], i.e., “SE is predominantly model-based”, and SoS are envisioned as “designed with unified modeling approaches and established to include common style guides, patterns, methodologies, and practices that integrate different aspects of systems, from their social-technical nature to the sociology of their existence.” A unified approach calls for a unified understanding. Ontology-driven approaches provide a shared conceptualization of a domain. Moreover, such approaches are driven by the need for consistency and conformance to existing domain knowledge and rules, and continuous evolution as knowledge evolves. A conceptualization abstracts reality, to balance truthfulness to reality, i.e., domain appropriateness, with conceptual clarity, i.e., comprehensibility [8]. Overall, an ontological approach creates a machine-readable representation that can be queried and inferred, making the ontology model more usable using ontology tools.

1.2. Ontology Usability

ISO 9241-11:2018 defines Usability as “the extent to which a product can be used by specified users to achieve specified goals with effectiveness, efficiency, and satisfaction in a specified context of use” [9]. This suggests a more external view of usability. However, the use of the word usability in our study does not separate internal and external views. This study looks at usability from three main aspects, namely syntax, semantics, and pragmatics, as described by [10]. Syntax conveys the rules and structural appropriateness. Semantics conveys literal clarity. Pragmatics conveys contextual awareness. Since our focus is on a core ontology and its usefulness in the development of domain ontologies, we think of both usability, and reusability, i.e., usability as the adequacy for a specific use, and reusability as the adequacy for several uses [11]. Thinking of the syntactic, semantic, and pragmatic levels lets us reflect on semiology, “a philosophical and scientific study of how meaning is communicated” [12]. As they represent formalized conceptualization, ontologies are semiotic objects that communicate meaning in a particular manner for a particular purpose.

1.3. Contributions

The main contributions of this study are:

• A formal representation of a core ontology for missions and capabilities in SoS in an ontology language, and subsequent testing of the constraints defined in the core ontology.
• Insights into how a formalized ontology can be queried to support the categorization and characterization of different kinds of decisions inherent in an SoS.
• A proposed mapping of the core ontology into a domain ontology, to understand the contextual usability of the ontology in a real-world SoS.

The remainder of the paper is structured as follows: Section 2 gives a brief overview of the SABIOx methodology employed in this study. The following sections describe the phases of the SABIOx methodology, i.e., the requirements phase (Section 3), the ontology set-up phase (Section 4), the capture phase (Section 5), the design phase (Section 6), and the implementation phase (Section 7). Section 8 discusses the findings, and Section 9 concludes the paper.

2. Methodology

As knowledge representation artifacts, ontologies go through a lifecycle of their own. Therefore, to understand the usability of the core ontology, we trace its lifecycle phases through its development process. To accomplish this, the study employs the Extended Systematic Approach for Building Ontologies (SABiOx) [13] methodology. The SABIOx methodology describes five phases for ontology development. Each phase is described with its associated inputs, processes, and outcomes. These SABIOx phases are as described in the following sections, and depicted in Figure 1.

The phases of the SABIOx methodology are [14]:

• Requirement phase: describes the what, why and what-for of the ontology.
• Setup phase: defines questions and criteria that will guide the ontology development, and therefore, the choice of modeling-related frameworks.
• Capture phase: identifies ontology concepts and axioms by answering the setup phase questions, and by using expert knowledge to implement desired constraints for the domain.
• Design phase: makes technology-based implementation decisions, covering the codification and presentation of the ontology in a machine-readable tool.
• Implementation phase: implements the ontology in a formal language, followed by verification and validation of its implementation.

This study gives an overview of all phases to put the ontology development in the right perspective. However, the greater focus of this study is on the design and implementation phases, whose activities include the ontology formalization process and the extrapolation of a domain ontology. The following sections elaborate on work done in each phase as referenced from the SABIOx methodology [14].

3. Requirements Phase

The requirements phase seeks to identify the purpose, reasons, and designated users of the ontology. This phase produces a specification document describing what the ontology is about, why it was developed, its purpose, and prospective users. This phase involved brainstorming, workshops, and discussions with industry representatives from Volvo Construction Equipment and Saab. These were done in the context of the Mission and Capability Engineering for SoS (MACE4SoS) project, which incorporated industry and academia collaboration of experts in the defense sector, enterprise architecture, software engineering, and systems of systems.

(a)

Purpose definition

We focus on developing an ontology to provide an explanatory model of the SoS domain, hinged on two aspects, mission and capability, and aimed at supporting SoS thinking principles. The designated users of this ontology include the scientific community, and SoS practitioners interested in knowledge representation and alignment, and learning the complexity of SoS.

(b)

Identifying and sizing of the domain

This ontology is a core ontology for mission and capability in SoS, i.e., a minimal list of concepts and relationships to describe the SoS domain in an application-agnostic manner. Through analyses of the scenarios of the domain-specific SoS case studies, we extracted the knowledge of the SoS domain embedded in the scenarios.

(c)

Requirements elicitation

The activities in this step involve the identification and negotiation of requirements. It highlights how the ontology team defines the functional and non-functional requirements for the ontology.

Functional requirements are defined through three high-level exploratory questions, which are translated into more specific competence questions (CQ). These exploratory questions are:

• What does an SoS require?
• How does an SoS operate?
• What does an SoS realize?

Requirements are explained in terms of capabilities, operations in terms of capability configurations, and realizations in terms of missions implemented by the SoS.

Non-functional requirements are grouped in three categories: quality, design, and intended use:

• Quality requirements focus on different usability aspects of the ontology.
• Design requirements focus on simplicity, availability, and subsequently the definition of design decisions, including: the choice of an open-access, user-friendly ontology language, a popular ontology editing tool, and the reuse of existing concepts.
• Intended use requirements focus on the very purpose of the ontology, i.e., scientific alignment. In this, we checked how the ontology aligns with existing foundation ontologies and ontology foundries.

(d)

Identification of subdomains

From the pre-defined exploratory questions, three subdomains stand out: requirements, operation, and realization. Understanding these subdomains offers an opportunity to incorporate modularity in the ontology by explicitly extending the core ontology with existing ontologies of these subdomains.

These steps, accompanied by documentation, control of specifications, and evaluation, result in valuable input for the setup phase.

4. Setup Phase

The setup phase formulates questions and criteria guiding the ontology development. These formulations end up defining the decisions that impact the ontology modeling tasks, including: the definition of the modeling language, the conceptualization definition of what qualifies as a concept for the domain, the choice of foundational ontology baselines, and the re-use of existing ontologies. The outcome of the setup phase is the reference ontology. The reference version of the core ontology is expressed informally in the Unified Modeling Language (UML) [15]. The choice of UML follows its simplicity and understandability in expressing relations and corresponding cardinality between concepts of the ontology.

From the high-level exploratory questions defined in the requirements elicitation step in the requirements phase, the setup phase breaks down these high-level questions into more specific competency questions (CQ). This breakdown highlights what is actually part of the ontology, i.e., in terms of the SoS requirements, operations, and realization. These are summarized in the following list:

(a)

SoS requirements: how the independent systems contribute their capabilities in SoS.

-

Which systems does the SoS contain?

-

Which capabilities are provided by these systems?

(b)

SoS operation: the formation of constellations, the creation of mission threads, and the creation of capability configurations. These show variations and possibilities in the SoS.

-

Which constellations are possible in this SoS?

-

Which mission threads are addressed by which constellations?

-

Which capability configuration options are possible in an SoS?

(c)

SoS realization: identification of specific missions in the SoS.

-

Which missions are part of this SoS?

5. Capture Phase

The capture phase catalogues the respective ontology concepts, relations, and axioms by answering the setup phase questions using expert knowledge to implement the respective constraints for the domain. This phase involves cataloging of concepts. For this core ontology, the capture phase involved different stages and milestones. The overall capture process was iterative, and included stakeholder workshops which incorporated industry participation, case study analysis, and illustrations. The workshop sessions included discussions, feedback, and case study illustrations using wildfire crisis management SoS case provided by Saab, and road asphalt paving construction case study from Volvo Construction Equipment. These workshops included participants with expertise in business architecting, software engineering, systems engineering, systems of systems, defense, and construction equipment. The processes in this phase led to:

• The identification of 13 main concepts for the core ontology, with some subclasses and attributes. The knowledge sources for the core ontology concepts include: engineering handbooks, standards, manuals, frameworks, and research studies. The catalogue of concepts was adapted from ISO/IEC/IEEE 21839 [16], ISO/IEC/IEEE 15288:2015 [17], Object Management Group (OMG) Unified Architecture Framework Modeling Language [18], United States Department of Defense (US-DoD) architectural framework [19], and Mission Engineering Guide [20]. This is followed by the definition of axioms and modeling of the ontology in a technology-independent representation.
• Preliminary efforts were made to demonstrate the views of the ontology. Three views were identified: capability, mission, and configuration views [21]. The capability view highlighted how capabilities are generated and interfaced, therefore, covering attributes such as capability definition and CS identification. The mission view highlights mission decomposition and mission thread execution, where the attributes include mission context and constraints. The configuration view highlights constellation, measures, and capability configuration operations, where the attributes included capability tradeoffs, standards, and frameworks [21]. These three views, i.e., capability, mission, and configuration views, highlighted different abstraction levels corresponding to SoS requirements, planning, and implementation, respectively.
• Ontology revision. The ontology was further revised. The revision aimed at further minimizing the concepts to reflect the core of SoS. This resulted in the reduction of concepts from 13 to 9. This reduction was a result of continuous improvement and an exploratory study, which implemented a survey and an interview-based evaluation study [21]. This study employed the Formal Ontology Content Alignment (FOCA) methodology that evaluated the goal-question-metric, i.e., a correlation of the objective of knowledge representation, the knowledge representation roles, and the quality criteria of the respective goals. The focus was on checking the adequacy and relevance of the core ontology with specific emphasis on coherence, i.e., consistency, conciseness, and completeness. The evaluation employed a convenience sampling of practitioners in diverse fields, ranging from software architecting and model-based engineering, to defense-related operations research.
• Ontology benchmarking: This modified version of the ontology was benchmarked against a foundation ontology. The focus of the mapping is to employ analogy and identify what kind of entities are contained in the reference ontology. The Basic Formal Ontology (BFO), as discussed by Arp et al. [22], was employed to show the kind of entities represented by the ontology concepts [15]. The core ontology is therefore a mix of different kinds of BFO entities: object, object aggregate, disposition, planned process, design specification, and plan specifications. This mapping tells the ontology user what is expected of each concept of the ontology. It also highlights how the ontology relates to entities from other ontologies and foundries.

The outcome of this capture phase is a complete reference ontology, with axioms described in natural language and with a model dictionary, as summarized in Figure 2.

6. Design Phase

In this stage, the architecture of the formal ontology is derived from the reference ontology. The input to this phase is the reference ontology as depicted in Figure 2. This phase defines technology-based implementation decisions and decides on the ontology codification rules and guidelines. It responds to how the technological choice positively or negatively affects the requirements defined in the requirements phase. Activities involved in this phase include:

• Choice of encoding language: The requirements of an ontology language are highlighted as characterized by “well-defined syntax and semantics, efficient reasoning support, sufficient expressive power, and convenience of expression” [23]. We opted for Web Ontology Language (OWL), which is highly popular in the ontology community. OWL reasonably fulfills the language requirements by building on the Resource Description Framework (RDF) data model and Resource Description Framework Schema (RDFS) hierarchy support. Since OWL is based on mathematical logic, it also supports the application of reasoning engines. We explore and use OWL in Protégé, an ontology editing tool [24].
• Definition of ontology encoding: choice of presentation rules is based on standard encoding techniques.

The design phase choices are summarized in

Table 1. Summary of ontology codification with respective symbols as seen in the ontology editor.

Codification Item/Protégé Symbol	Operational Ontology
Language	Web Ontology Language (OWL) with Description Logic (DL)
Core class name	Follow the pattern Pascal Case, with no space: SystemOfSystems, System, Capability, CapabilityConfiguration, Constellation, Mission, MissionThread
Domain class name	Follow the pattern Pascal Case: AssessTerrain, ControlFire
Object property name	Follow Camel Case pattern: e.g., isMadeUpOf
Data property name	Follow Camel Case pattern: e.g., accuracyLow
Instance name	Follow Snake Case pattern: e.g., move_equipment
Class description	Classes are described using the comment property of RDFS
Specialization relationships	Defined using the subClassOf property of Resource Description Framework Schema (RDFS)

.

7. Implementation Phase

The implementation phase aims to transform the reference ontology into an operational ontology, i.e., a machine-readable version. This entails ontology encoding, verification, and validation. The encoding process is characterized by the choice of language and framework, the application of ontology tools, and the implementation of constraints. The verification process checks that the ontology is built right, i.e., built with the right syntax, and is consistent; on the other hand, validation focuses on the accuracy of the representation of the essence of SoS and its response to the ontology’s competence questions. The implementation process highlights different kinds of errors the ontology is prone to. These fall in different categories including, hierarchical errors (Taxonomy), design errors such as redundancies, or encoding errors such as incorrect syntax [25].

7.1. Encoding

The encoding process involved transforming the concepts and relationships from the UML model into an OWL model. This meant defining and differentiating bi-directional relationships between concepts, domain and ranges of these relationships, as well as their inverses. The blue-highlighted relationships are encoded with the respective domain and range, i.e., as global relationships, the corresponding inverse relationships are highlighted in brown in Figure 3. The encoding process involved the analysis of loops within the ontology to identify potential errors linked to the compositional structure of the ontology. This analysis led to the revision of the relationships between capability and capability configuration. This was necessary to differentiate the ontology’s two forms of capability, i.e., CS capability and SoS capability, corresponding to the capability of constituent systems and the capability of the SoS, respectively. These were added as subclasses of the Capability concept. The OWL-implemented ontology is examined using reasoners, resulting in consistent and coherent reasoning. Having implemented the core ontology, the next step was to verify and validate the implementation.

7.2. Verification

Ontology verification checks the internal consistency of the ontology. This includes the logical consistency, alignment, reasoning, and the correct use of ontology patterns. The SABIOx methodology suggests that: “For ontology verification, one must evaluate whether the functional and non-functional requirements raised are answered by means of queries applied on the instantiated ontology” [14]. Since our focus is on a core ontology, not a domain ontology, we explore how we choose to view functional and non-functional requirements. We also explore and highlight various mechanical verification checks for the core ontology.

7.2.1. Functional Requirements

Functional requirements are generally defined as covering the what of the system, i.e., its performance and behavioral aspects. We view this with respect to the exploratory questions of the core ontology, and the roles played by the corresponding concepts as summarized in

Table 2. Functional requirements as parts of ontology concepts.

Exploratory Question	Corresponding Concepts
What are the SoS requirements?	This is extended from the concepts system and capability where a system provides a capability disposition towards a certain activity.
How does the SoS operate?	This is extended from the linkage between capability configuration plan, aggregation of constellations, the mission planned process, and mission thread step-by-step plan specification.
What does the SoS realize?	This is extended from how CS capabilities are orchestrated into capability configurations to realize missions.

.

7.2.2. Non-Functional Requirements

Non-functional requirements generally define the how of the system, and consequently, the associated quality aspects. With the minimalist nature of the core ontology, attributes are not defined, meaning different SoS can have their own attributes. However, SoS by their very nature can be thought of as converging towards addressing certain properties inherent in an SoS setting. In Section 7.3, we highlight different application-agnostic qualities towards which various SoS attributes converge.

Therefore, for this core ontology, the non-functional requirements checked are those related to quality, design, and intended use requirements, as mentioned in the requirement phase in Section 3. The quality and design requirements are addressed through the choice of ontology coding language, checking the ontology’s logical consistency, querying support, and the use of ontology patterns. The intended use is demonstrated through alignment with the foundational ontology BFO and other ontology foundries as seen in Figure 3. This verifies its conformance to a foundation and highlights the types of entities for each concept. The design requirements are addressed through the selection of OWL-DL, an open source ontology language, and the use of Protégé ontology editor. The non-functional requirements addressed include:

• Logical consistency: this focuses on the identification of contradictions. It is achieved through a consistent and coherent check using a Web Ontology Language - Description Logic (OWL-DL) reasoner. We chose the HermiT reasoner. The choice of HermiT is based on it being the default reasoner for Protégé, its support of a wide range of optimizations and queries, and description graphs. The performed test focused on the global ontology coherence, consistency, and satisfiability. The HermiT reasoner resulted in a consistent and coherent outcome with no unsatisfied classes or properties.
• Inferencing: Ontology reasoners are especially useful for making inferences, i.e., reasoning to create connections that were not explicitly stated in the ontology. In this ontology, the reasoner did not create any inference. We attribute this to the compactness of the ontology.
• Ontology design patterns (ODPs) check: “ODPs are reusable modeling solutions that encode modeling best practices” [26]. They are agreed-upon ways of framing classes, properties, and individuals. ODP was proposed as a solution to facilitate the semantic web by offsetting the gap between the ontology development process and tools, and the application of domain expertise. ODPs are therefore prescribed best practices for ontology engineering. From the core ontology, we will consider two kinds of ODPs: logical and content ODPs [27], i.e., context-independent formal expressions, and context-dependent conceptual expressions, respectively.

  (a)

  Transformation and partition pattern

  The transformation pattern checks the whole-part relationships, whereas the partition pattern defines mutually exclusive entities. For the transformation, the structural check is whether the transitivity, reflexivity, and symmetry relationship observed to convey the required constraints. This is a logical pattern to convey the right structural make-up of the ontology.

  –

  For the loop connecting the SoS and System concepts, the core ontology defines the constistsOf relationship as irreflexive.

  –

  Value partition pattern defines mutual exclusivity, i.e., whether subclasses are defined as mutually exclusive. The core ontology includes only two subclasses, CSCapability and SoSCapability, which are defined as disjoint. However, these do not necessarily form the union of the superclass; this is a conscious choice to balance the need for the core ontology to evolve to include other forms of capabilities as knowledge evolves.

  (b)

  Role pattern

  The role pattern focuses on identifying the contextual nature of classes. It includes content OPDs that address the following questions: Does the ontology include roles? How are they modeled? This is to exemplify temporal behavior, which can be assumed by classes. Whether roles are classes, individuals, or properties has implications on the ontology expressiveness, simplicity, and questions that can be answered [28,29].

  –

  In SoS, this is particularly important as classes such as constellation and mission thread are temporal constructions. In the context of this core ontology, the notion of roles is not explicitly stated, but it is implied. In this ontology, it can be applied in a combination by, e.g., defining capabilities as classes, individuals, or properties. It all depends on how one wants to balance their ontology. When it is defined as a class, it adds openness to the use of attributes and further characterization. When it is defined as properties, it is much simpler, but less expressive.

  –

  Time-indexed role patterns explicitly say which classes are time-dependent. In alignment with the purpose of this ontology, entities in the operational part of the ontology present the most time-dependent nature. This means the relationships between system, constellation, and mission thread concepts. In its current state, there is no specific means to identify these as time-dependent.

7.3. Validation

Ontology validation focuses on the external consistency of the ontology. The SABIOx methodology suggests that: “for ontology validation, one should evaluate whether the ontology meets real-world situations by instantiating its concepts as individuals of the ontology” [13]. Studies on core ontology validation involve testing three main areas: coverage, definitions, and domain-specific testing. Throughout its development process, the ontology underwent activities that iterated throughout these aspects to this minimalist version seen in Figure 2. The definitions employed in the ontology adhere to the existing systems engineering definitions with slight modifications to fit the SoS context and the purpose of the ontology. This validation focuses on two main aspects: the use of heuristic validation metrics and the usability of the core ontology in a domain setting. For these, we instantiate the core ontology in a domain-specific wildfire crisis management SoS.

A typical wildfire crisis management is illustrated in Figure 4, with different agents and their corresponding possible interactions highlighted with dashed arrows. A typical wildfire scenario includes fire detection, reporting, fire containment, and fire control processes. Typically these processes involve different stakeholders with different managerial and operational independence, e.g., fire fighting teams, meteorology team providing inputs for the environmental factors, and civilians who are in the line of fire or who want to support the firefighting efforts. It also includes the need to understand, among other things, how nature and fire properties characterize the fire scenario context. Moreover, these stakeholders may be distributed, with underlying constraints, and at times with conflicting interests. These characteristics make wildfire crisis management a reasonable scenario to study an SoS.

7.3.1. Heuristic Considerations

With the core ontology’s minimalist representation of the SoS knowledge, to define an SoS domain ontology with clarity, embedding specific SoS expectations into the core ontology seems necessary. We outline these expectations as considerations of how one may characterize domain ontologies by thinking beyond the core ontology concepts. This is summarized in

Table 3. Specific considerations corresponding to concept kinds and associated SoS characteristics.

Wildfire Crisis Management SoS	Considerations
Fire detection constellation (object aggregate) → object states: active vs. passive, incentive towards active participation in the SoS	the effectiveness of the constellation
Firefighting system (object) → how a ground firefighting team versus an aerial firefighting team interface with the rest of the systems in the SoS	interfaces, boundaries, active vs. passive CS in SoS
Capability (disposition) → how the capability contributions may create different tradeoffs: example moving people and equipment using a firetruck (slow) versus moving equipment with an All Terrain Vehicle (fast)	belonging, performance of the capability in a specific constellation, e.g., in accuracy
Fire detection mission (planned process) → performance measure that determines milestones towards completeness	milestones, timefactor, performance
Fire detection step-by-step procedure (plan specification) → the coordination plan for the mission context	feasibility, tradeoffs
Capability configuration, a template of possibilities (design specification) → a list of diverse combinations and outcomes towards the SoS emergent behavior	context, interoperability, reusability

. The corresponding attributes and instances can then be defined to reflect the purpose of the particular SoS.

7.3.2. Wildfire Management SoS

A wildfire crisis management SoS domain ontology is developed by importing the core ontology and creating sample classes, instances, and properties to address the specific purposes of the SoS. In this validation, we will focus on domain-specific checks of how the ontology supports different decisions inherent in the SoS. A typical class hierarchy of the ontology is as seen in Figure 5, showing the different classes, instances, and properties. We elaborate on how the ontology responds, directly or indirectly, to usability in terms of six categories of interrogatives: why, who, what, when, how, and where. These are used as basic means of elaborating on how a user can interact with the ontology.

• Why do we need an SoS? From the ontology, we can view an SoS as originating from two main aspects: the availability of systems, and the need for missions that are SoS-worthy. The why then describes the instance of SoS Capability achievable from these systems, and the necessary classes of missions to be accomplished. Figure 6 shows two classes of mission and their corresponding instances.
• Who participates in this SoS? This describes the stakeholders, highlighting their ownership of the different classes of systems involved in the SoS. In this ontology, stakeholder is not explicitly stated as a concept. Stakeholders can be implied from how one describes CS capability. In our example, CS capability is described according to their action, but they could be classified in many different ways, e.g., according to their ownerships, e.g., control_action_municipal_council efficiencies, whichever option demonstrates what is more important for the respective SoS, i.e., stakeholders’ involvement can be embedded in their respective systems.
• What is the SoS working with? This describes the classes of capabilities needed for the SoS, and their respective instances as seen in Figure 7.
• When? This describes the time or sequence-related nature of the SoS, showing the step-by-step mission thread. In the ontology, one is able to specify mission threads, their instances, and their corresponding constellations, as seen in Figure 8. However, the ontology does not yet support sequential or parallel activities.
• How? This describes the operation-related nature of the SoS, linking an SoS with a capability configuration design template, and how it conforms to the constellations’ actual implementation options. Figure 9 shows a sample definition of what makes up a constellation const_large_fire_fast_spread and its conformance to a specific capability configuration cc_large_fire_fast_spread.
• Where? This describes the formation and adaptability of constellations. From the core ontology perspective, this is related to the context of the mission, and forms a baseline defining capability configurations.

In summary, the above highlights show the ease of use of the ontology, which is summarized as:

• Constellation is the implementor in the SoS; its adaptability must be taken in consideration in the capability configuration design plan.
• The feasibility of these configurations is observed in the context of the mission.
• Constellations originate from systems; therefore, the reliability of systems as they participate in the SoS must be measured.
• This reliability can be measured through the performance of the capabilities of these systems in the SoS.
• Missions can be traceable on the basis of the constellations assigned and the overall relational performance of these constellations.

7.3.3. Ontology Metrics

Other structural metrics can validate how acceptable and crafted an ontology is. This includes evaluation of the ontology hierarchy, properties, complexity, restrictions, centrality, and others, as summarized by Franco et al. [30]. Our core ontology is a minimal one, with a hierarchy depth of 3, i.e., the longest path from in the hierachy. This is on the lower end of the recommended hierarchy depth, meaning the ontology is easy to navigate through.

To further check different metrics of the ontology, we employed the OntoMetrics tool to see the core ontology metrics. OntoMetrics is an open source web-based tool that can verify and determine some ontology metrics [31]. Here we describe two metrics: relationship richness and axiom class ratio.

• Relationship richness, 0.48: “the ratio of the number of non-inheritance (NI) relationships to the total number of relationships” [31]. It depicts the diversity of relationships, where the more diverse the relationships, the better the information. Since the aim of the core ontology is to bring out deep knowledge, a higher ratio would have been preferred.
• Axiom class ratio, 11.89: “the average amount of axioms per class”. This ratio speaks of the level of detail that describes the concepts of the ontology, and it also suggests the expressiveness of the ontology.

7.3.4. Ontology Traceability

To highlight how the ontology meets its goals, we perform a forward traceability to see how different CQs are implemented using a wildfire crisis management SoS domain ontology. The use case is traced from exploratory questions to the CQs. The findings are summarized in

Table 4. Traceability of how the ontology competence questions are addressed by querying the wildfire crisis management domain ontology.

CQ	DL Query & Outcome
Which systems does the SoS contain?	System lists all classes and instances of systems available, this is as seen in Figure 10a,b
Which capabilities are provided by these systems?	CSCapability lists all classes and instances of CS capabilities available, this is as seen in Figure 10c
Which constellations are possible in this SoS?	Constellation lists all preset constellations, ConstellationSmallFire displays all possible instances of small fire as seen in Figure 10d
Which mission threads are addressed by which constellations? Which missions are part of this SoS?	Mission and MissionThread lists all preset mission and mission thread instances respectively, as seen in Figure 10d
Which capability configuration options are possible in an SoS?	CapabilityConfiguration lists possible configurations classes and instances as seen in Figure 10e

.

Use case: A wildfire on a windy day. Initial efforts are aimed at fire containment, followed by fire control. We create two instances of constellations for small fire, and allocate respective capabilities in each constellation, and we create two instances of capability configuration for small fire, and allocate respective constellations in each.

Exploratory questions and prospective responses for the use case.

• What does the SoS require? fire containment and fire control capabilities
• How does it operate? creation of fire containment and fire control capability configurations
• What does it realize? fire containment and fire control mission threads

Starting from a basic layout of prospective classes for the wildfire crisis management as seen in Figure 10a, we see different subclasses of the respective ontology concepts. From these classes different instances are created, and prospective constellation and configuration are created.

8. Discussion

This study has implemented a formalization and usability assessment of a core ontology for missions and capabilities in SoS. The formalization entailed converting the semi-formal representation of the ontology into a machine-readable version. The usability assessment explored how the core ontology can be extended to a domain ontology. The study highlights how the different phases of the SABIOx methodology were implemented throughout the development lifecycle of the core ontology. Through these five phases, several choices were made whose implications and results are discussed in this section.

8.1. OWL-DL

The design phase was preceded by the choice of codification language. OWL-DL was selected for the implementation of the formalization. This is a lower-level language that is guided through consistency and coherence checks. Although it is a good engine for facilitating machine readability, converting higher-level conceptual models to lower-level implementation is not always straightforward because of limited support for rules. OWL’s underlying Open World assumption, i.e., any information that is not explicitly stated is not considered false but unknown, adds flexibility when considering that knowledge is always incomplete and can be extended further. However, it also means consistency and coherence checks are not definitive. This has both pros and cons. When we think of ontology as responsive to knowledge changes, it becomes advantageous. However, since we know that a core ontology is very specific and minimalistic to the core of knowledge, we want it to be definitive enough to direct SoS thinking principles.

8.2. Inferencing

The implementation phase involved correcting and analyzing the status quo of the ontology, and modifying it into a version that the tool can encode. This included the addition of two more classes to clearly separate the capability of independent systems CSCapability from that of the SoS SoSCapability. The encoded implementation did not create any inferences. This led to further exploration of whether the ontology is over-axiomatized. We explored playing around with global settings for the domain and ranges of the object properties; however, we resorted to the realization that the ontology is compact and suitable even without inferences.

8.3. Usability

Ontology usability in a real-life SoS is tested by instantiating with classes and instances of wildfire crisis management SoS. The competency questions were elaborated to address different issues about the SoS, and quality attributes were highlighted as means through which one can guide the choice of the types of attributes or data properties to address specific SoS concerns. The bigger question is then how useful the ontology is in supporting SoS thinking principles. The core ontology gives us a view of both tangible and intangible aspects of an SoS. It shows us a way to plan how to go about conceptualizing an SoS, by understanding its abstract and concrete aspects, working through its descriptive plan and design specifications, concretization of abstract concepts, contextualization of roles, and realization of processes.

8.4. SABIOx Methodology

The SABIOx methodology’s capture phase discusses ontology integration. If our construction had reused any ontology, it would have been possible to integrate views from these ontologies in the overall formalization for added clarity. However, this ontology was developed without reusing existing ontologies. We highlight three subdomains, namely requirements, operation, and realization, in Section 3. From these subdomains, it should be possible to build modularity in the core ontology by specializing these concepts towards better domain-specific conceptualizations.

8.5. SoS Thinking Principles

INCOSE complexity primer [32] suggests several ways to develop guiding principles to complexity thinking. The ontology supports this in several ways:

(a)

Adapting to an ecosystem as opposed to starting from scratch: The core ontology re-uses an existing knowledge base in terms of the selection of terminologies, and seeks alignment to established knowledge foundations.

(b)

Seek balance rather than optimization, and focus on an outcome space rather than a specific solution: The core ontology approach to SoS has demonstrably shown us what is possible and probable. I has shown us:

• The capability configuration provides an outcome space of possibilities
• The constellation aggregation varies the SoS boundaries to the chosen outcome probability
• An SoS is partly tangible and intangible, therefore, it involves the coordination and adaptation of design specification with plan specifications
• Regardless of what exists first, either the mission or the systems, one can always tailor the SoS to a satisfactory outcome according to the context and the acceptable tradeoffs

(c)

Adaptive thinking of interventions or influence as opposed to control or design: The core ontology adapts one’s thinking to how different constituents of an SoS can be of use, be it in a top-down or bottom-up approach; it shows that adaptive thinking can develop SoS-like uses whenever capabilities align.

9. Conclusions

The core ontology provides an explanatory model for the SoS hinged on the concepts of mission, and capability. The study adopts the SABIOx methodology to trace the ontology from requirements to implementation. Particular emphasis is put on the formalization of the ontology knowledge base in an ontology language, and the extrapolation of the core ontology into a domain-specific SoS. From the design and implementation phases, we see how it is significant to balance conceptual clarity with domain appropriateness. This study highlights tradeoffs and concerns when encoding ontologies, how the choice of a language, tools, and their underlying assumptions can influence logic, reasoning, and the quality attributes. Moreover, ontologies can be complicated, therefore, not very easy to understand, use, and manage because of limited tool support and the complexity of expressing models in machine-readable formats. Tradeoffs are inevitable, and therefore, tailoring the ontology to its purpose is a best practice; however, ensuring re-use, modularity, and conveying the right information remain very necessary. To make the ontology more usable within the ontology community, making it a part of an ontology foundry plays a significant role; therefore, future work suggests efforts to see how this core ontology may fit in the existing ontology foundries, how it can be extended by refining its concepts such as refining mission thread into steps, adding other concepts, relations or properties, and including other validation trials by testing different SoS domains.