IoDT² Ontology

A Comprehensive BFO-Aligned Schema for Cross-Domain Digital Twin Applications

1

Introduction and Motivation

The rapid evolution of urban infrastructure, coupled with the increasing complexity of modern cities, has catalyzed a growing demand for robust digital twin architectures. Within this context, the IoDT² (Internet of Digital Twin Things) framework seeks to unify heterogeneous domains—such as construction management, seismic events, transport networks, and sensor data—through a single, semantically consistent ontology. The proposed IoDT² Ontology consolidates infrastructural and event-based knowledge in alignment with the Basic Formal Ontology (BFO), while integrating widely recognized standards including SOSA (Sensor, Observation, Sample, and Actuator), GeoSPARQL, and OWL-Time. By offering a versatile schema that handles diverse elements ranging from building sub-components to spatiotemporal phenomena, this ontology enables advanced reasoning, interoperability, and real-time data processing across multiple use cases.

In the domain of urban informatics, digital twins have emerged as a transformative paradigm to model, simulate, and analyze real-world entities and processes through virtual representations. These representations bridge physical infrastructures (e.g., buildings, roads, cell towers) and events (e.g., earthquakes, construction stages, transportation flows) under a unified data model. However, designing such an ontology faces numerous challenges: the need for high-level philosophical consistency (ensured by BFO), the requirement to incorporate sensor data lifecycles (ensured by SOSA), the necessity for spatial intelligence (ensured by GeoSPARQL), and the demand for explicit temporal representation (ensured by OWL-Time). The IoDT² Ontology meets these challenges through modular yet integrated classes and properties, offering a scalable approach for both real-time monitoring and retrospective analysis in complex urban scenarios.

2

Methodological Foundations

The development of this ontology adheres to established ontology engineering principles, borrowing insights from methodologies such as Methontology and the NeOn Methodology. These approaches stress iterative development, modular design, and stakeholder-driven validation. In particular:

Specification Phase

Core domain requirements are identified by examining high-level user stories, typical urban processes (e.g., building construction, seismic mitigation, traffic analysis), and sensor use cases. This step ensures that each concept—like Building, Road, Vehicle, EarthquakeEvent—directly supports an actual data or query requirement in the digital twin ecosystem.

Conceptualization Phase

The identified classes, relations, and properties are systematically organized. Here, the distinction between continuants (static entities) and occurrents (time-bound processes) becomes paramount. For example, a building is considered a :ContinuantEntity, whereas an earthquake or a transport flow constitutes an :OccurrentEvent.

Formalization Phase

Using OWL (Web Ontology Language) constructs, developers incorporate logical axioms, class hierarchies, object and data properties, and cardinality constraints. This ensures machine-interpretable semantics and supports advanced reasoning tasks, such as automated consistency checks and inference over spatiotemporal data.

Throughout this process, emphasis is placed on maintainability and extensibility. While certain domains like SAREF modeling deliberately excluded in the current scope, the ontology's design leaves open the possibility of integration with these domains in future iterations.

3

BFO Integration

At the highest level, the IoDT² Ontology adopts BFO to provide a clear philosophical scaffold. BFO distinguishes between:

Continuants (bfo:Continuant): Entities that persist through time while possibly undergoing qualitative changes. In IoDT², these are represented by the class :ContinuantEntity, encompassing physical objects such as buildings, roads, fiber cables, cell towers, and vehicles.

Occurrents (bfo:Occurrent): Entities that unfold over time (events, processes, or stages). In IoDT², these are represented by the class :OccurrentEvent, covering phenomena such as earthquakes, aftershocks, construction stages, and transportation flows.

This dual classification elegantly captures both static infrastructural elements and dynamic activities. By anchoring these conceptual distinctions in BFO, the ontology aligns with broader biomedical and engineering ontologies that employ the same top-level framework, thus facilitating potential cross-domain interoperability.

4

Scope and Key Domains

The IoDT² Ontology defines a comprehensive set of domain classes and object/data properties, focusing on three primary domains—construction, earthquake, and transport—while also incorporating a selective sub-scenario related to communication infrastructure within the earthquake context.

4.1 Construction Domain

:ConstructionProject: An instance of :OccurrentEvent that organizes the entire lifecycle of a building or infrastructure's development.

:ConstructionStage: Represents distinct phases of the construction process (e.g., foundation, structural framing). An ontology-level restriction ensures that each construction project must have at least one stage (:hasStage).

:Building: A subclass of :ContinuantEntity, specialized further into :ResidentialBuilding or :CommercialBuilding, each capable of containing multiple building elements (:Column, :Door, :Wall, etc.) via the :hasBuildingElement property.

Data Properties: Elements like :hasBudget or :hasFloors enable the tracking of construction costs and structural complexity, respectively. These features can be critical for cost—benefit analyses or risk mitigation strategies.

4.2 Earthquake Domain

:EarthquakeEvent: An extension of :OccurrentEvent designed to capture seismic events, including attributes for magnitude (:hasMagnitude) and a direct relationship (:affectsBuilding) to the infrastructural elements that may sustain damage.

