Actionable Semantic Patterns in the Crisis Management Lifecycle: The TERMINUS Ontology

Highlights

What are the main findings?

• The TERMINUS ontology provides a BFO (Basic Formal Ontology)-aligned semantic framework structured around ontology design patterns (ODPs) and ontology query patterns (OQPs), ensuring semantic continuity across the crisis management lifecycle.
• The ontology enables automated risk assessment, cascading risk analysis, emergency scenario generation, and participatory recovery planning, validated through real-world applications in Rome and L’Aquila.

What are the implications of the main findings?

• TERMINUS enhances interoperability and reuse of knowledge graphs in crisis management, supporting more effective prevention, preparedness, response, and recovery in smart cities.
• The ontology fosters collaborative decision-making and resilience building by providing actionable, pattern-based semantic structures that bridge conceptual models with operational applications.

Abstract

Crisis management in smart cities demands coherent, interoperable, and reusable semantic models to represent complex systems, their risks, crisis situations, interdependencies, and decision-making processes across all lifecycle phases, i.e., prevention, preparedness, response, and recovery. This paper presents the TERMINUS (TERritorial Management and INfrastructures ontology for institutional and industrial USage) ontology, a BFO (Basic Formal Ontology)-aligned conceptual model based on semantic patterns for the crisis management lifecycle operationalized as both ontology design patterns (ODPs) to structure the ontology and ontology query patterns (OQPs) to use it in specific contexts. ODPs capture reusable conceptual structures for modeling domains, while OQPs provide SPARQL (SPARQL Protocol and RDF Query Language)-based templates to retrieve and reason over knowledge graph instances derived from these model chunks. The approach ensures semantic continuity from conceptual modeling to operational applications, enabling automated scenario generation, cascading risk analysis, and participatory decision-making. We position the patterns within the crisis management lifecycle and demonstrate their use through real-world case studies, covering semantic spatio-temporal risk assessment, interdependent infrastructure risk cascades, creative emergency scenario design, and recovery planning. Evaluation results highlight the ontology’s ability to support domain experts in generating plausible context-specific models, fostering collaborative validation, and enhancing preparedness and resilience. TERMINUS thus provides a versatile and interoperable semantic infrastructure for integrating ontologies and knowledge graphs into urban crisis management workflows.

1. Introduction

Crisis management in smart cities is a complex cyber-socio-technical challenge [1] requiring the integration of heterogeneous data sources, coordinated actions across multiple stakeholders, both human and cyber, and adaptive decision-making under uncertainty. Urban systems, such as transportation, energy, water, healthcare, and communication infrastructures, are essential services [2,3] which are deeply interdependent [4,5], and disruptions in one sector can propagate rapidly to others, creating cascading effects [6]. Traditional information management approaches often fail to capture these interdependencies in a semantically coherent and machine-interpretable way, limiting their ability to support targeted prevention, proactive preparedness, timely response, and effective recovery [7,8].

To address these challenges, semantic technologies and ontologies offer a powerful foundation for representing, integrating, and reasoning over complex, multi-domain knowledge. An ontology is a formal specification of a shared conceptualization  [9,10]. By formally defining the entities, processes, roles, and relationships involved in crisis situations, ontologies enable consistent interpretation across systems, stakeholders, and applications. However, building large-scale, reusable ontologies from scratch is resource-intensive, and their practical utility depends on well-structured patterns that can be directly made actionable in real-world scenarios.