:AftershockEvent: A specialized seismic occurrence that follows an earthquake and may further affect infrastructure already impacted by the primary seismic event.

Communication Sub-Scenario: As part of the earthquake context, the ontology includes telecommunication elements (e.g., "CellTower", "FiberCable") to illustrate how quakes can disrupt networks. This communications scenario is not treated as a standalone domain but rather as a sub-scenario, highlighting potential failures in cell towers and fiber cables during or after seismic activity. This approach underscores that telecommunication disruptions are primarily a secondary effect within the broader earthquake resilience analysis rather than a top-level focus area.

4.3 Transport Domain

:TransportFlow: Modeled as an :OccurrentEvent representing the movement of :Vehicle instances (e.g., :Bus, :Truck, :Train) over a specific route or network during defined time intervals.

:usedInFlow: An object property linking a :Vehicle to the associated :TransportFlow, enabling complex queries regarding multi-vehicle interactions, congestion patterns, or capacity planning.

Data Properties: For instance, :hasFuelType allows classification of vehicles by fuel usage (electric, diesel, hydrogen), and :hasTrafficVolume can be assigned to measure the intensity or density of traffic over a period.

5

Sensors, Observations, and Data Streams

A critical requirement for any digital twin is the ability to integrate real-time or near-real-time sensor data. The IoDT² Ontology leverages SOSA for a standardized approach to sensors and observations:

:InfrastructureSensor: A subclass of sosa:Sensor, encompassing physical devices that measure or detect various parameters (e.g., seismic vibrations, temperature, vehicle speed).

:MeasurementObservation: An extension of sosa:Observation, designed to capture measurement values (numeric or textual). For example, an accelerometer on a building might publish magnitude data during an earthquake event, or a traffic sensor could log the number of passing vehicles per minute.

:deploysSensor: An object property indicating that a :ContinuantEntity hosts a sensor device. This property is critical in contexts such as structural health monitoring (bridges or towers) and telecommunication oversight (cell towers).

Temporal and Spatial Aspects: Through the combination of :hasTimeInterval (OWL-Time) and :hasGeoFeature (GeoSPARQL), each measurement can be anchored to a specific time range and location. Such spatiotemporal fidelity is essential for granular analytics—for instance, detecting which building floors experience the highest tremors during a quake, or which road segments exhibit peak traffic flows at certain hours.

6

Communication Infrastructure Within the Earthquake Sub-Scenario

While communication infrastructure is not modeled as an independent domain, its role in earthquake resilience is explicitly incorporated as a sub-scenario. When seismic events occur, telecommunication nodes (:CellTower, :FiberCable) may be at risk. By adopting a consistent pattern—analogous to how a quake affects buildings—this ontology can represent damage to networking elements.

The :EarthquakeEvent class can "affect" or "disrupt" communication assets, thereby illustrating downstream effects such as reduced network coverage or compromised emergency-response communications. Nonetheless, the ontology does not emphasize communication infrastructure as a standalone topic; it remains subordinate to the broader seismic modeling efforts.

7

Advanced Querying, Reasoning, and Usage

An ontology-based digital twin enables queries and reasoning tasks that surpass typical relational databases. Potential use cases include:

Automated Risk Assessment: Reasoning over classes like :EarthquakeEvent or :ConstructionProject can flag conflicts—for instance, identifying if construction is scheduled in a seismically active zone.

Sensor Integration: Real-time data from :InfrastructureSensor elements can dynamically update the knowledge graph, enabling alert systems to detect structural anomalies or sudden traffic surges.

Spatiotemporal Analysis: Using GeoSPARQL and OWL-Time, analysts can visualize how events (quakes, transport flows, aftershocks) propagate over space and time, offering deeper insights into vulnerabilities and response strategies.

Scenario Simulation: Planners can simulate large-scale disruptions, such as a major earthquake that affects both buildings and telecommunication lines, integrating transport flow data to assess evacuation routes.

8

Conclusion

The IoDT² Ontology offers a comprehensive, BFO-aligned foundation for modeling complex urban systems within a digital twin ecosystem. By systematically representing construction processes, seismic events, transport flows, sensor deployments, and communication assets—without elevating telecommunication to an independent domain—this ontology achieves both domain coverage and conceptual clarity. Its modular design ensures that future expansions, whether for resource-management or cybersecurity perspectives, can be integrated seamlessly.

In this way, the IoDT² Ontology stands as a rigorous, semantically rich model capable of supporting real-world applications across construction analytics, earthquake resilience, and transportation optimization. Through the combined adoption of SOSA for sensor representations, GeoSPARQL for geospatial semantics, and OWL-Time for temporal structuring, the ontology fosters a multi-faceted understanding of how urban systems behave and evolve. It is precisely this holistic approach—rooted in recognized methodological standards and top-level ontologies—that positions the IoDT² Ontology as an essential backbone for next-generation digital twin solutions, enabling advanced reasoning, real-time data integration, and interoperable knowledge exchange among diverse stakeholders.