In this work, we present the TERMINUS (TERritorial Management and INfrastructures ontology for institutional and industrial USage) ontology (TERMINUS url: https://raw.githubusercontent.com/AntonioDeNicola/ontologies/main/TERMINUS_upper_ontology_v1.2.owl, accessed on 14 October 2025.), a comprehensive, BFO (Basic Formal Ontology)-aligned [11,12] conceptual model designed to support the full crisis (or disaster) management lifecycle, including prevention, preparedness, response, and recovery [13,14]. TERMINUS is based on a set of semantic patterns (SPs) [15] that are specialized in two complementary forms: ontology design patterns (ODPs) and ontology query patterns (OQPs). ODPs provide reusable, high-level conceptual models capturing essential aspects of domains [16] such as system perspectives, risk modeling, cascading interdependencies, crisis management processes, and decision-making in recovery planning. OQPs, in turn, operationalize these models as SPARQL (SPARQL Protocol and RDF Query Language)  [17] templates for retrieving and reasoning over knowledge graphs [18,19], ensuring that the same conceptual structures used for modeling also guide data access and analysis.

We position these patterns explicitly within the crisis management lifecycle. In the prevention phase, the risk and cascade SPs formalize hazard scenarios and their potential propagation, enabling early warning and mitigation planning. In preparedness, the system aspect SP enables mapping of infrastructures, resources, and stakeholders, supporting capability assessment. In response, crisis management SPs provide structured vocabularies for describing service disruptions, emergency resources, and coordination activities. In recovery, the decision-making SP models post-crisis planning, integrating needs, constraints, opportunities, and threats into coherent recovery strategies.

To guide this work, we formulated the following overarching research question: How can semantic patterns, through ontology design patterns and ontology query patterns, enhance the ability of smart cities to ensure semantic continuity (i.e., preserving the meaning consistently across different stages, systems, and stakeholders in the lifecycle of information), achieve interoperability, and effectively exploit knowledge graphs in order to improve preparedness, response, and recovery across the crisis management lifecycle? This central question is articulated into four sub-questions: (RQ1) How can ODPs be structured to capture recurring concepts such as system aspects, risks, cascading effects, and decision-making processes in a BFO-aligned framework? (RQ2) How can OQPs derived from ODPs enable effective querying, reasoning, and operational use of knowledge graphs in real-world crisis management scenarios? (RQ3) How well do the TERMINUS patterns support modeling and reasoning over interdependencies and cascading failures in complex socio-technical systems? (RQ4) To what extent is the pragmatic value of TERMINUS demonstrated through real-world use cases covering prevention, preparedness, response, and recovery?

The contributions of this paper are, hence, threefold:

• Extensible and reusable conceptual model for crisis management: We introduce the TERMINUS ontology and its family of ODPs and OQPs, designed for interoperability, modular reuse, and alignment with foundational ontology principles.
• Crisis management lifecycle semantic integration: We map these patterns to the four phases of the crisis management lifecycle, demonstrating their role in maintaining semantic continuity from preparedness to recovery.
• Applied validation: We evaluate the approach through multiple case studies in the cities of Rome and L’Aquila, covering semantic spatio-temporal risk assessment, cascading risk detection, creative scenario generation, and participatory recovery planning.

Unlike prior semantic disaster frameworks that focus on conceptual integration, TERMINUS couples ontology design patterns with reusable ontology query patterns, yielding actionable outputs: ranked risk mini-models, cascade paths, emergency scenarios, and models of structured recovery actions.

The remainder of this paper is organized as follows. Section 2 reviews related work in semantic modeling for crisis management and smart cities. Section 3 presents the structure of the TERMINUS ontology, addressing RQ1 by detailing its ontology design patterns and RQ2 by introducing the ontology query patterns. Section 4 evaluates the ontology through both a theoretical approach and real-world applications, thereby answering RQ3 on cascading interdependencies and RQ4 on the pragmatic value of TERMINUS in concrete use cases. Section 5 discusses the positioning of TERMINUS within the crisis management lifecycle, summarizes how it addresses the research questions, and further elaborates on policy alignment, governance implications, and identified limitations. Finally, Section 6 concludes with a discussion of contributions, and directions for future research.

2. Related Works

Semantic technologies have been progressively adopted in the domains of risk assessment [20,21,22,23], crisis and emergency management [24,25,26,27], critical infrastructure protection [28], and urban resilience [29,30,31,32,33,34], where decision-making depends on integrating heterogeneous datasets [35], coordinating diverse actors [36,37], correctly interpreting and contextualizing events [38], and understanding complex interdependencies [39,40]. Ontologies provide the formal semantics needed to represent hazards, vulnerabilities, system components, and stakeholder roles in a machine-interpretable way. Several works have explored ontology-based approaches in crisis contexts, such as MEMOn [35] for modular environmental monitoring, and ontology-driven emergency modeling languages [27], but they often target specific application niches. Moreover, many do not provide a reusable, pattern-based architecture or a clear alignment to foundational ontologies, which limits interoperability across sectors and phases of the crisis management lifecycle.

Against this backdrop, the present section is organized as follows: It first discusses the role of foundational and upper ontologies as a basis for semantic interoperability, then reviews existing ontologies and knowledge graphs for risk and crisis management and for smart cities. It subsequently presents the positioning of the TERMINUS ontology with respect to these approaches.

2.1. Foundational and Upper Ontologies

Alignment with foundational ontologies such as SUMO [41,42], DOLCE [43], and BFO is recognized as a best practice for ensuring semantic rigor and interoperability across domains. In the crisis management field, this alignment supports consistent integration of risk, infrastructure, and service models with other domain ontologies, enabling cross-domain reasoning. For example, BFO alignment has been applied in health informatics and manufacturing systems to enable multi-domain knowledge sharing. However, most crisis-related ontologies focus on specific lifecycle stages, such as hazard identification or operational response, without establishing a unified upper-level conceptualization that connects prevention, preparedness, response, and recovery. This partial coverage hinders the reuse of models when transitioning between phases or integrating data from multiple stakeholders.

Recent work on simplexity [44] reframes simplicity and complexity as co-evolving in complex adaptive systems, showing how simple organizing rules can yield actionable structure. TERMINUS echoes this stance by using modular, BFO-aligned semantic patterns and reusable ontology query patterns to render urban crisis complexity tractable.

2.2. Risk and Crisis Management Ontologies

Early efforts to provide a formal ontological conceptualization of risk in complex systems can be traced back to Coletti et al. [20], who introduced the Vulnerability Upper Model (VUM). This abstract pattern formalized fundamental concepts such as hazard, vulnerability, and exposure, enabling the systematic assessment of system-of-systems risks in the domain of climate change. The VUM was later refined in participatory settings, for example, in water systems risk modeling [45], laying the foundations for reusable ontology design patterns subsequently adopted in TERMINUS. Afterwords, ontological foundations of risk have been further refined. Sales et al. [46] introduced the Common Ontology of Value and Risk (COVER), highlighting the deep connection between risk and value ascription.

In parallel, ontologies were applied to crisis and emergency management. De Nicola et al. [27,47] pioneered semantics-based approaches for generating emergency management scenarios, demonstrating how ontologies could support interoperability, reasoning, and simulation in crisis contexts. These works marked the transition from ad hoc vocabularies to structured conceptualizations enabling machine reasoning.

The conceptualization of cascading risks emerged from the seminal work of Rinaldi et al. [4], who classified critical infrastructure interdependencies and distinguished cascading, escalating, and common-cause failures. Other contributions to the conceptualization of interdependencies and cascading risks come from Franchina et al. [48], Luiijf et al. [49], Pescaroli and Alexander [50,51]. Building on this foundation, Coletti et al. [39] introduced one of the first semantic models explicitly addressing cascading risks, using ontological axioms and design patterns to represent and chain failures across interdependent socio-technical systems. These contributions paved the way other systematic ontological approaches to cascading disasters, such as that proposed by Li et al. [40]. Yu et al. [52] proposed the Cascading Disaster Risk Ontology (CDROntology), a three-level ontology based on the ABC [53] and eABC [54] ontology models supporting the modeling of risk chains and scenarios through case-based reasoning, with applications to typhoon-triggered urban disasters. Finally, building on this line, Fumagalli et al. [55] and Engelberg et al. [56] provided ontological analyses of risk propagation, further addressing the semantics of how risks spread across processes and systems.

Concerning other studies in the domain of climate change, Adamo et al. [57] applied ontological analysis to unpack the semantics of risk in IPCC definitions, while F. Barcelos et al. [58] extended the discourse by grounding the notion of resilience on solid ontological foundations using UFO and OntoUML [59].

Prior risk and crisis ontologies, from early upper-level abstractions such as VUM and their domain adaptations, to value-aware models like COVER, to emergency-scenario semantics, have advanced formalization but remain scattered across phases and uneven in their treatment of cross-domain cascades. Seminal analyses of interdependencies (e.g., [4]) and subsequent ontology-based proposals helped frame cascading effects, yet often stop short of an actionable bridge to operational knowledge graphs and reusable queries. TERMINUS addresses these gaps by (i) aligning mid-level crisis concepts to BFO for cross-domain consistency; (ii) pairing ODPs with OQPs so the same structures used to model risk, cascading threats, and EM scenarios also drive Knowledge Graph (KG) querying and reasoning in practice. Recent work on essential-service continuity and national interoperability principles underscores the need for such lifecycle-spanning, operational semantics, which TERMINUS explicitly targets.

2.3. Ontologies and Knowledge Graphs for Smart Cities

The increasing digitalization of urban infrastructures has made ontologies and knowledge graphs essential enablers for smart cities. Ontologies provide formal conceptualizations of urban domains, enabling semantic interoperability among heterogeneous datasets and supporting reasoning for advanced applications such as decision-making, situational awareness, and policy evaluation. A systematic review by De Nicola and Villani [60] identified more than sixty ontologies and fifty semantic applications spanning domains such as energy, transportation, healthcare, environment, and governance, showing that semantic technologies have become integral components of urban data platforms. Initiatives such as Km4City [61] and ontology catalogues like READY4SmartCities [62] demonstrate the importance of standardization and reuse in this space.

Parallel to ontology engineering, knowledge graphs have emerged as a powerful paradigm for integrating heterogeneous urban data sources, including IoT sensor feeds, geographic information systems (GISs), administrative records, and citizen reports, into unified semantic frameworks. In smart city contexts, KGs have been deployed for transportation planning, energy optimization, water management, and healthcare service delivery. FIWARE [63] exemplifies the feasibility of large-scale, interoperable knowledge graphs for city management. Likewise, Santos et al. [64] proposed a city KG and indicator ontology to support the automatic generation of dashboards from heterogeneous datasets, enabling dynamic monitoring and visualization of urban indicators. Another notable initiative is the World Avatar project, which includes knowledge graphs for smart cities that are exploited by agents within a multi-agent framework [65]. More recently, KGs have also been explored for supporting sustainability assessment and sustainable development goals (SDG) monitoring, highlighting their ability to bridge local data ecosystems with global policy frameworks .

Despite these advances, the application of ontologies and KGs to crisis and emergency management remains underdeveloped. Existing works rarely capture cross-domain interdependencies, such as how a disruption in the energy grid could cascade into failures in transport, health, or water infrastructures, within a unified semantic framework. Moreover, the linkage between KG construction and crisis management lifecycle-oriented ontology design patterns and ontology query patterns is still limited. This gap restricts the potential for automated scenario generation, cascading risk modeling, and dynamic response planning. Addressing these challenges requires moving beyond sector-specific ontologies towards actionable semantic frameworks, where ontologies are operationalized as reusable ODPs and OQPs and instantiated in KGs that support reasoning across interconnected urban domains.

City-scale ontologies and KGs (e.g., Km4City, READY4SmartCities, FIWARE, indicator-oriented city KGs, and multi-agent platforms like the World Avatar) demonstrate interoperability and large-scale integration, yet most solutions focus on sectoral monitoring/visualization and provide limited support for crisis-lifecycle semantics, for cascading interdependencies, or for reusable, lifecycle-oriented query templates. TERMINUS complements these efforts by offering a unifying, BFO-aligned set of semantic patterns mapped to the crisis management lifecycle and operationalized as OQPs, enabling automated scenario generation, cascade analysis, and decision support on top of KGs. Recent contributions emphasizing standards and continuity of essential services further motivate this actionable linkage between conceptual models and operational queries that TERMINUS provides.

2.4. Positioning of TERMINUS in the State of the Art

These lines of research have converged in the development of TERMINUS, a domain ontology for crisis management and smart cities. A preliminary version of this ontology was introduced in [23]. TERMINUS brings together risk patterns, cascading interdependencies, and system services within a coherent architecture grounded in ontology design patterns (ODPs). In doing so, it ensures semantic continuity and interoperability across the different phases of the crisis management lifecycle. As mentioned in Introduction, this includes prevention, preparedness, response, and recovery. Specifically, prevention refers to activities and measures aimed at avoiding or minimizing existing and potential disaster risks. Preparedness emphasizes the anticipation of hazards and the development of capacities to ensure effective response and recovery once a disaster occurs. Response encompasses the immediate actions taken before, during, and immediately after an event in order to protect lives, assets, and critical systems. Finally, recovery involves both the short-term rehabilitation of essential services and facilities and the longer-term processes of reconstruction, rebuilding, and sustainable restoration of affected communities and infrastructures. These definitions provide the reference against which we reviewed prior ontologies.

The review of related works shows that existing semantic models remain fragmented in several ways. Many cover only isolated stages of crisis management, leaving prevention, preparedness, response, and recovery disconnected rather than supported within a unified framework. Conceptual modeling is rarely integrated with query-driven exploitation, meaning that ontology design is often detached from the ways in which knowledge is actually accessed and used. Furthermore, cascading and cross-domain interdependencies, such as the propagation of failures from the energy grid to transportation, healthcare, or water infrastructures, are still poorly captured, particularly when environmental and social dimensions are considered alongside technical infrastructures. Finally, even when ontologies are available, they are seldom operationalized into knowledge graphs that can directly support reasoning, automation, or real-time decision-making.

As summarized in

Table 1. Comparative coverage across related ontologies. Scores: F = Full, P = Partial, N = None.

	TERMINUS	COVER	CDROntology	Km4City	FIWARE
Crisis management lifecycle coverage
System	F	P	P	P	P
Risk	F	F	F	N	N
Cascading risks	F	F	F	N	N
Emergency management	F	N	P	N	N
Decision-making	F	N	P	N	N
Smart city coverage	F	N	N	F	F
Alignment with foundational ontologies and schemas	BFO, WGS84 Geo  [66], W3C Time  [69]	UFO	ABC/eABC	schema.org, SSN  [67], FOAF  [70]	schema.org, SAREF  [68], WGS84 Geo, SSN

, related strands converge yet remain complementary. COVER (UFO-aligned) delivers full coverage of risk and cascading risks but does not address emergency management, decision support, or smart-city integration. CDROntology (ABC/eABC style) likewise covers risk and cascading risks and offers partial support for emergency management and decision-making, without smart-city data integration. Conversely, Km4City and FIWARE provide full smart-city coverage through rich urban data models and partial system representation, but they do not model the crisis-management lifecycle. Foundationally, these efforts either adopt non-BFO upper layers (COVER, CDROntology) or rely on domain vocabularies, schemas (e.g., schema.org), and W3C semantics (Km4City, FIWARE).

The TERMINUS ontology provides a BFO-aligned conceptual model that systematically aligns ODPs with OQPs, ensuring coherence between modeling and data exploitation. By mapping these patterns across the full crisis management lifecycle, TERMINUS enables semantic continuity and reuse, while its validation through real-world applications in Rome demonstrates its ability to support spatio-temporal risk assessment, cascading risk analysis, emergency scenario generation, and participatory recovery planning.

In contrast with existing approaches, which often stop at semantic integration and visualization, TERMINUS bridges high-level ontology engineering with the operationalization of knowledge graphs. This makes it possible not only to represent but also to reason about cascading effects, enabling automated scenario generation and more adaptive decision support. As such, TERMINUS contributes a unifying semantic infrastructure that advances the state of the art and strengthens urban resilience through actionable semantics.

3. TERMINUS Ontology

The TERMINUS ontology is a BFO-aligned semantic framework designed to model, integrate, and operationalize knowledge across all phases of the crisis management lifecycle in smart cities. It is structured around a family of semantic patterns, expressed as ontology design patterns and ontology query patterns, which together enable consistent conceptualization and retrieval of knowledge graph content. These patterns capture recurring structures for representing system aspects, risks, cascading interdependencies, emergency management processes, and decision-making in recovery contexts. The ontology was engineered in close collaboration with domain stakeholders in several research projects to ensure practical applicability in real-world use cases, from semantic spatio-temporal risk assessment to participatory recovery planning (see Section 4). The following subsections describe the engineering process, the alignment with foundational ontologies, and the detailed structure of each TERMINUS pattern.

3.1. Ontology Engineering

The engineering of the TERMINUS ontology follows established methodologies for ontology construction [71,72,73,74], adapted to the specific needs of crisis management in smart cities. In line with the software engineering perspective on ontology building, the development process was conceived as an iterative and incremental activity, involving close collaboration between ontology engineers and domain experts. The goal was to ensure that the resulting semantic patterns would be both formally rigorous and directly applicable in real-world scenarios. A lightweight, rapid ontology engineering approach [74] was adopted to enable frequent validation cycles with stakeholders, reducing the gap between conceptual modeling and operational use. This approach allowed for early deployment of partial models in pilot applications, enabling feedback on terminology, conceptual coverage, and usability before committing to large-scale ontology integration.

The semantic patterns, comprising both ODPs and OQPs, were defined and refined in real operational contexts. Stakeholder engagement was central to this process: workshops, interviews, and co-design sessions were organized with representatives from civil protection agencies, municipal departments, infrastructure operators, and emergency planners. These interactions ensured that the patterns addressed concrete information needs, aligned with existing operational workflows, and supported the decision-making processes [75,76,77] required for effective prevention, preparedness, response, and recovery.

This engineering strategy allowed TERMINUS to evolve as a BFO-aligned, modular, and interoperable ontology framework, grounded in actual practice rather than purely theoretical design. As a result, the ontology not only offers conceptual clarity but also provides immediately deployable knowledge graph structures and query templates tailored to real case studies, such as semantic spatio-temporal risk assessment, cascading risk modeling, and participatory recovery planning.

3.2. Foundational Ontologies

The TERMINUS ontology is grounded in well-established foundational and upper ontologies to ensure semantic rigor, interoperability, and reusability across domains. Foundational ontologies provide high-level, domain-independent categories and relations that serve as a common semantic backbone for integrating heterogeneous domain models.

For formal ontological grounding, TERMINUS adopts BFO as its primary upper-level reference. BFO’s clear separation between continuants (entities that persist through time) and occurrents (entities that unfold over time) enables a consistent alignment of domain concepts such as infrastructures, stakeholders, hazards, and events with a universally recognized top-level framework. This alignment ensures that the ontology’s core patterns, such as the system aspect, risk, and decision-making SPs, are not only internally coherent but also interoperable with other BFO-compliant ontologies in related domains.

TERMINUS can also be considered a foundational ontology in its own right, positioned directly on top of BFO. It extends BFO’s abstract categories with domain-neutral but crisis-management-oriented constructs, such as system aspects, risk propagation structures, and decision-making primitives. These mid-level abstractions bridge the gap between high-level philosophical categories and the domain-specific ontologies or knowledge graphs used in operational applications.

In addition to these upper-level frameworks, TERMINUS integrates the official W3C Time ontology [69] for representing temporal concepts such as instants, intervals, and durations, which are essential for modeling the temporal dynamics of hazards, cascading events, and recovery actions. Spatial concepts are modeled using the W3C/OGC Basic Geo (WGS84 lat/long) vocabulary [66] and related spatial ontologies, enabling the precise geolocation of system components, affected areas, and hazard extents. Together, these temporal and spatial vocabularies provide the necessary semantic tools for spatio-temporal reasoning, which is a core requirement in crisis management applications.

By combining these foundational resources, BFO, and W3C’s Time and Space ontologies, TERMINUS establishes a robust semantic infrastructure that supports modular extension, formal reasoning, and seamless integration of knowledge graphs across the full crisis management lifecycle, while itself acting as a domain-oriented foundational layer above BFO.

3.3. TERMINUS Ontology Backbone: The Semantic Patterns

In this section, we describe the set of semantic patterns specifically designed to support the semantic modeling of systems, risks, emergency situations, and decision-making processes in urban and infrastructural contexts. These patterns are categorized into two complementary families: ontology design patterns and ontology query patterns. While both contribute to ensuring semantic consistency and interoperability, they address different aspects of knowledge structuring and exploitation. When used to extend either an ontology or a knowledge graph, a semantic pattern takes the role of an ODP, as it provides a reusable modeling solution that enriches the structure and semantics of the target ontology or knowledge graph. Conversely, when the same semantic pattern is operationalized into reusable query templates aimed at retrieving ontology fragments or knowledge graph instances, it takes the role of an OQP. An OQP remains consistent with the semantics of its underlying semantic pattern. Its topological structure may differ from that of the originating semantic pattern when required by specific application needs, but the intended semantics of the latter must not be violated. Importantly, the same semantic pattern can also assume both roles, ODP and OQP.

For example, the cascading risk semantic pattern structures the representation of interdependencies between infrastructures, allowing the modeling of how a disruption in the energy grid can propagate into failures in transport or healthcare. The same semantic structure can then be expressed as an OQP that retrieves cascading risk scenarios from a knowledge graph, enabling analysts to query not only direct failures but also second- and third-order effects across domains. This dual use illustrates how TERMINUS bridges conceptual modeling and practical knowledge exploitation.

Ontology query patterns, hence, are reusable formal structures for retrieving semantically coherent information from ontology-based knowledge graphs. They are typically expressed as SPARQL query templates grounded in the conceptual structure provided by the corresponding ODPs. OQPs encode recurring information needs, such as identifying all system aspects affected by a specific hazard, or retrieving all decision constraints associated with a recovery plan, thus enabling automated reasoning, scenario generation, and knowledge exploration. In TERMINUS, query patterns are systematically derived from the structural ODPs, ensuring that the way information is queried remains consistent with the way it is modeled.

By combining ontology design patterns and ontology query patterns, the TERMINUS framework supports both the construction of rich semantic models and their operational use in risk assessment, emergency management, and recovery planning. This dual-layered approach allows for the seamless transition from conceptual modeling to data-driven applications, while preserving semantic rigor and interoperability across domains.

Figure 1 illustrates the overall workflow of the TERMINUS ontology and its semantic patterns. On the left, TERMINUS is represented as a conceptual foundation, which is enriched and structured through ODPs. These patterns provide reusable modeling solutions that enable the extension of TERMINUS into more specialized ontologies or knowledge graphs. Once extended, the ontology can be operationalized through OQPs, which act as reusable templates for extracting coherent fragments of knowledge from the ontology and supporting reasoning tasks. The bottom part of the figure highlights four exemplary application domains enabled by OQPs: (i) risk assessment, where patterns support the identification and evaluation of hazards and vulnerabilities; (ii) crisis scenario design, where cascading effects and critical infrastructure interdependencies can be modeled and simulated; (iii) decision-making, where structured knowledge guides coordination and adaptive responses; (iv) business innovation, where semantic structures enable the generation and evolution of new value propositions and service models. Together, ODPs and OQPs ensure semantic consistency while enabling both the conceptual design and operational exploitation of the ontology.

In the following the mentioned semantic patterns are presented in detail. As a roadmap, the patterns below are ordered to mirror their typical use in the crisis management lifecycle: system modeling, followed by risk assessment, cascading effects, emergency scenario design, and, finally, recovery decision-making.

3.3.1. The System Aspect Semantic Pattern

The system aspect semantic pattern refers to the perspective from which a system is considered by a stakeholder [23]. It provides a conceptual structure to describe systems not as monolithic entities but through multiple complementary lenses, such as their operations, services, physical infrastructure, managed resources, or the actors interacting with them. This perspective-based modeling is essential for enabling flexible and granular risk or system assessment, especially in complex socio-technical contexts.

Table 2. Descriptions of the core concepts in the system aspect semantic pattern. Each concept represents a specific perspective from which a system can be analyzed, including its resources, operations, actors, and services. These elements support flexible and context-aware modeling of socio-technical systems for use in risk assessment, planning, and decision-making.

Concept	Description
Asset	An asset is an item of value owned by the system [39].
Commons	Cultural and natural resources accessible to all members of a society, including natural materials such as air, water, and a habitable earth. Examples of commons are lakes, water springs, rivers, and glaciers [39].
Infrastructure	Infrastructure refers to the fundamental physical and organizational structures and facilities needed for the functioning of a society, economy, or organization. It comprises the underlying systems, facilities, and networks that support various activities and services necessary for social and economic development.
Managed object	Any entity that is handled by a system, such as water in case of water system or fuel in case of oil system [39].
Operator	One that operates, such as one that operates a machine or device or one that operates a business.
Regulator	A regulator is an authoritative entity or agency responsible for overseeing and enforcing rules, regulations, and standards within a specific industry, sector, or domain to ensure compliance, fairness, safety, and proper functioning.
Service request	A service request is a formal or informal communication made by an individual or an organization to request assistance or support from a service provider. It is a way for customers or clients to communicate their needs or issues to the service provider and seek resolution or action.
Shareholder	It is also known as a stockholder, is an individual, entity, or organization that owns shares or equity in a corporation. Shareholders are considered partial owners of the company and have a financial interest in its performance and success.
Spatial region	The term spatial region refers to a specific area or portion of space that is defined or delineated based on certain criteria or characteristics. It is a concept used in various fields, including geography, mathematics, and the sciences, to describe and analyze areas with distinct spatial attributes.
Stakeholder	A person or organization that is interested in a system or its subsystems [23].
System	A regularly interacting or interdependent group of items forming a unified whole, such as a group of devices or artificial objects or an organization forming a network especially for distributing something or serving a common purpose.
System aspect	A perspective that can be used to view a system. System aspects are system service, system operation, asset, commons, infrastructure, managed object, and ecosystem service [39].
System external service	Service provided by a system [23].
System internal operation	Internal activities performed in system and that are required preconditions to deliver services [39].
User	It represents the entity using or consuming a resource entity (e.g., hospital). It is characterized by a wellness level [27].

provides a summary of the core concepts associated with the system aspect semantic pattern. Each concept is briefly described to clarify how it contributes to representing different facets of a system. For instance, Asset, Commons, and Infrastructure capture different types of tangible or intangible system components; Operator, Regulator, and User represent key stakeholder roles involved in managing or interacting with the system; while System internal operation and System external service reflect the internal and output functionalities of a system. Together, these elements form a comprehensive vocabulary for analyzing and modeling systems from multiple viewpoints, as required by domain experts, planners, and decision support tools.

The alignment between the system aspect semantic pattern and BFO provides a foundational semantic structure for interpreting system-related concepts. This alignment ensures that the domain-level constructs used in socio-technical modeling are ontologically grounded in universally accepted upper-level categories.

Table 3. Alignment of concepts in the system aspect semantic pattern with BFO foundational ontology categories. Each concept is mapped to a semantic path that links it to core BFO types (in bold) such as continuants, occurrent, material entities, roles, or qualities. This alignment ensures ontological consistency and enables structured reasoning in complex system-oriented domains.

Ontology Concept	Ontology Path
Asset	entity>continuant>specifically dependent continuant>quality>asset and entity>System_aspect>Asset
Commons	entity>continuant>specifically dependent continuant>quality>commons and entity>System_aspect>Commons
Infrastructure	entity>continuant>independent continuant>material entity>infrastructure and entity>System_aspect>Infrastructure
Managed object	entity>System_aspect>managed_object and entity>continuant>independent continuant>material entity>managed_object
Operator	entity>System_aspect>operator and entity>continuant>specifically dependent continuant>realizable_entity>role>actor>operator
Regulator	entity>continuant>specifically dependent continuant>realizable_entity>role>actor>stakeholder>regulator
Service request	entity>System_aspect>Service_request and entity>occurrent>process>service_request
Shareholder	entity>continuant>specifically dependent continuant>realizable_entity>role>actor>stakeholder>shareholder
Spatial region	entity>System_aspect>spatial_region and entity>continuant>independent continuant>immaterial_entity
Stakeholder	entity>continuant>specifically dependent continuant>realizable_entity>role>actor>stakeholder
System	entity>continuant>independent continuant>material_entity>object_aggregate>System
System aspect	entity>System_aspect
System external service	entity>occurrent>process>system_external_service and entity>System_aspect>system_external_service
System internal operation	entity>occurrent>process>System_internal_operation and entity>System_aspect>system_internal_operation
User	entity>continuant>specifically dependent continuant>realizable_entity>role>actor>stakeholder>user

presents the mapping of each core concept from the system aspect to its corresponding BFO path. These mappings clarify whether a concept should be understood as a continuant (e.g., asset, user), an independent material entity (e.g., infrastructure), a realizable role (e.g., regulator, operator), or an occurrent (e.g., service request, internal operation). This layered interpretation facilitates interoperability, consistency, and reuse of system models in complex domains such as emergency management, smart city planning, and risk assessment.

Figure 2 shows the UML representation of the system aspect ODP. Examples of systems are socio-technical systems as the water system, the energy system, and the transportation system. Larger systems often encompass and integrate smaller ones, creating interconnected systems that mutually influence each other. The hasSystemAspect relationship is employed to indicate that a system can be viewed from the various perspectives, known as system aspects: system (external) services, system (internal) operations, operators, service requests, assets, commons, infrastructure, and managed objects. The isInterestedIn relationship is used to show that stakeholders are interested in specific system aspects. System service refers to the output of a system provided to stakeholders, such as the distribution of energy to users (as demonstrated by the hasUser relationship). System operations, like maintenance, are the internal activities performed within the system, which are essential prerequisites for delivering services. Operators are the individuals carrying out these system operations (as indicated by the performs relationship). They can be either blunt-end operators, such as managers, or sharp-end operators, such as lathe turners. Service requests, such as energy demands, represent users’ requirements for the service. Assets denote valuable items owned by the system. Commons refer to cultural and natural resources accessible to all members of society, including natural elements like air, water, and habitable land. Examples of the commons include lakes, water springs, rivers, and glaciers. Infrastructures model the physical, technological, and organizational structures within a system. Managed objects represent the entities handled by the system, such as water in the case of a water system or fuel in the case of an oil system.

The following OWL excerpt models a simple knowledge graph based on the system aspect when taking the role of ODP, using artificial data to describe an infrastructure system. In this example, Hospital_A is instantiated as an Infrastructure, which is a specific type of System. It is associated with a corresponding system aspect, Hospital_A_Infrastructure, reflecting the structural viewpoint on the hospital. The hospital is operated by an entity called Operator_A, which is categorized under the Operator class, a role-based perspective on stakeholders. Additionally, the hospital is situated within a spatial region, Rome_City, modeled as an instance of the Spatial_region class. Relationships such as describesAspectOf, operates, and locatedIn are used to semantically connect these entities. This example illustrates how the pattern supports the semantic representation of system components, roles, and contexts in a structured and reusable format.

        <rdf:RDF xmlns=‘‘http://www.terminus.org/ontology#’’
             xml:base=‘‘http://www.terminus.org/ontology’’
             xmlns:rdf=‘‘http://www.w3.org/1999/02/22-rdf-syntax-ns#’’
             xmlns:owl=‘‘http://www.w3.org/2002/07/owl#’’
             xmlns:rdfs=‘‘http://www.w3.org/2000/01/rdf-schema#’’
             xmlns:xsd=‘‘http://www.w3.org/2001/XMLSchema#’’>
			    
			    
          <!-- Individual: Hospital_A as a System -->
          <owl:NamedIndividual rdf:about=‘‘#Hospital_A’’>
            <rdf:type rdf:resource=‘‘#System’’/>
            <rdfs:label>Hospital A</rdfs:label>
          </owl:NamedIndividual>
			    
			    
          <!-- Individual: Hospital_A_Infrastructure as an Infrastructure-->
          <owl:NamedIndividual rdf:about=‘‘#Hospital_A_Infrastructure’’>
            <rdf:type rdf:resource=‘‘#Infrastructure’’/>
            <rdfs:label>Hospital A Infrastructure</rdfs:label>
          </owl:NamedIndividual>
		        
	            
          <!-- Link the infrastructure system aspect to the infrastructure system -->
          <owl:ObjectPropertyAssertion>
            <owl:ObjectProperty rdf:about=‘‘#hasSystemAspect’’/>
            <owl:NamedIndividual rdf:about=‘‘#Hospital_A_Infrastructure’’/>
            <owl:NamedIndividual rdf:about=‘‘#Hospital_A’’/>
          </owl:ObjectPropertyAssertion>
		       
	           
          <!-- Individual: Operator_A as an Operator -->
          <owl:NamedIndividual rdf:about=‘‘#Operator_A’’>
            <rdf:type rdf:resource=‘‘#Operator’’/>
            <rdfs:label>Operator A</rdfs:label>
          </owl:NamedIndividual>
		       
	           
          <!-- Individual: Rome_City as a Spatial Region -->
          <owl:NamedIndividual rdf:about=‘‘#Rome_City’’>
            <rdf:type rdf:resource=‘‘#Spatial_region’’/>
            <rdfs:label>Rome City</rdfs:label>
          </owl:NamedIndividual>
		       
	           
          <!-- Link Hospital_A to its spatial region -->
          <owl:ObjectPropertyAssertion>
            <owl:ObjectProperty rdf:about=‘‘#locatedIn’’/>
            <owl:NamedIndividual rdf:about=‘‘#Hospital_A’’/>
            <owl:NamedIndividual rdf:about=‘‘#Rome_City’’/>
          </owl:ObjectPropertyAssertion>
		      
	          
		      
        </rdf:RDF>
		  

Building on the system aspect semantic pattern, the next subsection introduces the risk semantic pattern, which specializes how hazards, vulnerabilities, and stakeholders interact with specific system aspects to produce critical events.

3.3.2. The Risk Semantic Pattern

The risk semantic pattern refers to a critical event of system from the perspective of a particular stakeholder [23]. The purpose of this pattern is to model the risk of a system due to hazards. The key ontological concepts and their definitions involved in this pattern are summarized in

Table 4. A summary of the core ontological concepts used in the risk semantic pattern, including definitions adapted from the literature. These concepts provide the semantic foundation for modeling how hazards affect systems through critical events, mediated by system vulnerabilities and understood from the perspective of stakeholders.

Concept	Description
Critical event of system	An event representing one or more effects on systems from exposure to a hazard; effects are mediated by the strength of the hazard and the vulnerability of the exposed system [23].
Hazard	An event or trend or their impacts (e.g., floods, droughts and sea level rise) with likely detrimental consequences to human systems [23].
Stakeholder	A person or organization that is interested in a system or its subsystems [23].
System aspect	A perspective that can be used to view a system. The system aspects are system service, system operation, asset, commons, infrastructure, managed object, and ecosystem service [39].
Vulnerability	The propensity of a system function to be adversely affected.

. These concepts form the foundational elements of a risk modeling framework, capturing how hazards may impact systems, the roles of stakeholders, and the mediating influence of vulnerabilities and system aspects.

Furthermore,

Table 5. Ontology paths for the core concepts of the risk semantic pattern, aligned with the BFO foundational concepts (in bold). Each concept is positioned within the BFO hierarchy to support semantic interoperability, formal reasoning, and integration across risk modeling applications.

Ontology Concept	Ontology Path
Critical event of system	entity>occurrent>process>Event>System event>Actual event/Potential event>Critical event of system
Hazard	entity>occurrent>process>Event>System event>Potential event>Critical event of system>hazard
Stakeholder	entity>continuant>specifically dependent continuant>realizable entity>role>actor>stakeholder
System aspect	entity>System aspect
Vulnerability	entity>continuant>specifically dependent continuant>quality>System property>Internal system conditions>vulnerability

illustrates how each concept aligns with BFO foundational concepts. Critical event of system and Hazard are modeled as the BFO concept Occurrent (i.e., process unfolding over time), while System aspect is directly connected to the notion of the BFO concept Entity as structured viewpoints on systems. Stakeholder is captured as the BFO concept Specifically dependent continuant, particularly as role realized by social actors. Lastly, Vulnerability is linked to the BFO concept Quality since it depends on internal system conditions, positioning it within the category of Specifically dependent continuant as well. This semantic alignment with BFO ensures ontological rigor and interoperability across domains and applications.

Figure 3 shows the UML representation of the risk semantic pattern. The hasImpactOn relationship specifies the aspect of the system affected by an event, which could be a physical infrastructure or a system function (e.g., in the case of a cyber-attack or an earthquake). Stakeholders, such as civil protection agencies, are concerned with critical events within the system (as illustrated by the takesCareOfEvent relationship in the diagram). Typically, the system aspect may have vulnerabilities, such as inadequate maintenance, which could lead to a higher impact (as indicated by the hasVulnerability relationship).

The following OWL excerpt exemplifies the implementation of the risk when takes the role of ontology design pattern by formally defining specific subclasses aligned with key domain concepts. For instance, Flood is modeled as a subclass of Hazard, while HospitalDisruption specializes the concept of Critical event of system. Other classes such as EmergencyMedicalService, CivilProtectionAgency, and InfrastructureOverload extend System_Aspect, Stakeholder, and Vulnerability, respectively. These subclass declarations instantiate the abstract pattern with concrete examples, illustrating how particular hazards, system aspects, stakeholders, and vulnerabilities can be semantically integrated within a coherent risk representation framework. For the sake of conciseness, we show only how the object property hasImpact has been implemented.

          <rdf:RDF xmlns=‘‘http://www.terminus.org/ontology#’’
               xml:base=‘‘http://www.terminus.org/ontology’’
               xmlns:rdf=‘‘http://www.w3.org/1999/02/22-rdf-syntax-ns#’’
               xmlns:owl=‘‘http://www.w3.org/2002/07/owl#’’
               xmlns:rdfs=‘‘http://www.w3.org/2000/01/rdf-schema#’’
               xmlns:xsd=‘‘http://www.w3.org/2001/XMLSchema#’’>
		   
           
           <!-- Subclass of Hazard -->
           <owl:Class rdf:about=‘‘#Flood’’>
             <rdfs:subClassOf rdf:resource=‘‘#Hazard’’/>
           </owl:Class>
		   
           
           <!-- Subclass of Critical_Event_of_System -->
           <owl:Class rdf:about=‘‘#HospitalDisruption’’>
             <rdfs:subClassOf rdf:resource=‘‘#Critical_Event_of_System’’/>
           </owl:Class>
		   
           
           <!-- Subclass of System_Aspect -->
           <owl:Class rdf:about=‘‘#EmergencyMedicalService’’>
             <rdfs:subClassOf rdf:resource=‘‘#System_Aspect’’/>
           </owl:Class>
		   
           
           <!-- Subclass of Stakeholder -->
           <owl:Class rdf:about=‘‘#CivilProtectionAgency’’>
             <rdfs:subClassOf rdf:resource=‘‘#Stakeholder’’/>
           </owl:Class>
		   
           
           <!-- Subclass of Vulnerability -->
           <owl:Class rdf:about=‘‘#InfrastructureOverload’’>
             <rdfs:subClassOf rdf:resource=‘‘#Vulnerability’’/>
           </owl:Class>
		   
           
           <owl:ObjectProperty rdf:about=‘‘#hasImpact’’/>
           …
		   
           
           <!-- Flood hasImpact some HospitalDisruption -->
           <owl:Class rdf:about=‘‘#Flood’’>
             <rdfs:subClassOf>
               <owl:Restriction>
                 <owl:onProperty rdf:resource=‘‘#hasImpact’’/>
                 <owl:someValuesFrom rdf:resource=‘‘#HospitalDisruption’’/>
               </owl:Restriction>
             </rdfs:subClassOf>
           </owl:Class>
		   
           
          …
		   
           
          </rdf:RDF>
		  

The following SPARQL query excerpts is a template finalized for retrieving risks from a service perspective, such as touristic services in a city. The query is based on the risk ODP to find its specializations related to specific critical events (excluding generic ones) following plausible hazards for the location at hand, and impacts in relation to functional vulnerabilities and tourist stakeholders.

          PREFIX : <http://www.terminus.org/ontology#>
          PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
		   
           
          SELECT DISTINCT ?hazard ?critevent ?sysaspect ?vulnerability ?stakeholder
          WHERE {
		   
           
          # selection of classes for service aspect
          ?sysaspect1 rdfs:subClassOf :System_external_service .
          ?vulnerability1 rdfs:subClassOf :Functional_vulnerability .
          ?stakeholder1 rdfs:subClassOf :Tourist~.
		   
           
          # pattern specializations - logical flow from event to a service
          ?evsys a owl:ObjectProperty;
             rdfs:domain ?critevent1 ;
             rdfs:range ?sysaspect1 ;
             rdfs:subPropertyOf :hasImpactOn .
            FILTER ( ! (?critevent1 = :Critical_Event_of_System) )
          .....................
          # selection of leaf concepts
          ?sysaspect rdfs:subClassOf :System_external_service  .
            FILTER NOT EXISTS {?sub_sy1 rdfs:subClassOf ?sysaspect  .
          ?sub_sy2 rdfs:subClassOf ?sysaspect .
            FILTER (! (?sub_sy1 = ?sub_sy2))  }
            FILTER EXISTS { ?sysaspect rdfs:subClassOf ?sysaspect1  .}
          …
          # contextual rules, for~example remove hazards
          FILTER (
          !(?hazard IN (:TropicalStorm, :TropicalDepression))  )
          ........................
          }
		  

Moving from single-system risk to networked settings, we then present the cascading risk semantic pattern, which models how interdependencies propagate critical events across systems.

3.3.3. The Cascading Risk Semantic Pattern

Cascading system risks arise from interdependencies among different systems. The TERMINUS ontology enables the explicit modeling of these interdependencies and offers dedicated ontology query patterns to support the automatic generation of new risk mini-models referring to different but interconnected systems. These OQPs rely on the concepts of the risk semantic pattern in Table 4, and on the hierarchy of System event, which distinguishes between a threat posed by a Hazard, that may trigger risks (Hazard threat) and the critical event that may result as consequences on the system (Critical event of system). These concepts, also defined in

Table 6. Summary of further ontological concepts used in the cascading risk semantic pattern involving different systems.

Concept	Description
System_event	An event of interest for a system.
Hazard_threat	Specialization of Threat, defined as something potentially dangerous for a system.

, provide the semantic foundation for cascading system events due to system interdependencies.

Table 7. Ontology paths for further concepts of the cascading risk semantic pattern, aligned with the BFO foundational concepts (in bold).

Ontology Concept	Ontology Path
System_event	entity>occurrent>process>Event>System_event
Hazard_threat	entity>occurrent>process>Event>System_event>Potential_event>Threat> Hazard_threat

shows how these concepts align with BFO. In particular, a System event is an Occurrent and abstraction of a Hazard threat and of a Critical event of system.

Figure 4 illustrates the semantic pattern that, together with the risk ontology pattern in Figure 3, provides the concept and the relationships to represent cascading risks. The structural pattern provides the semantic foundation for modeling cascading events in SPARQL queries, as shown in the right figure. The cascading OQP represents how a Hazard can pose a Hazard threat affecting a System aspect of a given system, leading to a Critical event of system for it. Due to the interdependency with the System aspect of another system, this critical event translates into a Hazard threat for the interconnected system.

The following SPARQL query excerpt is a template finalized for retrieving the events of two interdependent systems.

          PREFIX :     <http://www.terminus.org/ontology#>
          PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
		   
           
          SELECT DISTINCT ?interdepEvent ?sysAspect1 ?sysAspect2 …
          WHERE {
		   
           
            # pattern specializations: two interdependent system aspects
            ?sysAspect1 rdfs:subClassOf :SystemAspect .
            ?sysAspect2 rdfs:subClassOf :SystemAspect~.
		   
           
            ?assys a owl:ObjectProperty;
             rdfs:domain ?sysAspect1 ;
             rdfs:range ?sysAspect2 ;
             rdfs:subPropertyOf :isInterdependentWith .
             FILTER ( ! (?sysAspect1 = :SystemAspect) )
           ....
            # selction of events for the two systems
            # subclasses of critical event (for system 1)
            ?critEvent rdfs:subClassOf :Critical_Event_of_System~.
		   
           
            # subclasses of hazard threat (for system 2)
            ?hazThreat rdfs:subClassOf :HazardThreat_of_System~.
		   
           
            # a subclass that belongs to BOTH categories
            ?interdepEvent rdfs:subClassOf ?critEvent .
            ?interdepEvent rdfs:subClassOf ?hazThreat .
          ...
          }
		  

Having characterized how risks arise and propagate, we next shift to crisis management semantic patterns that structure emergency scenarios and their operationalization via query templates (e.g., emergency core and service communication).

3.3.4. The Crisis Management Semantic Patterns

The CEML (Crisis and Emergency Modeling Language) was proposed by De Nicola et al. [27] as a metamodeling language for designing crisis and emergency management scenarios. The CEML ontology was developed in [27] to provide formal semantics for the scenario models and to represent domain knowledge in support of creative design. More specifically, the crisis management semantic patterns derived from the CEML ontology, now part of the TERMINUS ontology, expand on smart city services and on the emergency situations affecting these services as a result of natural or anthropic events. The core entities are described in

Table 8. Summary of the core ontological concepts used in the crisis management semantic patterns, including definitions adapted from the literature. These concepts provide the semantic foundation for modeling how events can disrupt services, causing harm to users, and for identifying which emergency services can intervene in managing the situation.

Concept	Description
Critical event of system	This concept, described in Table 4, encompasses the External Event concept defined in the CEML ontology [27].
System external service	This concept, described in Table 2, encompasses the Service concept defined in the CEML ontology [27].
Resource	This represents the passive entity processed (i.e., produced, provided, transported) by either a service entity or a human service entity. It can be either material (e.g., water) or immaterial (e.g., fire brigades activity). It can be input to either another service entity or a communication service entity or a human service entity or a user entity. It can contribute significantly to a user’s wellness level [27].
Information	A type of Resource representing contextualized data that can be exchanged in a communication between services or a service with a user [27].
Human Service	An active entity providing a given resource in the form of human activities (e.g., fire brigades) [27].
Human Resource	It represents the passive human entity processed (i.e., produced, provided, transported) by either a service entity or a human service entity [27].
User	It represents the entity using or consuming a resource entity (e.g., hospital). It is characterized by a wellness level [27].

and were intended to highlight key hooks in any emergency management ontology for linking to taxonomies of concrete elements of a smart city. The abstract entities are the System external service, Critical event of system, User, and Human service within a smart city. The related entities, such as Managed object, Information, and Human resource allow us to specify the entity properties, and the structure of the situation, through the relationships issues, hasUser, hasHumanResource, hasImpactOn, and recovers. These abstract entities allow us to classify the concrete components involved in emergency situations.

Table 9. Ontology paths for the core concepts of the crisis management semantic patterns, aligned with the BFO foundational concepts (in bold).

Ontology Concept	Ontology Path
Critical event of system	See Table 5.
System external service	See Table 3.
Resource	entity>System_aspect>Resource and entity>continuant>independent continuant>material entity>Resource
Information	entity>System_aspect>Resource>Information and entity>continuant>independent continuant>material entity>Resource>Information
Human Service	entity>occurrent>process>system_external_service>Human_Service and entity>System_aspect>system_external_service>Human_Service
Human Resource	entity>System_aspect>Resource>Human Resource and entity>continuant>independent continuant>material entity>Resource>Human Resource
User	See Table 3.

shows their derivation from the BFO abstract entities.

Various ontological patterns can be defined for the construction of emergency management scenarios. In particular, semantic patterns serve as the foundation for ontology query patterns, which are used to realize SPARQL queries. These query patterns leverage the abstract concepts defined in Table 8, their semantic relationships, and the class taxonomies provided by the ontology. Two examples of semantic patterns for SPARQL query construction are in Figure 5. The emergency core query pattern represents the following generic situation: A Critical event of system affects a Service that provides a (critical) Resource to a User. Then, a Human service sends Human resources to recover the damaged service. The Service communication pattern represents the following: a Service issues Information for another Service and the exchange leverages a Resource (e.g., connectivity) provided by a utility Service (e.g., telecommunication service). Many variants of these patterns can be devised, for example by associating the Critical event of system entity with service entities to represent additional concurrent or subsequent problems which may arise in the scenario evolution.

The following SPARQL query excerpts shows a template finalized for retrieving communication situations among two different services.

           ....
           # service issuing an information resource
          ?pro a owl:ObjectProperty ;
              rdfs:domain ?sService1 ;
              rdfs:range ?infResource1 ;
              rdfs:subPropertyOf :issues.
          FILTER (  !(?sService1 = :System_external_service) )
		   
		   
          # the specific source service
          ?sourceService rdfs:subClassOf :System_external_service .
          FILTER EXISTS {
              ?sourceService rdfs:subClassOf ?sService1 .
          }
		   
		   
          # the specific information issued by source service
          ?infResource rdfs:subClassOf :Information .
          FILTER EXISTS {
              ?infResource rdfs:subClassOf ?infResource1 .
          }
		   
		   
          # the service target is an information provider
          ?targetService rdfs:subClassOf :Information_provider .
          ....
		  

It should be noted that the OQP for crisis management described in De Nicola et al. [27] is in fact a family of patterns that can be incrementally used to form application-specific SPARQL queries.

Finally, to support post-event recovery choices, the following subsection introduces the decision-making semantic pattern, which encodes concepts, such as needs, constraints, actions, and institutional roles, for structuring recovery decisions.

3.3.5. The Decision Making Semantic Pattern

The decision-making semantic pattern provides a semantic structure to represent the essential components involved in planning and executing recovery decisions in post-disaster contexts. The pattern captures the interplay between actors, impacts, intentions, and constraints that shape how decisions are conceived, justified, and implemented. At its core, there is the concept of Recovery decision, defined as a determination aimed at rebuilding communities, restoring functionality, and enhancing resilience after a disaster.

The decision-making semantic pattern is composed of a set of interrelated concepts that structure the representation of post-disaster recovery decisions. As summarized in

Table 10. Summary of the core concepts defined in the decision-making semantic pattern. Each concept represents a key element involved in structuring and supporting post-disaster recovery decisions, including actors, constraints, anticipated consequences, and targeted needs. The pattern provides a semantic foundation for modeling complex decision-making processes in crisis and recovery contexts.

Concept	Description
Action	An activity that should be done to implement a decision.
Decision constraint	Any kind of limitation, restriction, or legal rule a decision must be compliant with.
Disaster impact	The effect of a disaster.
Decision influencer	A person, group, or organization that has an interest or a concern in a decision.
Decision opportunity	Any benefit that can be achieved from a decision.
Decision threat	Anything or anyone threatening the success of a decision.
Disaster	A sudden calamitous event bringing great damage, loss, or destruction.
Envisaged consequence	An estimated threat or opportunity.
Institutional framework	Institutional subjects responsible for a decision.
Need	A condition requiring supply or relief.
Recovery decision	A determination arrived at after consideration aimed at rebuilding communities so that they can return to normal life and protect against future hazards.
Target	The desired state of the affairs to be achieved by means of a decision.
Target group	A person, group, or organization that derives advantage from a decision.

, each concept captures a specific aspect of the decision-making process. At the center of the pattern is the concept of Recovery decision, defined as a determination aimed at rebuilding communities and restoring normal life while preparing for future hazards. Recovery decisions are taken within an Institutional framework, which refers to the institutional subjects responsible for decision-making.

The pattern also includes the concept of Disaster, described as a sudden calamitous event causing significant harm, and its resulting Disaster impact, which expresses the effects of such an event. These impacts generate one or more Needs, understood as conditions requiring supply or relief, and they affect a Target group, any person, group, or organization that stands to benefit from a decision. Each group has an associated Target, representing the desired outcome to be achieved.

To support implementation, a decision results in one or more Actions, which are specific activities to be performed. However, decision-making is often subject to Decision constraints, defined as legal, technical, or contextual limitations that restrict available options. The process is also shaped by Decision influencers, entities that have a stake in or influence over the decision.

Crucially, each decision involves the anticipation of possible outcomes, referred to as Envisaged consequences. These can take the form of Decision opportunities, potential benefits and Decision threats, factors that might jeopardize success. Together, these concepts form a comprehensive structure for semantically modeling recovery decisions and supporting participatory planning processes.

The decision-making semantic pattern aims to represent the conceptual structure underlying decisions taken in response to disaster events. It includes key concepts such as Action, Decision constraint, Disaster impact, Need, and Target group, among others. To ensure ontological clarity and promote interoperability with other domain ontologies, each concept in this pattern is aligned with BFO.

Table 11. Alignment of the decision-making ontology design pattern concepts with BFO foundational concepts (in bold). Each concept is mapped to its corresponding ontological path within the BFO hierarchy, distinguishing between occurrents (e.g., actions, events, impacts), continuants (e.g., needs, roles, target groups), and their subcategories. This alignment ensures semantic coherence and supports integration with other ontologies grounded in BFO.

Ontology Concept	Ontology Path
Action	entity>occurrent>process>Action
Decision constraint	entity>occurrent>spatiotemporal region>Decision constraint
Decision opportunity	entity>occurrent>spatiotemporal region>Decision constraint>Decision opportunity
Decision threat	entity>occurrent>spatiotemporal region>Decision constraint>Decision threat
Disaster	entity>occurrent>process>Event>System event>Actual event/Potential event>Critical event of system>Disaster
Disaster impact	entity>occurrent>process>Event>System event>Actual event/Potential event>Critical event of system>Impact>Disaster impact
Envisaged consequence	entity>occurrent>process>Event>System event>Actual event/Potential event>Envisaged consequence
Decision influencer	entity>continuant>specifically dependent continuant>realizable entity>role>actor>Decision influencer
Institutional framework	entity>continuant>specifically dependent continuant>realizable entity>role>Institutional framework
Need	entity>continuant>specifically dependent continuant>realizable entity>disposition>Need
Recovery decision	entity>continuant>specifically dependent continuant>realizable entity>disposition>function>Decision>Recovery decision
Target	entity>continuant>specifically dependent continuant>quality>Target
Target group	entity>continuant>independent continuant>material entity>object aggregate>Target group

presents the full alignment of these concepts within the BFO hierarchy. Specifically, decision-related entities such as Action, Disaster, and Impact are modeled as Occurrent, reflecting their temporal nature. Roles and functions like Decision influencer, Institutional framework, and Recovery decision are categorized as Specifically dependent continuant, realized through the activity of social actors or systems. Entities, such as Target group, are treated as Material entity, while abstract requirements like Need and Target are modeled as Disposition and Quality, respectively. This structured alignment enables semantic reasoning, modular reuse of ontology patterns, and consistent integration within BFO-compliant knowledge systems.

Figure 6 illustrates the decision-making semantic pattern as UML diagram. At the center of the diagram, there is the class Recovery decision, which acts as the central decision-making entity. This decision is taken by an Institutional framework, influenced by a Decision influencer, and operationalized through an Action, which is itself limited by a Decision constraint. The recovery decision considers one or more Envisaged consequences, which may take the form of a Decision opportunity or a Decision threat. These consequences reflect potential outcomes and risks associated with the decision. The decision is motivated by a Disaster impact, which is caused by a Disaster and concerns a particular Target, the desired state to be achieved. The Target is connected to a Target group that isInterestedIn it and hasNeed for recovery, thus linking community priorities with strategic outcomes.

This pattern makes explicit the causal, functional, and institutional relationships that shape recovery decisions, enabling knowledge structuring, reasoning, and participatory deliberation in emergency and resilience planning.

The following OWL excerpt provides an example of how the decision-making semantic pattern, when taking the role of ontology design pattern, can be extended with domain-specific classes to represent a concrete disaster scenario. In this case, a MajorFlood is modeled as a subclass of Disaster, causing a HospitalServiceDisruption, which is a subclass of DisasterImpact. To address the situation, a HospitalRecoveryPlan (a subclass of RecoveryDecision) is taken, constrained by a BudgetLimitation and implemented through an Action such as DeployMobileClinics. The decision is influenced by the MunicipalHealthAuthority and shaped within the EmergencyManagementProtocol institutional framework. The affected population is represented by the FloodAffectedResidents (TargetGroup) with an identified Need for AccessToEmergencyCare. The decision aims at the Target of RestoreEmergencyCareAccess and considers the EnvisagedConsequence of ImprovedHealthOutcomes. The model also accounts for possible DecisionThreats, such as HealthSystemCollapse, and DecisionOpportunities, like BoostCommunityResilience. This extension demonstrates how the pattern can be instantiated to semantically represent complex decision-making dynamics in crisis response scenarios. For the sake of conciseness, we show only how the object property hasNeed has been implemented.

          <rdf:RDF xmlns=‘‘http://www.terminus.org/ontology#’’
               xml:base=‘‘http://www.terminus.org/ontology’’
               xmlns:rdf=‘‘http://www.w3.org/1999/02/22-rdf-syntax-ns#’’
               xmlns:owl=‘‘http://www.w3.org/2002/07/owl#’’
               xmlns:rdfs=‘‘http://www.w3.org/2000/01/rdf-schema#’’
               xmlns:xsd=‘‘http://www.w3.org/2001/XMLSchema#’’>
		   
		   
           <!-- Specific disaster subclass -->
           <owl:Class rdf:about=‘‘#MajorFlood’’>
             <rdfs:subClassOf rdf:resource=‘‘#Disaster’’/>
           </owl:Class>
		   
		   
           <!-- Specific disaster impact -->
           <owl:Class rdf:about=‘‘#HospitalServiceDisruption’’>
             <rdfs:subClassOf rdf:resource=‘‘#DisasterImpact’’/>
           </owl:Class>
		   
		   
           <!-- Specific decision -->
           <owl:Class rdf:about=‘‘#HospitalRecoveryPlan’’>
             <rdfs:subClassOf rdf:resource=‘‘#RecoveryDecision’’/>
           </owl:Class>
		   
		   
           <!-- Specific constraint -->
           <owl:Class rdf:about=‘‘#BudgetLimitation’’>
             <rdfs:subClassOf rdf:resource=‘‘#DecisionConstraint’’/>
           </owl:Class>
		   
		   
           <!-- Specific action -->
           <owl:Class rdf:about=‘‘#DeployMobileClinics’’>
             <rdfs:subClassOf rdf:resource=‘‘#Action’’/>
           </owl:Class>
		   
		   
           <!-- Specific stakeholder -->
           <owl:Class rdf:about=‘‘#MunicipalHealthAuthority’’>
             <rdfs:subClassOf rdf:resource=‘‘#DecisionInfluencer’’/>
           </owl:Class>
		   
		   
           <!-- Specific institutional framework -->
           <owl:Class rdf:about=‘‘#EmergencyManagementProtocol’’>
             <rdfs:subClassOf rdf:resource=‘‘#InstitutionalFramework’’/>
           </owl:Class>
		   
		   
           <!-- Specific target group -->
           <owl:Class rdf:about=‘‘#FloodAffectedResidents’’>
             <rdfs:subClassOf rdf:resource=‘‘#TargetGroup’’/>
           </owl:Class>
		   
		   
           <!-- Specific need -->
           <owl:Class rdf:about=‘‘#AccessToEmergencyCare’’>
             <rdfs:subClassOf rdf:resource=‘‘#Need’’/>
           </owl:Class>
		   
		   
           <!-- Specific target -->
           <owl:Class rdf:about=‘‘#RestoreEmergencyCareAccess’’>
             <rdfs:subClassOf rdf:resource=‘‘#Target’’/>
           </owl:Class>
		   
		   
           <!-- Specific envisaged consequence -->
           <owl:Class rdf:about=‘‘#ImprovedHealthOutcomes’’>
             <rdfs:subClassOf rdf:resource=‘‘#EnvisagedConsequence’’/>
           </owl:Class>
		   
		   
           <!-- Specific threat -->
           <owl:Class rdf:about=‘‘#HealthSystemCollapse’’>
             <rdfs:subClassOf rdf:resource=‘‘#DecisionThreat’’/>
           </owl:Class>
		   
		   
           <!-- Specific opportunity -->
           <owl:Class rdf:about=‘‘#BoostCommunityResilience’’>
             <rdfs:subClassOf rdf:resource=‘‘#DecisionOpportunity’’/>
           </owl:Class>
		   
		   
           <owl:ObjectProperty rdf:about=‘‘#hasNeed’’/>
           …
		   
		   
            <!-- FloodAffectedResidents hasNeed some AccessToEmergencyCare -->
            <owl:Class rdf:about=‘‘#FloodAffectedResidents’’>
                <rdfs:subClassOf>
                    <owl:Restriction>
                        <owl:onProperty rdf:resource=‘‘#hasNeed’’/>
                        <owl:someValuesFrom rdf:resource=‘‘#AccessToEmergencyCare’’/>
		    </owl:Restriction>
                </rdfs:subClassOf>
            </owl:Class>
		   
		   
          …
		   
		   
          </rdf:RDF>
		  

4. TERMINUS Validation

Ontology validation addresses the syntactic, semantic, social, and pragmatic qualities of TERMINUS. System-level performance benchmarks (e.g., query latency, throughput, scale-out) depend on implementation choices and deployment environments and are therefore outside the scope of ontology validation, though they remain valuable future work. In this section, we report syntactic/semantic checks and alignment/size metrics, summarize social and pragmatic evidence from engagements and use cases, conclude with a concise Summary of evidence.

4.1. Theoretical Validation

The quality of the TERMINUS ontology was assessed following the semiotic metrics framework proposed by Burton-Jones et al. [78], which evaluates ontologies along syntactic, semantic, social, and pragmatic dimensions. This framework provides a comprehensive perspective on ontology quality, balancing formal rigor with considerations of usability and adoption.

Syntactic quality refers to the extent to which an ontology adheres to formal language specifications. TERMINUS was developed using the OWL 2 specification [79], ensuring compliance with the syntax and semantics of this W3C standard [79]. All design patterns were verified to ensure that no syntactic violations occurred during integration.

Semantic quality concerns the clarity, interpretability, and correctness of the ontology’s conceptualizations. The ontology was validated using automated reasoners (e.g., Pellet, HermiT) to check for logical consistency, class satisfiability, and correct use of axioms. TERMINUS ensures semantic clarity through explicit textual definitions for all concepts and object properties, with the alignment to the BFO upper-level ontologies. The definition of domain concepts are grounded in authoritative definitions from standards, regulations, and expert consensus.

Social quality measures the degree to which an ontology is trusted, reused, and accepted by its intended community. TERMINUS builds on a widely adopted foundational ontology, i.e., BFO, and reuses well-established W3C standards (i.e., Time and Geo vocabularies), increasing its compatibility and acceptance potential, as well as interoperability. The ontology’s development involved collaborative workshops and validation sessions with several domain experts from different institutional organizations (e.g., ARPA Lazio, ARPA Umbria, ENEA and Roman Civil Protection) in different National and International research projects [23,27], fostering community engagement and consensus. Furthermore, its modular patterns-based design encourages reuse and adaptation in related domains beyond smart cities.

Pragmatic quality evaluates the relevance and usefulness of the ontology for accomplishing specific tasks. In the case of TERMINUS, this dimension is demonstrated by the application-oriented results reported in the following, where multiple real-world use cases are presented. These include semantic spatio-temporal risk assessment, cascading risk modeling, creative emergency scenario design, and participatory recovery planning. Each use case illustrates how the semantic patterns (ODPs and OQPs) directly support operational decision-making, scenario generation, and cross-domain data integration in smart city crisis management.

By applying the semiotic metrics suite, we ensure that TERMINUS is not only formally correct and semantically clear but also pragmatically valuable, as evidenced by its real-world applications, and socially acceptable through community-driven design and adoption.

4.2. Pragmatic Validation Through Use Cases

Evaluating an ontology solely on formal or syntactic criteria is insufficient when it is applied in participatory and creative domains such as smart city planning and emergency scenario design. In these contexts, pragmatic and social aspects become central to assessing the ontology’s real-world value. As mentioned, pragmatic quality reflects how effectively an ontology supports task relevance, accuracy, and comprehensiveness for its users, while social quality relates to the degree of trust, reuse, and acceptance it gains within a user community. These dimensions are especially pertinent in the use cases presented, where the TERMINUS ontology has been employed to support identifying risk and emergency scenarios and to guide expert deliberation. For instance, in the creative scenario design process, pragmatic quality is evidenced by how well the ontology supports the generation of novel yet plausible events across different urban infrastructures. Social quality is reinforced by collaborative validation sessions, where domain experts assess, adapt, and adopt the proposed models, thus embedding the ontology within a shared decision-making process. Together, these evaluation layers ensure that the ontology is not only technically sound but also socially embedded and operationally meaningful.

4.2.1. Risk-Oriented Applications

Semantic Spatio-Temporal Risk Assessment

Semantic spatio-temporal risk assessment is the process of automatically evaluating potential risks for a system based on their spatial and temporal dimensions, leveraging semantic knowledge to capture the meaning and interrelations of the entities composing them [23]. Indeed, the result comprises both qualitative and quantitative assessments, which are performed on geo-localized risk model fragments, called risk mini-models, once these have been generated and associated with sensitive exposed elements in given locations, such as Points of Interest (POIs).

The core semantic pattern of risk is depicted in Figure 3. This can be further specified, with respect to the System aspect, to describe the type of component (e.g., System external service) together with its associated vulnerability (e.g., Functional vulnerability), which contributes to the critical event affecting a given type of stakeholder (e.g., Operator). The pattern is multi-shaped in that the abstract entities can be specialized in different ways to represent various system components, associated vulnerabilities, and stakeholder perspectives, while maintaining a shared semantic structure, especially thanks to the system aspect pattern illustrated in Figure 2. Once a risk pattern is defined for a specific aspect, its implementation in SPARQL queries, leveraging the class taxonomies of the ontology, enables the automatic generation of the corresponding risk mini-models.

The TERMINUS application ontology, devoted to risks in urban contexts, is central to the architecture of a semantic spatio-temporal risk assessment system. The ontology underpins a semantic reasoning system that enables a software component, named the CREAtivity Machine (CREAM), to support creative methods applied to the design of models for risk management. Through a web service technology (i.e., WS-CREAM, CREAtivity Machine Web Service), CREAM supports in generating and assessing risk mini-models. Each mini-model is a semantically structured tuple representing a potential risk for a specific Point of Interest (POI) and includes instances of the five core concepts of the risk ontology pattern (see Figure 3). The risk mini-models are generated automatically using SPARQL queries contextualized using spatio-temporal data (e.g., operating hours of services, environmental hazard levels). For example, the system can model a risk where a hospital (System service) is vulnerable to internal crowding (Functional vulnerability) during a flood (Hazard), leading to disruptions in healthcare delivery (Critical event of system) and affecting patients (Stakeholder). The risk mini-models are then ranked using a time-dependent risk function and visualized through a WebGIS interface to support decision-making.

The effectiveness of the TERMINUS ontology was evaluated through two real-world case studies in the city of Rome, focusing on areas exposed to earthquake and flood hazards [23]. Experts assessed the plausibility of the automatically generated risk mini-models and their usefulness for qualitative risk assessment. Results showed that the majority of the scenarios were judged plausible (up to 100% in some cases) and that the system’s objectivity helped mitigate the subjectivity inherent in human evaluations. Furthermore, experts attributed different weights to evaluation criteria (e.g., time relevance, vulnerability level, hazard localization), highlighting the value of TERMINUS in providing a consistent and structured foundation for comparative risk analysis. The ontology’s well-defined concepts and properties facilitated semantic reasoning and automated scenario generation, thereby demonstrating its capability to support comprehensive, scalable, and objective urban risk assessment [23].

Operationally, the ranked mini-models exposed through the WebGIS (e.g., for hospitals and transport corridors) can be used by municipal emergency officers to (i) prioritize pre-event inspection routes and functional checks for healthcare facilities in flood-exposed districts; (ii) rehearse diversion and access-control plans on segments where earthquakes, or flood-triggered disruptions, would concentrate flows.

Cascading risks in interdependent systems

Critical infrastructures are complex socio-technical systems, characterized by numerous interdependency [80,81] links. Identifying potential cascades of failures [82] and the resulting risk models is challenging, making creative methods a valuable approach [39]. We define a cascading risk mini-model (or cascade of risk mini-models) as a sequence of risk mini-models in which the risk affecting one system aspect depends on the risk affecting another system aspect. These system aspects may belong to different systems or to the same system. TERMINUS has been expanded with an application ontology to support automatic generation of cascading risk mini-models.

The use case is grounded on the cascading risk semantic pattern described in Figure 4. Crucially, the TERMINUS application ontology models interdependencies using the object property isInterdependentWith, with sub-properties like physicalInterdependency, cyberInterdependency, geographicInterdependency, and logicalInterdependency.

These symmetric object properties connect concepts across different system aspects (e.g., Provision_of_fuel and Cars_and_trucks_move) and enable the semantic chaining of cascading failures across domains.

We expanded the CREAtivity Machine (CREAM) software (v1.0) component [23,27] with a computational method to automatically generate semantically coherent chains of candidate risk mini-models, referring to different interdependent systems, to be validated by experts. As a simple example, a hurricane (Hazard) causes flooding of gasoline stations (HazardThreat) in the oil system (System Aspect: Provision of fuel), impacting highway users (Stakeholder). This, in turn, cascades to the transportation system (System Aspect: Cars and trucks move) and further to the water system (System Aspect: Drinking water distribution) due to fuel-dependent delivery mechanisms. These semantic links are enabled by the isInterdependentWith object property, and its specializations, within the ontology. The method required expert validation on risk mini-models of the individual systems, which was done by using the ICE app [45]. Whenever updates to the risk definitions of a system involve aspects that are sources of interdependency links with aspects of other systems, CREAM automatically generates risk mini-models for these interdependent systems by following the system interdependency relationships defined in the TERMINUS ontology. Sequences of these mini-models, each representing a risk situation in one system that may lead to a risk situation in another, are then automatically proposed to risk experts as cascading risk representations for validation.

The ontology was tested for its ability to produce cascading risk results in domains such as oil, transportation, and water systems. Preliminary tests in these sectors have demonstrated the method’s capacity to generate meaningful outputs, and its usefulness has been positively evaluated by expert researchers in risk analysis and enterprise interoperability [39].

4.2.2. Crisis Management Applications

Creative Scenario Design

We define an emergency management (EM) scenario as a user narrative of a contextualized real or imagined emergency scenario in a city. This scenario can be represented as a model linking a set of situations, named mini-stories [27], grouped in three phases: start, to describe the initiating event (trigger) and the (part of) emergency created in the spatial and temporal context of the city; middle, to describe what follows, e.g., secondary events and new situations that could arise; and end, to describe reactions by the emergency services and decisions [27]. The advantage of this modular design approach is that different scenarios can be obtained by different definitions and/or reuse of ministories, enabling creative identification of possible situations.

The semantic framework, detailed in [27], consists of the CEML application ontology, currently integrated in TERMINUS, representing the domain of crisis and emergency management in smart cities; a set of predefined ontology patterns for scenario building; and contextual semantic rules that allow further refinement of the domain knowledge in specific urban contexts, supporting the generation of tailored emergency scenarios and management processes. The pre-defined ontology design patterns and the contextual rules, once implemented in SPARQL queries, allow the automatic generation of semantically coherent ministories for a given location and temporal period. Essentially, the ministories are application-specific models, derived by associating subclasses of the components of an abstract pattern, such as the one illustrated in Figure 5, while preserving the same semantic structure of that pattern. A total of 14 ontology patterns have been developed for an experimentation aimed at validating the usage of the ontology for the creative scenarios design.

The software application devoted to crisis and emergency scenarios, named M-CREAM (v1.0), encompasses a knowledge base and related computational services that enable automated reasoning to identify plausible ministories, as well as semantic similarity functions to support their classification, exploration, and ranking. Through a web interface, the application allows users, particularly emergency management officers and planners, to describe and explore alternative scenarios for smart cities. Each scenario is built using mini-stories composed of TERMINUS concepts, and the system uses these models to suggest new emergency situations following computational creativity [83] methods applied to the ontology patterns.

The usefulness and expressiveness of the TERMINUS ontology were evaluated through a case study involving emergency management in the city of Rome. Scenarios were generated for critical infrastructures such as transportation and hospital services. The evaluation focused on whether the generated scenarios were novel, plausible, and useful for experts in emergency management.

The results demonstrated that the system, driven by the TERMINUS ontology, successfully supported experts in conceiving new emergency scenarios. It was particularly effective in aiding the exploration of low-probability, high-impact events. Feedback from participants confirmed that the semantic structure provided by the ontology facilitated clearer communication, improved scenario coverage, and enabled a more systematic approach to emergency planning.

Decision-Making

The decision-making use case concerns a gamified process for participatory post-crisis recovery supported by a conceptual model grounded in the decision-making semantic pattern (see Figure 6) [76]. This model defines abstract concepts and relationships essential for structuring recovery decisions in urban contexts. The key ontology concepts include: Disaster, Disaster impact, Recovery decision, Target, Target group, Need, Influencer, Envisaged consequence, Decision threat, Decision opportunity, Institutional framework, Action, and Constraint. Now explicitly embedded in TERMINUS, the pattern provides a semantically rich and reusable framework for capturing the multifaceted aspects of recovery-related decisions. The model is operationalized through a canvas, inspired by conceptual patterns such as those found in business model representation, offering an intuitive visual structure to guide participant input.

The decision-making semantic pattern was embedded in a gamified decision-making process called R-EAGLE-S (L’Aquila Rises Simulation) [76], which aimed to involve citizens and administrators in post-crisis recovery planning after the 2009 earthquake in L’Aquila, Italy [84,85,86,87,88]. During the process, participants used a decision-making canvas to represent their proposals, structured according to the pattern components. These included identifying affected needs, formulating actions, assessing opportunities and threats, and considering institutional constraints and stakeholder roles.

This structured approach allowed diverse users, both experts and citizens, to collaboratively elaborate and negotiate decisions within a simulated, role-playing environment. The semantic richness of the model enhanced clarity, comparability, and integration of diverse decision elements, and the canvas served as both a data collection tool and a shared reference model during deliberation.

The evaluation of the ontology-based decision model was conducted during the VII Michelangelo workshop through a live simulation involving 23 participants and four expert evaluators. The simulation covered four domains of post-crisis recovery: housing, economy, education, and welfare/health. Participants created individual and team decision proposals using the canvas, which were subsequently assessed by experts based on clarity, completeness, and realism.

Feedback confirmed that the decision-making semantic pattern effectively captured the essential dimensions of complex recovery decisions and supported a coherent decision-making process. Experts found the proposals valuable starting points for real recovery projects, while participants reported that the structured canvas was intuitive and facilitated creative thinking. Overall, the model-based approach proved effective in engaging stakeholders and producing well-structured, semantically informed decision outputs.

In operational terms, the decision-making canvas supports production of structured proposals that agencies can translate into recovery action sheets (targets, actions, constraints, responsible units) and track over time. In the L’Aquila simulation with 23 participants and four expert evaluators, several proposals were judged clear, realistic, and suitable as starting points for concrete initiatives in housing, economy, education, and welfare/health, supporting collaborative prioritization and assignment of responsibilities in post-crisis programs.

4.2.3. Innovation-Oriented Application

Business Innovation

The business innovation use case explores how a dedicated semantic pattern, specifically designed for modeling business ideas, can support the development of innovative and resilient services in smart cities [89]. The business innovation semantic pattern formalizes the conceptual structure of business models by specializing some elements from the business model canvas proposed by Osterwalder and Pigneur [90], including concepts such as Value_Proposition, Customer_Segment, Channel, Key_Activity, and Key_Partner. These elements are structured into a semantic pattern used to represent idea models termed creative sparks and guide their semantic generation and evolution. For the sake of conciseness, we do not present the details of this pattern here; it is based on the work of Osterwalder and Pigneur [90]. We integrated this semantic pattern into TERMINUS to demonstrate its flexibility in encompassing not only risk and crisis management aspects but also the business dimension of resilience, particularly in supporting innovation processes for building resilient urban services.

The ontology was integrated within a software architecture composed of two main components: CREAM (v1.0), which, as mentioned, performs computational creativity functions, and ICE4B (Innovation through Collaborative Environment for Business) (v1.0), a mobile app facilitating a gamified collaboration process. CREAM uses the ontology to generate creative sparks, semantically structured preliminary business ideas, based on domain knowledge, user context, and heuristic methods (e.g., transformation, combination, and analogy-based searches).

These creative sparks are presented to users via ICE4B, where participants may iteratively elaborate, refine, and evaluate the ideas using gamification mechanics. The application support the divergent–convergent thinking process essential in innovation design through real-time interaction, voting, and knowledge reuse within innovation teams working on domains like energy, transportation, and healthcare.

Summary of evidence. 

Table 12. Validation summary for TERMINUS across the four semiotic quality dimensions. The syntactic and semantic rows report computed values (e.g., HermiT consistency checks, BFO alignment, contradictions, and ontology size metrics); the social and pragmatic rows list the indicators collected in our study (collaborating bodies, participants, experiments in a relevant environment, funded projects, and the number of ODPs/OQPs exercised).

Quality Dimension	Indicator with Value
Syntactic quality	Syntax violations checked with Hermit reasoner = 0
Semantic quality	BFO alignment coverage = 100%
	Number of contradictions = 0
	Number of axioms = 2098
	Number of classes = 177
	Number of object properties = 70
	Number of data properties = 31
	Number of SubClassOf = 287
Social quality	Number of collaborating bodies = 9
	Number of involved persons = 67
Pragmatic quality	Number of experiments in a relevant environment = 7
	Number of funded projects = 7
	Number of experimented ODPs = 8
	Number of experimented OQPs = 14

consolidates the quantitative evidence gathered in Section 4 along the four semiotic quality dimensions. Syntactic quality is confirmed by zero syntax violations in the OWL 2 serialization (Protégé checks), ensuring that the ontology parses correctly. Semantic quality is validated with HermiT: full classification yields logical coherence with no contradictions or unsatisfiable classes, alongside alignment and size indicators (100% BFO grounding of the core vocabulary; 2098 axioms; 177 classes; 70 object properties; 31 data properties; 287 SubClassOf axioms), consistent with a modular, pattern-based design. Social quality reflects the breadth of external engagement to date (nine collaborating bodies; 67 participants across workshops, validations, and co-design sessions). Finally, pragmatic quality captures use-oriented evidence in relevant settings (seven experiments and seven funded projects), as well as the degree of operationalization (#ODPs exercised = 8; #OQPs exercised = 14) across the Rome and L’Aquila applications. Together, these indicators substantiate the claims made in Section 4.1 and Section 4.2: TERMINUS is not only formally sound and semantically rigorous, but also socially embedded and operationally effective for risk assessment, cascade analysis, emergency scenario design, and recovery decision-making.

5. Discussion

5.1. Positioning of TERMINUS in the Crisis Management Lifecycle

The TERMINUS ontology results from the interconnections of the presented semantic patterns, as shown in Figure 7.

Table 13. The positioning of the TERMINUS semantic patterns within the crisis management lifecycle phases. Each pattern supports specific tasks in prevention, preparedness, response, and recovery, ensuring semantic continuity and interoperability across the lifecycle.

	Phase	Prevention	Preparedness	Response	Recovery
SPs
System Aspect		Identification of critical assets and dependencies to reduce vulnerability	Mapping of infrastructures, resources, and stakeholders; capability assessment; baseline system modeling	Support for rapid system status assessment	Updating system models with post-event changes
Risk		Prioritization of mitigation actions; hazard monitoring models	Hazard and vulnerability analysis; risk scenario definition	Contextualization of risks to guide operational decisions	Lessons learned for future hazard impact reduction
Cascade		Prevention of cascading failures through targeted interventions	Modeling interdependencies between systems; scenario simulation	Identification of potential cross-system impacts during an event	Post-event analysis of cascading effects
Crisis Management		Refinement of emergency plans and coordination protocols	Development of generic and location-specific emergency scenarios	Structured representation of service disruptions, resource allocation, and inter-service communication	Documentation of response effectiveness for plan improvement
Decision-Making		Integration of decision constraints into preventive strategies	Simulation of decision-making exercises; stakeholder engagement in preparedness planning	Support for in-crisis decision tracking	Formalization of post-crisis recovery plans, needs assessment, and resilience-building actions

illustrates how the TERMINUS semantic patterns can provide systematic support across the four phases of the crisis management lifecycle. In the prevention phase, the system aspect pattern contributes to identifying critical assets and dependencies in order to reduce vulnerabilities, while the risk and cascading risk patterns enable the prioritization of mitigation actions and the modeling of interdependencies to prevent cascading failures. The crisis management patterns complement these efforts by refining emergency plans and coordination protocols, and the decision-making pattern supports the integration of preventive strategies within broader policy frameworks. In the preparedness phase, the system aspect pattern facilitates the mapping of infrastructures, resources, and stakeholders, forming the basis for capability assessments and baseline system modeling. The risk pattern allows for hazard and vulnerability analysis as well as the definition of risk scenarios, while the cascade pattern models interdependencies between systems to simulate possible crisis propagation. Preparedness is further strengthened by the crisis management patterns, which supports the development of both generic and location-specific scenarios, and by the decision-making pattern, which enables decision-making exercises and stakeholder engagement. During the response phase, the system aspect pattern supports rapid assessment of the status of critical systems, ensuring that disruptions are accurately represented. The risk pattern contextualizes hazards to inform operational choices, and the cascading risk pattern identifies potential cross-system impacts as they unfold. The crisis management patterns play a central role by providing structured representations of emergency events, service disruptions, and coordination mechanisms, while the decision-making pattern tracks decisions taken in real time, ensuring transparency and accountability. Finally, in the recovery phase, the system aspect pattern enables the updating of system models to reflect post-event changes. The risk and cascade patterns are applied to assess lessons learned, refine risk models, and analyze cascading effects that occurred during the crisis. At the same time, the crisis management patterns support the documentation and evaluation of response effectiveness to improve future planning. The decision-making pattern provides a formal framework for capturing recovery processes, including needs assessment, reconstruction priorities, and resilience-building measures.

In practice, the design–query pattern duality operationalizes the ontology: the same constructs used to model risk, cascades, emergency management, and recovery also drive auditable queries, enabling planners to generate, inspect, and compare options, not merely visualize integrated data.

Together, these patterns ensure that knowledge captured at each phase remains semantically coherent, reusable, and interoperable across systems and stakeholders, enabling a continuous feedback loop that strengthens future prevention and preparedness efforts, and positioning TERMINUS as a comprehensive semantic infrastructure for urban resilience and crisis management.

TERMINUS is not bound to a specific city or hazard: it is designed as a BFO-aligned upper ontology with modular semantic patterns that capture system aspects, risks, cascading effects, emergency management, and decision-making. These patterns are reusable across domains (e.g., energy, transport, health, environment) and across geographies. The OQPs provide a reusable “query grammar” that can be instantiated with local data, enabling portability from one urban context to another. We also note that TERMINUS reuses widely adopted vocabularies (W3C Time), which supports interoperability with existing datasets and platforms in different regions. This design ensures that while Rome and L’Aquila demonstrate feasibility and usefulness, the ontology is generalizable to other cities, sectors, and crisis types.

5.2. Answering the Research Questions

TERMINUS provides clear answers to the research questions presented in Section 1. RQ1 is addressed through the development of ontology design patterns that capture essential concepts and relationships across crisis management. RQ2 is answered by operationalizing ontology query patterns as reusable SPARQL templates ensuring semantic continuity from modeling to data exploitation. RQ3 is supported by the cascading risk patterns, validated in case studies, which demonstrate TERMINUS’s ability to represent and reason over interdependencies and cascading failures. Finally, RQ4 is demonstrated by pragmatic validation in multiple use cases, where TERMINUS proved effective in supporting risk assessment, emergency scenario design, and participatory recovery planning.

Overall, TERMINUS confirms its role as a coherent and actionable semantic infrastructure that ensures interoperability and practical value across all phases of the crisis management lifecycle.

5.3. Policy Alignment and Governance Implications

TERMINUS provides machine-interpretable structures that support compliance with priorities of the Sendai Framework (2015–2030) [91]: P1—Understanding risk: Risk and cascading risk patterns integrate hazards, system aspects exposed to risk (exposure), and vulnerability, serving as semantic models for the development of applications for dissemination of risk information, taking into account the needs of different users; P2—Risk governance: A multi-dimensional structure of risk, grounded in system aspects and stakeholder perspectives, together with the specification of interdependencies, enables the development of collaborative applications both within and across institutions for systemic risk management; P3—Investing in resilience: ODPs and OQPs help highlight asset criticalities and to structure possible decisions; P4—Preparedness, response, and “Build Back Better”: emergency-management and decision-making patterns support exploration of new scenarios useful for exercises and post-event recovery.

Operational benefits are rooted in the ontology’s conceptual structure, which facilitates taxonomy-based extensions and supports automated reasoning to implement creative scenarios and new decisions. In this way, the same framework not only allows us to develop decision-support tools based on the KPIs needed by municipalities and emergency operators, but also enables the exploration of low-probability, high-impact risk scenarios that require innovative thinking. Through case studies tested by emergency operators, the potential for developing new applications has been demonstrated, while the ontology facilitates interoperability with external systems for resilience management. In sum, TERMINUS complements existing frameworks by providing reusable semantic patterns and queries that help expand and strengthen systems for resilience governance.

5.4. Limitations

As a BFO-aligned upper/foundational ontology, TERMINUS shares the strengths and trade-offs typical of this class. On the benefit side, its modular semantic patterns and systematically derived ontology query patterns lower the effort of building ontologies and knowledge graphs and make their operational exploitation more direct and reusable across use cases. At the same time, practical deployment still requires constructing and curating the domain/application ontologies and the underlying KGs, activities that usually involve domain experts and/or assisted authoring (e.g., with large language models) to ensure conceptual fidelity and data quality.

While TERMINUS is modular and OWL 2-compliant, reasoning and query performance at a very large scale depend on the deployment stack (triplestore/reasoner, indexing, hardware) and on streaming pipeline design; such system-level benchmarks are beyond the scope of this paper. Interfacing with legacy systems also requires schema alignment despite our reuse of widely adopted vocabularies (e.g., W3C Time, WGS84/Basic Geo); to reduce integration costs, application-specific mapping templates can be supplied where appropriate.

Cross-domain adoption also poses challenges, as sectoral datasets often rely on heterogeneous standards and legacy vocabularies. Although TERMINUS promotes interoperability through BFO alignment and reuse of W3C vocabularies, further work is needed on automated schema matching and harmonization. Looking ahead, coupling TERMINUS with AI-assisted reasoning, multi-agent systems for distributed decision support, and digital twin platforms for dynamic simulation of cascading risks would strengthen its capacity to support real-time, cross-domain crisis management.

6. Conclusions

This paper has presented the TERMINUS ontology, a BFO-aligned semantic framework designed to support the full crisis management lifecycle in smart cities. TERMINUS is structured around a set of reusable ontology design patterns and ontology query patterns that together provide a coherent bridge between conceptual modeling and operational knowledge graph exploitation. The ontology incorporates established foundational resources such as BFO, and the W3C Time and Geo vocabularies, while also introducing mid-level, crisis-management-oriented constructs that position TERMINUS as a foundational ontology in its own right.

A key contribution of this work is the explicit mapping of the TERMINUS semantic patterns to the four phases of the crisis management lifecycle, i.e., preparedness, prevention, response, and recovery, ensuring semantic continuity and interoperability across diverse applications. The engineering of the ontology was carried out in close collaboration with stakeholders from municipal administrations, infrastructure operators, and emergency management agencies, ensuring that the patterns were grounded in real operational needs and validated in realistic contexts.

The theoretical validation, based on the semiotic metrics framework, has confirmed the syntactic and semantic soundness of the ontology, its pragmatic value, as demonstrated in multiple real-world use cases, and its social quality through community engagement and reuse potential. The use cases, including semantic spatio-temporal risk assessment, cascading risk modeling, creative emergency scenario design, and participatory recovery planning, illustrate the versatility and practical impact of the TERMINUS approach.

Future work will focus on extending the ontology to cover additional domains relevant to urban resilience, integrating real-time data streams for dynamic knowledge graph updates, and refining automated reasoning and query generation capabilities. We also plan to promote broader adoption of TERMINUS by releasing the ontology, documentation, and associated query patterns under open licenses, and by fostering a community of practice to evolve the framework in line with emerging crisis management needs.

By combining rigorous ontological grounding, pattern-based modularity, and operational validation, TERMINUS provides a robust semantic infrastructure for integrating and exploiting knowledge in complex, interdependent urban systems, ultimately contributing to more effective, informed, and resilient crisis management.