A Semantic Ontology Model Construction Approach for the Station

Abstract

Station–city integration cyberspace behaves as an interdisciplinary field of intelligent transportation and smart city, also a representative scenario in the Architecture, Engineering and Construction (AEC) sector. Due to the growing demands in data integration research, the intelligent operation and maintenance (O&M) of the station–city integration cyberspace needs to implement semantic ontology, which is suitable for semantic web construction. To achieve semantic information fusion of multi-source heterogeneous data, and clarify the decision-making role of various types of data on specific operational goals, this article proposed a framework for semantic ontology model construction, based on the deployed sensor network. Specifically, an ontology model for station–city integration cyberspace O&M was constructed, incorporating sensor data mainly from five categories, named structure, environment, crowd flow, emergency events, and energy consumption, respectively. Subsequently, the $r d f l i b$ library in Python was utilized to assign data flow to static semantic models. Furthermore, a semantic web inference engine was generated using decision rules, ultimately completing risk early warning and equipment maintenance for the sensor network. Finally, a case study was conducted for the station–city integration O&M scenario in Shenzhen North Station, and the experimental results demonstrated the applicability and effectiveness, providing robust, intelligent data support for intelligent O&M.

Keywords

Architecture,Engineering and Construction (AEC)semantic ontology station–city integration cyberspace knowledge graph intelligent operation and maintenance (O&M)

1. Introduction

In recent years, research on intelligent operation and maintenance (O&M) across various industrial scenarios has garnered significant attention, particularly in Architecture, Engineering and Construction (AEC) sectors such as manufacturing, energy, and transportation. The adoption of digital transformation in the AEC sector has grown rapidly. This kind of digital transformation involves some advanced information and communication technologies (ICT), such as digital twin, virtual reality, text mining, and block chain. The core objective is to improve operational efficiency and system reliability through data-driven technologies. For example, most intelligent O&M research focuses on equipment failure prediction, intelligent diagnostics, resource optimization, adaptive decision-making, real-time monitoring and analysis (Dinh, 2024; Montero Jimenez, 2020; van Dinter et al., 2022).

Station–city integration is one of the important research directions in the field of AEC. Its highlight is to achieve an integrated layout of transportation and urban functions, which is not merely a simple superposition of transportation facilities and urban space, but rather an optimization of resource allocation and enhancement of functional efficiency through the close integration of stations, cities, and transportation networks. Specifically, intelligent O&M in the station–city integration cyberspace involves a comprehensive evaluation of the operational status based on a developed performance evaluation index system for various O&M scenarios. As the O&M system in station–city integration cyberspace utilizes advanced information technologies, particularly the Internet of Things (IoT), big data, and artificial intelligence (AI), to enhance sensing capabilities, intelligent analysis, and decision-making support, the development of an intelligent O&M platform based on multi-source information fusion becomes essential. However, as the station–city integration cyberspace becomes increasingly complex, traditional O&M management systems face significant challenges, due to the diversity of multi-source heterogeneous sensor data, high overlapping functional O&M tasks, and so on (Chen et al., 2023; Diao, 2019; Ke et al., 2021).

To address this challenge, semantic web technologies have been progressively applied in the field of intelligent O&M. The semantic web is an extension of web technologies that allows information to be accessible to human users and, at the same time, understandable and processable by machines. By adopting standardized knowledge representation languages (such as the Resource Description Framework (RDF) and Web Ontology Language (OWL)) and reasoning mechanisms, the semantic web facilitates cross-platform and cross-domain data integration and sharing, enhancing data interoperability (Canito et al., 2022; Gouda Mohamed et al., 2024). Currently, in the AEC domain, semantic research mainly focuses on how to connect transportation data with urban information effectively, improving the intelligent decision-making capabilities of transportation hub systems during O&M processes (Shi et al., 2023; Tan et al., 2021). Notably, sensor networks integrate data collection, processing, and transmission (Duobiene et al., 2022; Li, 2022) while utilizing numerous low-power, low-cost sensor nodes for data perception, fusion, and analysis, thus providing efficient monitoring and decision support (Navabian et al., 2020). Intelligent O&M often involves various types of sensor devices, such as those for environmental monitoring and energy consumption management. Achieving cross-platform sensor data fusion remains a key challenge for sensor network technologies.

In order to achieve semantic information fusion of multi-source heterogeneous data, and clarify the decision-making role of various types of data on specific operational goals, this article proposes a framework of semantic ontology model construction for the station–city integration cyberspace. This framework involves static sensor deployment information and dynamic monitoring data within the context of station–city integration, aiming to achieve intelligent O&M processes. The goal of the constructed ontology framework is to achieve semantic fusion of heterogeneous data from multiple sources, as well as dynamic O&M management.

The main contributions of this article are as follows:

Constructing an ontology model for station–city integration cyberspace, which combines both sensor deployment information and monitoring data. This ontology model encompasses five key O&M scenarios: structure, environment, human flow, emergency events, and energy consumption. Additionally, it incorporates knowledge from various station–city integration standards and sensor manuals, referencing the real-world sensor deployment at Shenzhen North Station of China.

Presenting a dynamic reasoning method for the semantic web of the station–city integration cyberspace. This reasoning method integrates the ontology model with the knowledge graph and applies predefined rules to facilitate risk warnings and the maintenance of sensor networks within the station–city integration cyberspace.

The remainder of this article is organized as follows: Section 2 reviews related research on the semantic frameworks for intelligent O&M. Section 3 presents the methodology of the semantic ontology architecture for sensor network-based intelligent O&M, and Section 4 provides a detailed description of the process of constructing the semantic model. Section 5 evaluates the proposed semantic framework in terms of ontology consistency and model validity. Finally, Section 6 concludes the article and presents potential future directions.

2. Related Work

To leverage the semantic web for implementing the intelligent O&M architecture of sensor networks, an essential element is the construction of a semantic ontology for sensor networks. This section provides an overview of the research progress on the ontology concept within the context of intelligent O&M.

In the context of AI, an ontology is a formal, explicit specification of a shared conceptualization, taking the form of a set of classes, relationships, and axiomatic constraints. ‘‘Formal” refers to the fact that it must be machine-readable. ‘‘Explicit” means that the type of concepts used and the constraints on their use are explicit. ‘‘Shared” describes consensual knowledge that is accepted by a group (Gruber, 1995).

In recent years, research on ontologies has expanded into multiple domains, with significant advancements in the field of smart cities (De Nicola & Villani, 2021). These advancements cover a wide range of dimensions, including communities (Periñán Pascual, 2023), risk management (Cui et al., 2023), eLearning (Tsoutsa et al., 2022), energy (Sayah et al., 2021), environment (Xu et al., 2022), sustainable development (Santos et al., 2023), and urban planning (Sobral et al., 2021). Several public resources for smart city ontologies have been released, such as Smart City Ontology (https://urenio.org/smart-city-ontology/) and Smart City Ontology Standards (https://iec.ch/basecamp/ontology-standards-smart-cities). These studies aim to effectively integrate data from diverse sources and achieve intelligent management. Against this backdrop, with the help of sensor network technology, many ontologies have been developed and successfully applied in scenarios such as data integration, knowledge sharing, and intelligent decision-making (Chen et al., 2020). These ontologies can effectively integrate data from different sources and achieve intelligent management in various fields. Table 1 lists the semantic models highly relevant to this article along with their basic information, including names, knowledge sources, and reused ontologies. Based on these studies, existing ontology applications can be divided into two categories according to their research focus, application scenarios and system architecture: intelligent environments and activity recognition, as well as sensor data integration and intelligent decision support.

Table 1.
Ontologies Related to Sensor Nnetworks.

Name Acronym Data Source Reuse Ontology Language

Ontology of the Fire Weather Index (Chandra et al., 2022) _ Environment sensors monitoring data SSN OWL; SWRL; SPARQL

Urban District Sustainability Assessment ontology (Kuster et al., 2020) UDSA Smart meters, survey or statistical datasets SSN; DUL; QUDT; GeoSPARQL OWL; SPARQL

Connected Traffic Data Ontology (Viktorovic et al., 2020) CTDO Vehicle Remote Sensing Data; Basic Safety Message (BSM); VSS taxonomy SOSA RDF; SPARQL

The smashHitCore Ontology (Kurteva et al., 2023) smashHitCore Vehicle Sensor Data GConsent; DPV; OntoSensor OWL

Probabilistic and Ontological Activity Recognition in Smart-Homes (Civitarese et al., 2021) POLARIS ADLs sensors monitoring data COSAR OWL 2 DL

Multimedia Semantic Sensor Network Ontology (Angsuchotmetee et al., 2020; Cardinale et al., 2022) MSSN-Onto Mobile sensors; mobile sensors monitoring data SSN; SOSA OWL; Python

Bridge Structure and Health Monitoring Ontology (Li et al., 2021) BSHM Bridge structural data; bridge health monitoring data SSN; SOSA; QUDT OWL; SWRL; SPARQL

Subway construction safety checking ontology (Li et al., 2022) SCO Structural health,environmental, personnel monitoring equipment monitoring data _ OWL; SPARQL

The Business Process Ontology (Diamantini et al., 2023) BPO Sensors monitoring data SOSA; DogOnt; KPIOnto;event ontology OWL; SPARQL

Industrial production workflow ontologies (Yang et al., 2023) InPro Industrial sensors monitoring data BFO OWL; SPARQL

An ontology model of environmental pollutants monitoring indicator (Xu et al., 2022) _ Environment sensors monitoring data _ OWL; Jena custom rules

Indoor Space Ontology (Guo et al., 2021) _ Smartphone sensors monitoring data _ OWL

a lightweight ontology of SensorThings API, the indoorgmllite ontology, cgis ontology (Huang et al., 2022) STA-Lite; IndoorGML-Lite; cgis OGC SensorThings API; IndoorGML; CityGML SSN; SOSA; BOT OWL; RDF; SPARQL

CIM ontology (Shi et al., 2023) ontoCIM BIM data; GIS data; IoT data Brick; SSN OWL; SPARQL

Name	Acronym	Data Source	Reuse Ontology	Language
Ontology of the Fire Weather Index (Chandra et al., 2022)	_	Environment sensors monitoring data	SSN	OWL; SWRL; SPARQL
Urban District Sustainability Assessment ontology (Kuster et al., 2020)	UDSA	Smart meters, survey or statistical datasets	SSN; DUL; QUDT; GeoSPARQL	OWL; SPARQL
Connected Traffic Data Ontology (Viktorovic et al., 2020)	CTDO	Vehicle Remote Sensing Data; Basic Safety Message (BSM); VSS taxonomy	SOSA	RDF; SPARQL
The smashHitCore Ontology (Kurteva et al., 2023)	smashHitCore	Vehicle Sensor Data	GConsent; DPV; OntoSensor	OWL
Probabilistic and Ontological Activity Recognition in Smart-Homes (Civitarese et al., 2021)	POLARIS	ADLs sensors monitoring data	COSAR	OWL 2 DL
Multimedia Semantic Sensor Network Ontology (Angsuchotmetee et al., 2020; Cardinale et al., 2022)	MSSN-Onto	Mobile sensors; mobile sensors monitoring data	SSN; SOSA	OWL; Python
Bridge Structure and Health Monitoring Ontology (Li et al., 2021)	BSHM	Bridge structural data; bridge health monitoring data	SSN; SOSA; QUDT	OWL; SWRL; SPARQL
Subway construction safety checking ontology (Li et al., 2022)	SCO	Structural health,environmental, personnel monitoring equipment monitoring data	_	OWL; SPARQL
The Business Process Ontology (Diamantini et al., 2023)	BPO	Sensors monitoring data	SOSA; DogOnt; KPIOnto;event ontology	OWL; SPARQL
Industrial production workflow ontologies (Yang et al., 2023)	InPro	Industrial sensors monitoring data	BFO	OWL; SPARQL
An ontology model of environmental pollutants monitoring indicator (Xu et al., 2022)	_	Environment sensors monitoring data	_	OWL; Jena custom rules
Indoor Space Ontology (Guo et al., 2021)	_	Smartphone sensors monitoring data	_	OWL
a lightweight ontology of SensorThings API, the indoorgmllite ontology, cgis ontology (Huang et al., 2022)	STA-Lite; IndoorGML-Lite; cgis	OGC SensorThings API; IndoorGML; CityGML	SSN; SOSA; BOT	OWL; RDF; SPARQL
CIM ontology (Shi et al., 2023)	ontoCIM	BIM data; GIS data; IoT data	Brick; SSN	OWL; SPARQL

2.1. Intelligent Environments and Activity Recognition

Research on ontology applications in intelligent environments and activity recognition focuses on perceiving the environment and recognizing activities through various sensors and intelligent technologies. For instance, as the recognition of complex daily activities (ADLs) in smart homes was increasingly applied to disease diagnosis, leading to the development of POLARIS (Civitarese et al., 2021), which uses unsupervised segmentation algorithms. However, the data sources for POLARIS’s ontology construction are limited to sensor monitoring information, which is relatively narrow. Similarly, an indoor knowledge graph framework has been developed, which combines smartphone sensor data (such as inertial sensors, WiFi strength, and magnetic field strength) with indoor spatial information to achieve precise and efficient pedestrian positioning in indoor environments (Guo et al., 2021). Although the ontology constructed in this study integrates multi-source information, it does not mention the main ontological backbone, which is crucial for ontology interoperability.

In the domain of smart buildings, with the evolution of multimedia sensor network (MSN) technology, M²SSN-Onto (Cardinale et al., 2022) offers an integrated solution by merging multimedia and mobile sensor data based on the MSSN-Onto framework (Angsuchotmetee et al., 2020), to meet the detection needs of emergency events within smart buildings. Additionally, in the application of construction safety, a novel environmental pollutant identification mechanism has been proposed. This approach utilizes association rule mining and ontology reasoning to combine sensor data with multidisciplinary knowledge, enabling real-time monitoring and intelligent identification of pollutants at construction sites (Xu et al., 2022). Meanwhile, SCO (Li et al., 2022) integrates multi-source safety risk factors with textual rule knowledge, with a focus on enhancing safety during subway construction. However, these ontologies, which are modeled around specific areas within the smart building domain, are not openly accessible, thereby impeding their extensive evaluation and reuse by smart building practitioners.

2.2. Sensor Data Integration and Intelligent Decision Support

Research on the application of ontologies in data integration and intelligent decision-making primarily focuses on sensor networks. These methods emphasize the integration of multi-source sensor data through ontology models, offering intelligent decision support and optimized management across diverse domains. For instance, a decision support system for forest fire management was developed, which relies on a semantic sensor network ontology. This system integrates meteorological data and sensor information to prevent and control various types and stages of fires (Chandra et al., 2022). However, the credibility of the proposed ontology’s structure is significantly undermined due to the lack of evaluation. In the context of Industry 4.0, a novel approach was proposed that links sensor data with process activities during data generation, leading to the creation of a process-aware industrial IoT knowledge graph. This graph bridges the gap between raw sensor data and higher-level knowledge within organizations (Diamantini et al., 2023). Although the study provides a detailed description of the ontology’s structure, it fails to adequately justify the selection of entities, thereby weakening the persuasiveness of the ontology design. Meanwhile, to fully represent industrial production workflows, InPro (Yang et al., 2023) described sensor monitoring data by sharing and reusing domain knowledge, achieving conceptualization and formalization of production processes. However, InPro has not been publicly released.

In urban transportation, the Connected Traffic Data Ontology (CTDO) (Viktorovic et al., 2020) improved the spatial structure of existing domain ontologies, enhancing the query efficiency of semi-autonomous vehicle sensor platforms. Within urban management, a knowledge modeling and heterogeneous sensor data integration method for a bridge health monitoring system was proposed. Based on ontology, this method enables fine-grained semantic modeling of bridge structures, sensors, and their observation attributes (Li et al., 2021). Additionally, the Urban District Sustainability Assessment (UDSA) ontology (Kuster et al., 2020) integrated existing urban sustainability assessment frameworks and domain ontologies, addressing data heterogeneity and information exchange issues through semantic web technology. Compared to CTDO, the ontology designs of the bridge health ontology and UDSA are more transparent and rational, yet neither is openly accessible. SmashHitCore (Kurteva et al., 2023) provides a comprehensive model for GDPR-compliant data sharing and processing, with a particular focus on consent and contract compliance for vehicle sensor data, thereby facilitating legal data exchange and management for smart city services. Although the use of SPARQL queries for evaluation was proposed, the details and results of these queries were not explicitly presented. With the development of smart cities, cross-domain resource integration has gradually become a research hotspot. One approach integrates urban models and open standards of the Internet of Things (such as SensorThings API, IndoorGML, and CityGML), which supports various smart city applications (Huang et al., 2022). Furthermore, the construction of a City Information Model (CIM) through the integration of BIM, GIS, and IoT data provides a systematic framework for data integration, contributing to the development of digital twin cities (Shi et al., 2023). However, the modeling of these ontologies typically focuses on BIM-GIS aspects, with relatively simplistic ontology designs for IoT, failing to fully capture the complexity and diversity of IoT.

2.3. Summary of Related Work

In summary, the existing general research methods for ontology modeling are achieved by adhering to a series of standards set by the World Wide Web Consortium (W3C), aimed at ensuring the interoperability of ontologies between different systems, enhancing maintainability and providing consistency and connectivity for applications. These standards include RDF, OWL, SPARQL, and Semantic Web Rule Language (SWRL). Ontology modeling based on specific application scenarios involves the following three aspects:

(1) Application scenarios: At present, in the context of smart cities, ontology research targeting specific operational scenarios aims to achieve certain objectives, such as bridge safety and construction risks. However, daily O&M for the station–city integration involves complex tasks that encompass structures, environments, and passenger flows, among others. Therefore, it is necessary to establish a comprehensive ontology that meets the daily O&M needs of the station–city integration management.

(2) Data sources: Existing research on ontology models for sensor networks has primarily focused on the analysis of sensor monitoring data, while limited attention has been given to other ontological attributes, such as the correlation between the physical layout, sensor configuration deployment, and operational outcomes. Such information is critical for the efficient O&M of complex urban integrated systems.

(3) Ontology reuse: Most existing ontology models are based on relevant general-domain ontologies, enabling ontology modeling in specific fields through the reuse and inheritance mechanisms of foundational models, such as the Basic Formal Ontology (BFO) for real-world entities, the DOLCE+DnS Ultralite (DUL) ontology for human activities, the Build-Operate-Transfer (BOT) ontology for building information, and the semantic sensor network (SSN) ontology and sensor, observation, sample, and actuator (SOSA) ontology for sensor networks.

3. Methodology

The station–city integration cyberspace involves a complex structure with a large number of sensors, which generate data that exhibit multi-source heterogeneous characteristics. Therefore, to systematically present the intelligent O&M framework of the network space, it is necessary to construct the corresponding maintenance framework at the granularity of the ontology. The maintenance ontology framework for sensor data in the station–city integration cyberspace proposed in this article is shown in Figure 1. Specifically, this framework centers around the operational process of the sensor network system. It generates the ontology model and maintenance framework for sensor data through two core steps: ontology construction from static information and dynamic information-driven knowledge graph.

Ontology Construction From Static Information: In the long-term operation of sensor networks, the collection and management of static information are crucial for the stability and reliability of the system. Generally, in the field of ‘‘integrated station–city,” static information refers to the fixed attributes or configuration parameters of sensors, which typically remain unchanged after the deployment of the sensors. Considering the consistency and interoperability of the ontology, this article adjusts and extends the existing SSN ontology and SOSA ontology (Haller et al., 2018; Janowicz et al., 2019) based on the important concepts and attributes of static information.

Dynamic Information-Driven Knowledge Graph: Once the ontology constructed from static information is initially completed, it is necessary to extend the generated static ontology with dynamic information. ‘‘Dynamic information” refers to the monitoring data collected by sensors during the daily O&M of the integrated urban transportation system. Therefore, the ontology framework for intelligent O&M proposed in this article must utilize dynamic information to extend the static ontology, thereby generating a knowledge graph that supports decision-making for intelligent O&M.

Figure 1.

Sensor semantic model construction framework for the station–city integration cyberspace.

3.1. Ontology Specification

The specification phase aims to clearly define the scope and objectives of the ontology, and identify the intended users and requirements for the ontology. In this section, the article demonstrates the specification of the OMSC-Onto ontology through the following points:

Goal, domains, and scopes: This ontology is designed to represent concepts related to daily monitoring and management within sensor networks, supporting data integration and comprehensive operations for various scenarios in integrated station cities (such as structure, environment, passenger flow, events, and energy consumption). Specifically, by defining and categorizing observation properties, it provides a standardized data structure that allows data from different sensors to be uniformly managed and analyzed. Additionally, by defining various types of sensors (e.g. air quality sensors, temperature sensors, structural sensors, etc.) and corresponding observations (e.g. passenger flow, energy consumption, environmental conditions, etc.), the ontology model supports the construction of a comprehensive monitoring system for real-time surveillance of the environment and infrastructure of integrated station cities.

Use and users requirements: The construction of this ontology can provide an integrated data management and analysis platform for various users, including city managers, planners, emergency response teams, maintenance personnel, and data analysts. This enables them to make decisions based on real-time monitoring data, optimize resource allocation, enhance response efficiency, and formulate policies, thereby improving the overall level of urban operational intelligence and the quality of life for residents.

Competency questions (CQs): The objectives, application domains, and scope of the ontology serve as the basis for constructing CQs standards. The formulation of CQs aids in clarifying the specific requirements of the ontology and guides its development process (Keet & Khan, 2024; Yang et al., 2023). This process transforms requirements into question forms to assess the ontology’s capability to answer these questions. Table 2 lists a set of core CQs, focusing on the content and outcomes of sensor observations, with the aim of identifying and eliminating redundant concepts in ontology construction.

3.2. Knowledge Acquisition and Conceptualization

To enhance the intelligent management level of urban infrastructure and transportation systems, and to achieve real-time monitoring of stations and their surrounding environments as well as the daily maintenance of sensor network systems, this article focuses on the operation of sensor networks in the context of the station–city integration at Shenzhen North Station of China. It extracts knowledge from both the static deployment information and dynamic monitoring data of sensors to construct and enrich the semantic model.

Table 2.
List of Core Competency Questions (CQs).

Question Subjet Property Object

Which sensor make observation X? Sensor madeObservation Observation

Which sensors are used to observe ObservableProperty X? Sensor observes ObservableProperty

Which sensor is located in Location X? Sensor locatedIn Location

Which sensors have abnormal status X? Sensor hasAbnormalStatus AbnormalStatus

What is the sensor status of Sensor X? Sensor sensorStatus String

What is the last maintenance time for Sensor X? Sensor lastMaintenanceTime DateTime

What is the maintenance cycle for Sensor X? Sensor maintenanceCycle Float

Which observations are made by Sensor X? Observation madeBySensor Sensor

Which observations are observed for ObservableProperty X? Observation observedProperty ObservableProperty

Which observations have FeatureOfInterest X? Observation haveFeatureOfInterest FeatureOfInterest

Which observations are associated with Alarm X? Observation hasProblemOf Alarm

What is the simple result of Observation X? Observation hasSimpleResult String

What is the result time of Observation X? Observation resultTime DateTime

What is the value unit for Observation X? Observation valueUnit String

Which features of interest have ObservableProperty X? FeatureOfInterest hasProperty ObservableProperty

Which alarm is detected by Observation X? Alarm detectedByObservation Observation

Question	Subjet	Property	Object
Which sensor make observation X?	Sensor	madeObservation	Observation
Which sensors are used to observe ObservableProperty X?	Sensor	observes	ObservableProperty
Which sensor is located in Location X?	Sensor	locatedIn	Location
Which sensors have abnormal status X?	Sensor	hasAbnormalStatus	AbnormalStatus
What is the sensor status of Sensor X?	Sensor	sensorStatus	String
What is the last maintenance time for Sensor X?	Sensor	lastMaintenanceTime	DateTime
What is the maintenance cycle for Sensor X?	Sensor	maintenanceCycle	Float
Which observations are made by Sensor X?	Observation	madeBySensor	Sensor
Which observations are observed for ObservableProperty X?	Observation	observedProperty	ObservableProperty
Which observations have FeatureOfInterest X?	Observation	haveFeatureOfInterest	FeatureOfInterest
Which observations are associated with Alarm X?	Observation	hasProblemOf	Alarm
What is the simple result of Observation X?	Observation	hasSimpleResult	String
What is the result time of Observation X?	Observation	resultTime	DateTime
What is the value unit for Observation X?	Observation	valueUnit	String
Which features of interest have ObservableProperty X?	FeatureOfInterest	hasProperty	ObservableProperty
Which alarm is detected by Observation X?	Alarm	detectedByObservation	Observation

3.2.1. Static Deployment Information of Sensors

According to the Railway Passenger Station Integration Development Planning and Design Guidelines (T/CSOTE, 2024), sensor groups are deployed in different functional areas based on the classification of station–city functions. Each group selects appropriate sensors based on the key parameters specified in the Integrated Engineering Planning and Design Standards (DB11/T 2129-2023), involving a total of 14 types across five categories of sensors. The static information of the sensors denotes the ontological attributes fixed at deployment and invariant over the sensor’s lifetime, modifiable only during scheduled maintenance. As shown in Table 9 of Appendix A.1, it encompasses sensor type, measurand, indicator class, transduction principle, range, accuracy, resolution and spatial location, providing the persistent identity required for data interpretation, calibration and asset management in integrated station–city monitoring systems.

3.2.2. Dynamic Monitoring Information of Sensors

Dynamic sensor information refers to the time-stamped occurrent data streams continuously emitted after deployment. Accumulated as $⟨ timestamp, value, quality flag ⟩$ triplets at every sampling instant, these sequences capture the temporal evolution of measurands and thereby reflect the real-time operational state of the station–city integration system. Depending on the monitoring content, these real-time data can be categorized into five main types: structural data, environmental data, crowd flow data, event data, and energy consumption data. Specifically, structural data primarily pertains to the health status of structures; environmental data encompasses variations in environmental parameters such as temperature, humidity, air quality, and noise, as well as emergencies like fires and floods; crowd flow and incident data are used to capture the movement, density, and behavioral patterns of individuals within the area; energy consumption data relates to the energy usage of various facilities and equipment. Table 3 outlines the general characteristics of the data. The sensors collect this data in real-time and upload it, which is then processed locally for noise suppression and format standardization before being stored in a database.

Table 3.
Dynamic Monitoring Information of Sensors.

Type Data Stream Data Type Resolution

Structure Displacement, stress, strain, triple-axial tilt angle, XYZ velocity, acceleration, angular velocity, crack opening displacement, and leaking water Number Per minute

Flame temperature, smoke concentration, noise decibels, water flow velocity, depth, temperature, and humidity Number Per second

Environment PM2.5 concentration, PM10 concentration, and CO2 concentration Number Per 90 s

Fire source location and harmful gas components String Per second

CrowdFlow Individual speed, population density, pedestrian flow direction, crowd flow rate, total population in the area, high passenger flow, and queue size Audio & Image & Number Per minute

Event Running and falling Audio & Image Per minute

EnergyConsumption Pipe temperature, power, voltage, electric current, and electrical energy Number Per minute

Type	Data Stream	Data Type	Resolution
Structure	Displacement, stress, strain, triple-axial tilt angle, XYZ velocity, acceleration, angular velocity, crack opening displacement, and leaking water	Number	Per minute
	Flame temperature, smoke concentration, noise decibels, water flow velocity, depth, temperature, and humidity	Number	Per second
Environment	PM2.5 concentration, PM10 concentration, and CO2 concentration	Number	Per 90 s
	Fire source location and harmful gas components	String	Per second
CrowdFlow	Individual speed, population density, pedestrian flow direction, crowd flow rate, total population in the area, high passenger flow, and queue size	Audio & Image & Number	Per minute
Event	Running and falling	Audio & Image	Per minute
EnergyConsumption	Pipe temperature, power, voltage, electric current, and electrical energy	Number	Per minute

3.3. Implementation

The purpose of ontology implementation is to transform the ontology model into a machine-readable model using ontology representation languages. OWL 2 (Web Ontology Language 2) is a language recommended by the W3C (World Wide Web Consortium) for representing ontologies on the Web. It is an extended version of OWL, offering richer expressiveness and more efficient reasoning support. To construct an OWL 2-based ontology model, this paper uses the Protégé ontology management system to model, edit, and reason. A classical approach in the ontology modeling methods is the Stanford Seven-Step Method (Noy & McGuinness, 2002). This method belongs to manual ontology modeling methods and consists of seven steps: (1) determine the domain and scope of the ontology; (2) consider reusing existing ontologies; (3) list important terms; (4) define classes and class hierarchies; (5) define properties of classes; (6) define classifications of properties; and (7) create instances. This method has been widely applied in various fields (Ancione et al., 2024; Guyo et al., 2023; Xi et al., 2023). Specifically, this article utilizes the rdflib library in Python to develop an application that batch-converts CSV table data into instances based on predefined classes and properties, and maps them into RDF format.

RDF is a semantic network model based on triples, consisting of ‘‘subject-predicate-object,” which is used to represent relationships between different resources (Ma et al., 2023). This approach allows sensor data to be standardized into structured semantic data, facilitating data interoperability and reasoning across systems and domains. The converted RDF files, as a form of interrelated graph representation, are stored in GraphDB to form a knowledge graph. GraphDB is a graph database developed by Ontotext, built on RDF standards, and supports semantic data storage and querying, making it suitable for handling large-scale graph data and complex relational data. It has been widely applied in fields such as knowledge graphs, the semantic web, data integration, and recommendation systems (Ancione et al., 2024).

Once the dynamic data storage is completed, it is essential to effectively associate relevant entities and data related to risk warning in the ontology with predefined reasoning rules, thereby extending the existing knowledge graph. This process not only enhances the semantic expressiveness of the knowledge graph but also further improves the risk warning functionality within the graph, providing a more precise informational foundation for subsequent data analysis and decision support. In the context of semantic web reasoning rules, SPARQL (SPARQL Protocol and RDF Query Language) combines efficient data querying capabilities, allowing for flexible expansion on large-scale RDF datasets, thereby better supporting cross-platform compatibility and seamless integration with ontologies and rule engines. Consequently, the knowledge required to identify risk conditions is represented in the form of SPARQL rules.

3.4. Evaluation

Ontology evaluation aids in identifying potential issues, enhancing the accuracy and consistency of knowledge representation, and facilitating knowledge sharing and reuse. Evaluation methods encompass formal validation approaches, such as leveraging description logic reasoning to detect ontology consistency and completeness; structural assessment methods that focus on the complexity, coverage, and modularity of the ontology; and application-based effectiveness evaluation, which measures the ontology’s performance through practical use cases.

In this study, the criteria for evaluating OMSC-Onto are consistency, coverage, and adaptability. To maintain consistency, the HermiT reasoner in Protégé is employed for automatic consistency checks. To ensure coverage, responses to CQs are conducted. Adaptability is verified through application-based methods using a real-world scenario, where SPARQL queries are formulated to retrieve relevant information on sensor observations.

4. Semantic Fusion Framework for Sensor Data

4.1. Ontology Development for Smart O&M in Station–City Integration Cyberspace

This section provides a detailed description of the proposed OMSC-Onto ontology, including the core logical model representing knowledge of sensor network O&M, as well as the specifics of the OMSC-Onto modules.

The semantic web for intelligent O&M of the station–city integration at Shenzhen North Station collects and organizes static information through sensors, utilizing the general terminology for sensors (GB/T 7665-2005) to extract concepts closely related to intelligent operation and maintenance. This process ultimately identifies the types of sensors, their deployment locations, measurement parameters, and monitoring targets as the main entities of this research.

Based on this foundation, the semantic web for intelligent O&M is systematically constructed using a top-down design. Specifically, the first step involves defining the categories of the system based on the extracted core concepts, which provides a clear framework structure for model construction. Next, for each category, the attributes of each object and their related data properties are further clarified to ensure the comprehensiveness and accuracy of the model. The defined model is then semantically aligned with existing domain ontologies, namely SSN and SOSA. Based on the alignment results, classes and properties in SSN and SOSA are filtered, adjusted, and expanded. The final ontology structure is shown in Figure 2.

Figure 2.

Classes (yellow) and properties (blue) of OMSC-Onto.

Table 4 illustrates the core ontology model of OMSC-Onto, which is built upon the SSN (Semantic Sensor Network) ontology model. Mapping the ontology to a high-level abstract framework ensures that the terminology used in the model is comprehensible to end-users and explicit to ontology developers. Given that the DOLCE UltraLite ontology (DUL) is the core dependency of the previous version of SSN and that corresponding alignments already exist (https://www.w3.org/TR/vocab-ssn/), OMSC-Onto leverages DUL as its upper ontology. Specifically, the following alignments are made: sosa:Observation, which denotes the act of executing an observation procedure to estimate or compute a value of a FeatureOfInterest, is aligned with dul:Event. sosa:ObservableProperty, existing as a property dependent on an entity, is aligned with dul:Quality. sosa:Sensor, the entity that carries out the observation, is aligned with dul:Object. sosa:FeatureOfInterest, the thing whose property is estimated or calculated during observation, is treated as a joint subclass of dul:Event, dul:Object, and dul:InformationEntity. In this work, it is specialized into three categories: architectural structures, spatial areas, and equipment. Architectural structures and equipment are further categorized as dul:PhysicalArtifact under dul:Object, while spatial areas are categorized as dul:PhysicalPlace under dul:Object. Consequently, FeatureOfInterest is aligned with dul:Object to more accurately reflect its classification and attributes. MR:Location, representing the deployment site of a sensor, is aligned with dul:PhysicalPlace. MR:Alarm and MR:AbnormalStatus, representing distinct alarm states, are aligned with dul:Situation (Stavropoulos et al., 2021). The following sections will detail the specific information of these modules.

Table 4.

The Alignments With DUL Ontology.

OMSC-Onto Classes	Relation	DUL Classes
sosa:Sensor	subclass of	dul:Object
sosa:Observation	subclass of	dul:Event
sosa:ObservableProperty	subclass of	dul:Quality
sosa:FeatureOfInterest	subclass of	dul:Objec
MR:Alarm	subclass of	dul:Situation
MR:Abnormal Status	subclass of	dul:Situation
MR:Location	subclass of	dul:PhysicalPlace

– Observation: Feature 10 of Appendix A.2 illustrates the Observation class, which acts as the hub of the model representing sensor observation records. It includes five types: CrowdFlowObservation, EnergyConsumptionObservation, EnvironmentalObservation, EventObservation, and StructuralObservation. The relationships with other entities are constrained by the axiom:

\begin{aligned} O b s e r v a t i o n ⊑ (= 1 m a d e B y S e n s o r . S e n s o r) \\ ⊓ (= 1 o b s e r v e d P r o p e r t y . O b s e r v a b l e P r o p e r t y) \\ ⊓ (= 1 h a s F e a t u r e O f I n t e r e s t . F e a t u r e O f I n t e r e s t) \\ ⊔ (= 1 h a s P r o b l e m O f . A l a r m) \end{aligned}

This indicates that each Observation instance must be generated by a sensor, observe an observable property, and focus on a feature of interest, but it does not necessarily have to be associated with an alarm, except under certain conditions where it would be related to exactly one alarm.

– Sensor: Figure 10 of Appendix A.2 also illustrates the Sensor class, which is used to describe general information about all sensors in the context of intelligent O&M for station–city integration, such as name, type, and operational status. The Sensor class is composed of five types: CrowdFlowSensors, EnergyConsumptionSensors, EnvironmentalSensors, EventSensors, and StructuralSensors. The relational constraints with other entities are expressed as follows:

\begin{aligned} S e n s o r ⊑ (\geq 1 m a d e O b s e r v a t i o n . O b s e r v a t i o n) \\ ⊓ (\geq 1 o b s e r v e s . O b s e r v a b l e P r o p e r t y) \\ ⊓ (= 1 l o c a t e d I n . L o c a t i o n) \\ ⊔ (\geq 1 h a s A b n o r m a l S t a t u s . A b n o r m a l S t a t u s) \end{aligned}

This axiom indicates that each Sensor instance must generate at least one observation, observe at least one observable property, and be located in a specific location, while it may also have at least one abnormal status (although an abnormal status is not mandatory; it is associated only under certain conditions).

– ObservableProperty: The hierarchical division of the ObservableProperty class aligns with that of the $O b s e r v a t i o n$ class, indicating a one-to-one correspondence, representing the attributes that are observed.

– FeatureOfInterest: The FeatureOfInterest is the thing whose property is being estimated or calculated in the course of an observation to arrive at a result. As shown in Figure 11 in Appendix A.2, the FOI class in our ontology is specialized into AreaFOI, EquipmentFOI, and StructureFOI.

(a) AreaFOI is observed by CrowdFlowSensors, EnvironmentalSensors and EventSensors; for example, an air quality sensor measuring the CO concentration of the waiting hall.

(b) EquipmentFOI is monitored by EnergyConsumptionSensors; for example, a wireless meter recording the power of an air conditioning unit.

(c) StructureFOI is assessed by StructuralSensors; for example, a digital crack meter tracking the crack opening displacement of a Pillar.

The relational constraints of FeatureOfInterest with other entities are expressed as follows:

\begin{aligned} F e a t u r e O f I n t e r e s t ⊑ \\ (\geq 1 h a s P r o p e r t y . O b s e r v a b l e P r o p e r t y) \end{aligned}

This indicates that an instance of an FeatureOfInterest is associated with at least one observable property.

– Alarm: Figure 11 of Appendix A.2 also illustrates the hierarchical structure of the Alarm class, which is used to record various types of sensor alarm, providing a theoretical basis for subsequent knowledge reasoning and decision-making. Similarly, it is categorized into five types based on operational scenarios. The relational constraints with other entities are expressed as follows:

\begin{aligned} A l a r m ⊑ \\ (\geq 1 d e t e c t e d B y O b s e r v a t i o n . O b s e r v a t i o n) \end{aligned}

This axiom shows that an instance of an Alarm must be associated with at least one observation.

– AbnormalStatus: The AbnormalStatus class denotes the abnormal conditions of sensors, as shown in Figure 2, encompassing two scenarios: sensor failure and maintenance overdue.

– Location: The Location defines the specific deployment location of the sensors.

Additionally, the storage of inherent sensor attributes (such as range and resolution) can be divided into two categories:

(a) Different sensors have different focus attributes. For example, an ultrasonic level gauge measuring water depth emphasizes accuracy, range, and resolution, while a machine vision sensor measuring pedestrian flow direction focuses on recognition type, installation height, and recognition time;

(b) For the same type of sensor, the attribute values may change when measuring different parameters. For instance, the resolution of an AI ToF people-counting sensor is $0.1 {people / m}^{2}$ when measuring density, while it is 1 person when measuring large crowds.

Since these attributes are only for display purposes in this article and are intended for reference in daily management without computation or comparison, this type of information is represented using class annotation properties, as shown in Figure 3. For case (b), a $p a r a m e t e r_a t t r i b u t e$ approach is used for differentiation.

Figure 3.

A case study of annotation property representation.

4.2. Ontology-Based Knowledge Representation for Operation and Maintenance

4.2.1. SPARQL-Based Smart Operation and Maintenance Rules

The objective of the proposed framework is to detect relevant issues. To achieve risk management for the integration of stations and cities, this section defines the O&M rules for the semantic web of station–city integration based on the SPARQL query language, as shown in Table 5. These rules are categorized into five types, which are used to determine the upper and lower limits of risk control, thereby enabling the identification of potential risk scenarios. These rules include, but are not limited to, the occurrence of various abnormal events, the operational status of the sensor network, and maintenance conditions. By monitoring and managing these rules, we can proactively identify potential risk points, thus ensuring the operational safety of the station–city integration cyberspace.

Table 5.
Operation and Maintenance Rules for the Semantic Web of Station–City Integration.

ID Type Variables Rule Alarm

1 Environment Flame temperatureand smoke concentration $Flame temperature > 200^{\circ} C \lor Smoke concentration > 0.1 %$ Fire warning

2 Noise decibels $Noise decibels > 85 dB(A)$ Noise warning

3 Water flow velocity and depth $Water flow velocity > 2 m/s \lor depth > 10 cm$ Flood warning

4 Temperature $Temperature > 28^{\circ} C \lor Temperature < 12^{\circ} C$ Abnormal temperature

5 Humidity $Humidity > 80 % \lor Humidity < 30 %$ Abnormal humidity

6 PM2.5 concentration, PM10 concentration,and CO2 concentration $PM2.5 concentration > 75 {μ g / m}^{3} \lor PM10 concentration > 150 {μ g / m}^{3} \lor CO2 concentration > 1000 ppm$ Air quality warning

7 Structure Displacement $Displacement > 10 mm$ Structural displacement

8 Stress $Stress > 10 %$ Structural overload

9 Strain $Strain > 0.005 %$ Structural deformation

10 Triaxial inclination $Triaxial inclination > {0.3}^{\circ}$ Structural tilt

11 XY velocity, acceleration, and angular velocity $XY velocity > 5 mm/s \lor acceleration > 0.5 {m/s}^{2} \lor angular velocity > {0.2}^{\circ} / s$ Abnormal vibrations

12 Crack opening displacement $Crack opening displacement > 0.2 mm$ Abnormal cracks in the structure

13 Water leakage $Water leakage > 5 %$ Structural corrosion

14 Energy consumption Pipe temperature $Pipe temperature > 70^{\circ} C$ Abnormal energy consumption

15 Crowd flow Total population in the area $Total population in the area > 300 person$ Large crowd flow

16 Sensor Sensor status Sensor status == “off“ Not working

17 Last maintenance time and result time $float(Result time -- Last maintenance time) > Maintenance cycle$ Maintenance overdue

ID	Type	Variables	Rule	Alarm
1	Environment	Flame temperatureand smoke concentration	$Flame temperature > 200^{\circ} C \lor Smoke concentration > 0.1 %$	Fire warning
2		Noise decibels	$Noise decibels > 85 dB(A)$	Noise warning
3		Water flow velocity and depth	$Water flow velocity > 2 m/s \lor depth > 10 cm$	Flood warning
4		Temperature	$Temperature > 28^{\circ} C \lor Temperature < 12^{\circ} C$	Abnormal temperature
5		Humidity	$Humidity > 80 % \lor Humidity < 30 %$	Abnormal humidity
6		PM2.5 concentration, PM10 concentration,and CO2 concentration	$PM2.5 concentration > 75 {μ g / m}^{3} \lor PM10 concentration > 150 {μ g / m}^{3} \lor CO2 concentration > 1000 ppm$	Air quality warning
7	Structure	Displacement	$Displacement > 10 mm$	Structural displacement
8		Stress	$Stress > 10 %$	Structural overload
9		Strain	$Strain > 0.005 %$	Structural deformation
10		Triaxial inclination	$Triaxial inclination > {0.3}^{\circ}$	Structural tilt
11		XY velocity, acceleration, and angular velocity	$XY velocity > 5 mm/s \lor acceleration > 0.5 {m/s}^{2} \lor angular velocity > {0.2}^{\circ} / s$	Abnormal vibrations
12		Crack opening displacement	$Crack opening displacement > 0.2 mm$	Abnormal cracks in the structure
13		Water leakage	$Water leakage > 5 %$	Structural corrosion
14	Energy consumption	Pipe temperature	$Pipe temperature > 70^{\circ} C$	Abnormal energy consumption
15	Crowd flow	Total population in the area	$Total population in the area > 300 person$	Large crowd flow
16	Sensor	Sensor status	Sensor status == “off“	Not working
17		Last maintenance time and result time	$float(Result time -- Last maintenance time) > Maintenance cycle$	Maintenance overdue

In the semantic web environment, the rules in Table 5 can be expressed and executed using the SPARQL query language. SPARQL is a query language designed explicitly for querying RDF data models, allowing for efficient retrieval of relevant information from knowledge graphs. In practical applications, SPARQL not only supports standard selection queries but also enables complex construction queries to generate new RDF triples and expand existing data structures (Giannios et al., 2024). Therefore, utilizing the SPARQL query language to automate the execution of these rules and risk detection can significantly enhance efficiency and reduce the need for manual intervention.

Specifically, we utilize the management web application GraphDB Workbench interface provided by GraphDB to design and execute a series of SPARQL CONSTRUCT queries to generate and derive relevant graph patterns. These graph patterns can represent problem scenarios through RDF triples, further enriching and expanding the existing knowledge graph. For example, when executing queries, the system can identify potential nodes, relationships, and events related to risks in real-time, forming a complete chain of risk scenarios and storing this information in the graph for subsequent analysis and decision-making.

Figure 4 illustrates an example of the SPARQL rule structure, which is responsible for extracting problematic situations during the operation of the sensor network. The Prefix section declares two namespaces, with xsd used to reference XML Schema data types, such as $x s d : d a t e T i m e$ , while MR points to a custom ontology. The CONSTRUCT section defines the structure of the resulting graph. In this context, the query constructs a triple: ( $s e n s o r, h a s A b n o r m a l S t a t u s, a b n o r m a l s t a t u s$ ). The WHERE section primarily filters the data source that meets the conditions through three steps: matching, binding, and filtering.

Figure 4.

Rule structure.

4.2.2. Dynamic Data Extraction and Transformation Model

To achieve intelligent O&M, the sensor monitoring data in the station–city integration cyberspace needs to be first integrated with the corresponding sensor information. Based on the RDF mapping principles illustrated in Figure 5, this article develops an application using the $r d f l i b$ library in Python, which is widely used in the semantic web domain for creating, parsing, querying, and manipulating RDF data. Through this program, the integrated data is converted into RDF format, resulting in ontology instances, with each instance corresponding to the relevant column attributes in the table. The resulting RDF resources are stored in GraphDB to form a knowledge graph. In this process, the RDF format provides a standardized semantic expression method, facilitating the description and organization of relevant information about monitoring data, including equipment status, environmental parameters, and operational metrics. After data conversion and ontology instance generation, SPARQL query language can be utilized, combined with custom rules, to efficiently retrieve, analyze, and validate the data. These rules can assist in detecting potential equipment failures and abnormal trends or optimizing O&M strategies, thereby providing data-driven decision support for intelligent O&M.

Figure 5.

Principles of resource description framework (RDF) mapping.

5. Experimental Evaluation

To verify the correctness and applicability of the semantic network model for the station–city integration cyberspace proposed in this article, this section conducts an ontology consistency evaluation and a model validity evaluation of the constructed semantic network model.

5.1. Automated Consistency Checking

Ontology consistency typically refers to the state in which all concepts, relationships, rules, and their semantic and logical structures within an ontology remain consistent and conflict-free (Yang et al., 2023). HermiT is an efficient OWL 2 DL reasoner used for reasoning and verification of descriptive logic ontologies (Glimm et al., 2014). Disjointness axioms are essential for enabling non-trivial entailments and detecting inconsistencies (Völker et al., 2015). Therefore, to obtain a non-trivial result, we explicitly introduced 27 class-disjointness axioms (Table 10 in Appendix A.3) based on (i) the inherent mutual exclusivity arising from metrological and sensor-physics principles and (ii) the mandatory distinctions defined in international standards such as ISO/OGC and urban-rail-transport industry specifications. These axioms capture the semantic mutual exclusiveness among OMSC-Onto classes. After integrating these potentially conflicting constraints, the debug function of Protégé5.5, using HermiT 1.4.3, confirmed that OMSC-Onto remains logically consistent.

5.2. Answering CQs

Referencing a set of CQs provided in Table 2, this study designed a targeted set of CQs (see Table 6) to conduct application-based evaluation using the SPARQL query language. The purpose of this evaluation is to verify the performance of the OMSC-Onto ontology in practical applications, particularly its capability to retrieve precise information to answer specific query requirements. The query results indicate that the OMSC-Onto ontology can effectively retrieve accurate information to meet the designed CQs.

Table 6.
Specified Competency Questions (CQs) and Answers Based on the Passenger Flow Case.

Specified CQs Answers

1. What is the sensor of the observation obser_1? HJ001

2. What is the observable property of the observation obser_1? TotalPopulationInTheArea

3. What is the feature of interest of the observation obser_1? TransferCorridor

4. What is the result value of the observation obser_1? ”16”

5. What is the result time of the observation obser_1? ”2012-04-09T06:05:00”ˆˆxsd:dateTime

6. What is the value unit of the observation obser_1? ”person”

7. What is the location of the sensor HJ001? Location_HJ001

8. What is the status of the sensor HJ001? ”working”

9. What is the last maintenance time of the sensor HJ001? 2011-10-25T08:30:00ˆˆxsd:dateTime

10. What is the maintenance cycle of the sensor HJ001? ”180”

Specified CQs	Answers
1. What is the sensor of the observation obser_1?	HJ001
2. What is the observable property of the observation obser_1?	TotalPopulationInTheArea
3. What is the feature of interest of the observation obser_1?	TransferCorridor
4. What is the result value of the observation obser_1?	”16”
5. What is the result time of the observation obser_1?	”2012-04-09T06:05:00”ˆˆxsd:dateTime
6. What is the value unit of the observation obser_1?	”person”
7. What is the location of the sensor HJ001?	Location_HJ001
8. What is the status of the sensor HJ001?	”working”
9. What is the last maintenance time of the sensor HJ001?	2011-10-25T08:30:00ˆˆxsd:dateTime
10. What is the maintenance cycle of the sensor HJ001?	”180”

5.3. Application-Based Evaluation

Due to the typically large volume of data in real-life scenarios, this study selected the entry passenger flow records (Wang et al., 2017) from the Zhujiang Road subway station between April 9 and May 6, 2012, to validate the model’s effectiveness on a large-scale dataset. The dataset includes sensor information (sensor type, maintenance cycle, and last maintenance time) as well as passenger flow data. Among them, the passenger flow data comprises a total of 5,712 observations over 28 days, with the Labor Day holiday occurring from April 29 (Sunday) to May 1 (Tuesday), while April 28 (Saturday) is considered a working day. Figure 6 illustrates the general trend of this dataset.

Figure 6.

Original data of inbound transaction records at Zhujiang Road subway station from April 9 to May 6, 2012.

Firstly, based on the static information of the sensor, an ontology is constructed to formally represent various entities related to sensors and their interrelationships. Subsequently, the developed application utilizes this ontology model to transform real-time passenger flow data into specific instances, saved in RDF format and stored in a GraphDB for subsequent querying and analysis. Figure 7 illustrates the transformation process from the ontology layer to the instance layer. At the ontology layer, core concepts such as Sensor, Observation, FeatureOfInterest, and their related subclasses pertinent to this scenario are defined. The transformed instance layer then concretely embodies the application of these concepts in actual data, including specific instances of passenger flow observations, such as observation times, values, and associated sensor information.

Figure 7.

Ontology mapping process of the passenger flow case.

After processing the data using the methods described in this study, the results were stored in GraphDB, and corresponding queries and reasoning were conducted based on this data. To evaluate the capability of the ontology in answering questions, this study designed a series of CQs targeting the key areas of Observation and Sensor, along with their corresponding expected answers (see Table 6). Table 7 illustrates two example queries devised to address the CQs listed in Table 6. The final query results are presented in Figure 8. By comparing the query results with the expected answers, it is evident that the ontology is highly effective for dynamic passenger flow monitoring.

Figure 8.

Querying information for Competency Questions (CQs) 1–10.

Figure 9.

A knowledge graph for large passenger flow alarms (part).

Figure 10.

The class hierarchy structure of observation and sensor.

Figure 11.

The class hierarchy structure of alarm and FeatureOfInterest.

Table 7.

SPARQL Statements for Competency Questions (CQs) 1–10.

#CQ 1–6

SELECT ?Sensor ?ObservableProperty ?FeatureOfInterest ?resultValue

?resultTime ?valueUnit

WHERE {

?observation a mr:Observation ;

mr:id ”obser_1” ;

mr:madeBySensor ?Sensor ;

mr:observedProperty ?ObservableProperty ;

mr:hasFeatureOfInterest ?FeatureOfInterest ;

mr:hasSimpleResult ?resultValue ;

mr:resultTime ?resultTime ;

mr:valueUnit ?valueUnit .

}

#CQ 7–10

SELECT ?Location ?status ?lastMaintenanceTime

?maintenanceCycle

WHERE {

?sensor a mr:Sensor ;

mr:id ”HJ001” ;

mr:locatedIn ?location ;

mr:sensorStatus ?status ;

mr:lastMaintenanceTime ?lastMaintenanceTime ;

mr:maintenanceCycle ?maintenanceCycle .

}

For the passenger flow data, the main focus of the reasoning included the identification of large passenger flows and the maintenance of the sensor network system (rules 15 and 17 in Table 5). Table 8 illustrates a series of queries and reasoning processes executed on the entry passenger flow records. In query (a), a total of 5,712 records of the observation type were identified, which is consistent with the number of observations in the original data, indicating that no data loss or damage occurred throughout the data processing workflow. In reasoning (b), it was identified that 595 records of passenger flow data exceeded the set threshold, with these records typically appearing during peak hours (i.e. 17:00–19:00), providing a basis for further analysis of large passenger flow phenomena. Figure 9 displays the visualized graph of these warning records. In reasoning (c), the system also detected 3,030 records that triggered maintenance alarms, indicating potential issues within the sensor network. These unexpected records first appeared on April 22, 2012, suggesting that inspections or maintenance of the relevant sensors or equipment may be necessary.

Table 8.

SPARQL Statements for Alarm and AbnormalStatus.

(a)

SELECT ?entity WHERE {

?entity rdf:type MR:Observation .

}

(b)

CONSTRUCT {

?observation MR:hasProblemOf ?alarm .

?alarm MR:detectedByObservation ?observation .

}

WHERE {

?observation a MR:Observation ;

MR:hasSimpleResult ?result_value .

?alarm a MR:LargeCrowdFlowWarning .

BIND (xsd:float(?result_value) AS ?value)

FILTER (?value 300) }

(c)

CONSTRUCT {

?sensor MR:hasAbnormalStatus ?abnormalstatus .

}

WHERE { ?observation a MR:Observation ;

MR:timedif ?time_diff .

?sensor a MR:Sensor ;

MR:maintenanceCycle ?maintanence_cycle .

?abnormalstatus a MR:MaintenanceOverdue .

BIND (?maintanence_cycle 86400 AS ?maintanence_cycle_seconds)

FILTER (?time_diff ?maintanence_cycle_seconds)

}

Through these queries and reasoning, the proposed framework demonstrates its capability to accurately identify large passenger flow events and proactively predict and alert potential system failures or maintenance needs, thereby providing robust support for the system’s stable operation.

6. Conclusions and Future Work

The research on intelligent O&M in the station–city integration cyberspace is an intersection of intelligent transportation and smart city domains, addressing the semantic fusion of multi-source heterogeneous data. It encompasses risk analysis and decision-making, as well as the maintenance and management of sensor network systems. Currently, the unstructured and heterogeneous nature of data within sensor networks hinders knowledge sharing and semantic interoperability among various stakeholders and communities, making it challenging to establish mechanisms for data communication and utilization. This situation, in turn, complicates the identification of safety risks in the context of integrated station–city intelligent O&M. Therefore, constructing a semantic web model for the integrated station–city sensor network is essential.

This article develops a semantic model for sensor networks within the station–city integration cyberspace, aimed at achieving intelligent O&M of sensor networks based on a ‘‘data-ontology-maintenance” framework with data feedback characteristics. The main innovation lies in the proposed framework, which integrated various semantic web technologies (i.e. ontology, RDF, and SPARQL) to process five categories of sensor data—structure, environment, crowd flow, event, and energy consumption—across static and dynamic states, converting them into a unified RDF semantic representation format, thereby forming a knowledge graph for sensor intelligent O&M. Within the constructed sensor semantic web framework, potential risk identification during the integrated O&M process was achieved by applying predefined rules and the operational knowledge graph. To validate this framework, a comprehensive evaluation method for the ontology consistency and model validity of the constructed sensor semantic web was conducted. On the one hand, the consistency of the ontology was verified using the HermiT plugin provided by Protégé, ensuring that the defined concepts, classes, and attributes are logically conflict-free. On the other hand, the validity of the semantic web’s dynamic reasoning rules was validated using subway sensor data. This dual-layer evaluation standard significantly demonstrated the broad application prospects of the framework.

It is noteworthy that the proposed framework encompasses the primary risks encountered in the daily O&M processes of the integrated station–city, meeting general risk identification requirements. However, there are still some limitations in the specific implementation process that can be addressed in future research. First, this study primarily focuses on the identification of various risks; supplementary work regarding emergency response measures following risk identification will be conducted in the future. Second, the risk identification of abnormal behaviors such as running and falling cannot be determined by the rules presented in this article and requires further investigation in conjunction with deep learning methods, such as convolutional neural networks. Additionally, the rules in this article are based on manually extracted data; future work will involve the development of a rule extraction engine utilizing large language models.

Footnotes

Acknowledegments

This research was funded by the National Key Research and Development Program of China (Grant No. 2023YFC3807501). The authors gratefully acknowledge this support.

ORCID iDs

Xiaolin Pan

Huan Fang

Author Contributions

XP and HF: conceptualization; XP: methodology; XP: software; XP: validation; XP: formal analysis; XP: investigation; HF: resources; XP: data curation; XP: writing–original draft preparation; XP and HF: writing–review and editing; XP: visualization; HF: supervision; XP: project administration; HF: funding acquisition. All authors have read and agreed to the published version of the manuscript.

Funding

The author(s) disclosed receipt of the following financial support for the research, authorship, and/or publication of this article: This research was funded by the National Key Research and Development Program of China (Grant No. 2023YFC3807501).

Declaration of Conflicting Interests

The author(s) declared no potential conflicts of interest with respect to the research, authorship, and/or publication of this article.

Data Availability Statement

The data presented in this study are available on request from the corresponding author. The OMSC-Onto ontology can be found at https://llamla.github.io/station-city-integration/ontology/omsco, and the code is available at .

A.1 Static Deployment Information of Sensors

Table 9.

Static Deployment Information of Sensors.

	Measurement	Indicator	Sensor	Measured
Type	Parameter	Type	Technology	Parameters	Location
Structure	Stress	Quantitative	Strain gauge (resistive)	Accuracy: $\pm$ 0.2% Range: 0–20,000 $μ ε$ Resolution: Micrometric	Pillars and connection nodes at the station hall and platform layer
		Quantitative	Piezoelectric	Accuracy: $\pm$ 1% Range: 10,000 N Resolution: Millinewton
	Strain	Quantitative	Resistive straingauge	Accuracy: $\pm$ 1% Range: 0–50,000 $μ ε$ Resolution: Micrometric
		Quantitative	Fiber optic	Accuracy: $\pm$ 1% Range: 0–10,000 $μ ε$ Resolution: Micrometric
	Displacement	Quantitative $+$ Qualitative	Resistive	Accuracy: Micrometric Range: 0–50 mm Resolution: Micrometric
		Quantitative $+$ Qualitative	Fiber optic	Accuracy: Micrometric Range: 0–50 mm Resolution: Micrometric
	Vibration (Angular velocity) (XYZ velocity) (Acceleration)	Quantitative	Accelerometer	Accuracy: $\pm$ 0.5% Range: 0–50 g Resolution: Microg or smaller
		Quantitative	Piezoelectric sensor	Accuracy: $\pm$ 0.5% Range: 0–5000 g Resolution: Microg or smaller
		Quantitative	Fiber optic	Accuracy: $\pm$ 0.5% Range: 0–5000 $μ ε$ Resolution: Micrometric
	Water leakage	Quantitative	Vertical graphenesensor	–
	Tilt angle	Quantitative	MEMS tilt sensor	Accuracy: $\pm$ 0.1– $\pm$ 0.5Range: $\pm$ 15– $\pm$ 90Resolution: 0.01–0.1
	Crack	Quantitative	Digitalcrack gauge andphotogrammetry	Accuracy: Millimeter level Range: 0–50 mm Resolution: 100 pixels
Environment	Air quality	Quantitative	Optical sensor	Accuracy: $\pm$ 5% Range: 0–1000 $μ$ g/m³ Resolution: 1 $μ$ g/m³	Around the station hall and resting areas of passengers
		Quantitative	Electronic sensor	Accuracy: $\pm$ 2% Range: 0–5000 $μ$ g/m³ Resolution: 1 $μ$ g/m³
		Quantitative	Laser sensor	Accuracy: $\pm$ 10% Range: 0–1000 $μ$ g/m³ Resolution: 1 $μ$ g/m³
	Temperature	Quantitative	Thermocouplesensor	Accuracy: $\pm$ 0.5C Range: –200C–1600C Resolution: 0.01C
		Quantitative	RTD (resistivetemperaturedetector)	Accuracy: $\pm$ 0.1C Range: $-$ 200C +850C Resolution: 0.01C
		Quantitative	Infraredtemperature sensor	Accuracy: $\pm$ 0.1C Range: $-$ 50C–3000C Resolution: 0.01C
	Humidity	Quantitative	Lithium chloridehumidity sensor	Accuracy: $\pm$ 2% RH Range: 10% RH to 95% RH Resolution: 0.1% RH
	Noise level	Quantitative	Thermal noisesensor	Accuracy: $\pm$ 3 dB Range: 40–130 dB Resolution: 1 dB
	Flametemperature	Quantitative	Infraredthermographiccamera	Accuracy: $\pm$ 2C or $\pm$ 2% Range: $-$ 20C–650C Resolution: 0.03C–0.1C	Waiting hall and transfer corridor
	Fire sourcelocation	Quantitative	Infraredthermographiccamera	Accuracy: $\pm$ 2C or $\pm$ 2% Range: $-$ 20C–650C Resolution: 0.03C to 0.1C
	Smokeconcentration	Quantitative	Smoke sensor	Accuracy: $\pm$ 5%– $\pm$ 15% Range: 0–1000 ppm Resolution: 1 ppm or 0.1 mg/m³
	Hazardous gascomponents	Quantitative	Electrochemicalsensor	Accuracy: $\pm$ 2% to $\pm$ 5% Range: 1–1000 ppm Resolution: 1 ppm or smaller
	Water flow speed	Quantitative	Ultrasonic flowspeed sensor	Accuracy: $\pm$ 0.1 m/s Range: 0.03–12 m/s Resolution: 0.01 m/s or smaller	Taxi pick-up area and ride-hailing pick-up area
	Water depth	Quantitative	Ultrasonic liquidlevel meter	Accuracy: 0.5%–1% Range: 0.3–30 m Resolution: 3 mm
Energy consumption	Voltage	Quantitative	Hall voltage sensor	Accuracy: $\pm$ 0.2% Range: 2 mV–5000 V Resolution: 1 mV	Air conditioning units and pump units
	Current
	Power
	Energy
	Water flow	Quantitative	Water flow sensor	Accuracy: $\pm$ 0.2% Range: Flow in thousands of cubic meters per hour $-$ 100 KPa–60 MPa Resolution: 0.1%
Crowd flow	Passenger flow	Quantitative	AI ToF peoplecounting sensor	Accuracy: $\pm$ 0.2% Resolution: 1 person	Station hall entrances and exit areas, and external distribution areas
		Quantitative	Machine vision	Accuracy: $\pm$ 5% Installationheight: 5 m Recognition time: 25 fps
	Density	Quantitative	AI ToF peoplecounting sensor	Accuracy: $\pm$ 0.2% Resolution: 0.1 person/m²
		Quantitative	Machine vision	Accuracy: $\pm$ 5% Installationheight: 5 m Recognition time: 25 fps
	Queue Number	Quantitative	AI ToF peoplecounting sensor	Accuracy: $\pm$ 0.2% Resolution: 1 person
		Quantitative	Machine vision	Accuracy: $\pm$ 5% Installationheight: 5 m Recognition time: 25 fps
	Trajectory	Quantitative $+$ Qualitative	AI ToF peoplecounting sensor	Accuracy: $\pm$ 0.2% Resolution: 1 person
		Quantitative + Qualitative	Machine vision	Accuracy: $\pm$ 5% Installationheight: 5 m Recognition time: 25 fps
	Speed	Quantitative	AI ToF peoplecounting sensor	Accuracy: $\pm$ 0.2% Resolution: 0.1 person/m²
		Quantitative	Machine vision	Accuracy: $\pm$ 5% Installationheight: 5 m Recognition time: 25 fps
	Direction	Quantitative $+$ Qualitative	AI ToF peoplecounting sensor	Bidirectional recognition
		Quantitative + Qualitative	Machine vision	Bidirectional recognition installation height: 5 m Recognition time: 25 fps
	Large passenger flow	Quantitative	AI ToF peoplecounting sensor	Accuracy: $\pm$ 0.2% Resolution: 1 person
		Quantitative	Machine vision	Accuracy: $\pm$ 5% Installationheight: 5 m Recognition time: 25 fps
Event	Fall	Quantitative	Panoramic camera	Resolution: 8K (7,680 x 4,320 pixels) Range: 360
	Running	Quantitative	Panoramic camera	Resolution: 8K (7,680 x 4,320 pixels) Range: 360

A.2 The Class Hierarchy Structure

Feature 10 shows the class hierarchy structure of observation and sensor. Feature shows the class hierarchy structure of alarm and FeatureOfInterest.

A.3 The Class Disjointness Axioms

Table 10.

The Class Disjointness Axioms.

ID	Axioms
1	DisjointClasses: AbnormalStatus, Alarm, FeatureOfInterest, Location, ObservableProperty, Observation, Sensor
2	DisjointClasses: CrowdFlowObservation, EnergyConsumptionObservation, EnvironmentalObservation, EventObservation, StructuralObservation
3	DisjointClasses: CrowdFlowProperty, EnergyConsumptionProperty, EnvironmentalProperty, EventProperty, StructuralProperty
4	DisiointClasses: CrowdFlowSensors, EnergyConsumptionSensors, EnvironmentalSensors, EventSensors, StructuralSensors
5	DisjointClasses: CrowdFlowWarning, EnergyConsumptionWarning, EnvironmentalWarning, EventWarning, StructuralWarning
6	DisjointClasses: AreaFOI, EquipmentFOI, StructureFOI
7	DisjointClasses: AccelerationMonitoring, AngularVelocityMonitoring, CrackOpeningDisplacementMonitoring, DisplacementMonitoring, StrainMonitoring, StressMonitoring, TripleAxialTiltAngleMonitoring, WaterleakageMonitoring, XYZVelocityMonitoring
8	DisjointClasses: CO2Monitoring, FireSourceLocationMonitoring, FlameTemperatureMonitoring, HarmfulGasComponentsMonitoring, HumidityMonitoring, NoiseMonitoring, PM10Monitoring, PM2.5Monitoring, SmokeConcentrationMonitoring, TemperatureMonitoring, WaterDepthMonitoring, WaterflowVelocityMonitoring
9	DisjointClasses: CrowdFlowDirectionMonitoring, CrowdFlowRateMonitoring, IndividualSpeedMonitoring, PersonnelDensityMonitoring, QueueSizeMonitoring, TotalPopulationinTheAreaMonitoring
10	DisjointClasses: CurrentMonitoring, ElectricEnergyMonitoring, PipeTemperatureMonitoring, PowerMonitoring, VoltageMonitoring
11	FallingMonitoring DisjointWith RunningMonitoring
12	DisjointClasses: Acceleration, Angular Velocity, CrackOpeningDisplacement, Displacement, strain, stress, TripleAxialTiltAngle, WaterLeakage, XYZVelocity
13	DisiointClasses: CO2concentration, FireSourceLocation, FlameTemperature, HarmfulGasComponents, Humidity, NoiseDecibels, PM10Concentration, PM2.5Concentration, SmokeConcentration, Temperature, WaterDepth, WaterFlowVelocity
14	DisjointClasses: CrowdFlowDirection, CrowdflowRate, IndividualSpeed, PersonnelDensity, QueueSize, TotalPopulationinTheArea
15	DisjointClasses: Current, ElectricEnergy, PipeTemperature, Power, Voltage
16	Falling Disiointwith Running
17	DisjointClasses: DigitalCrackMeter, InclinationGauge, LowPowerDisplacementSensor, LowPowerStrain sensor, LowPowerStressSensor, UprightGrapheneSensor, VibrationSensor
18	DisjointClasses: AirQualitySensor, HarmfulGasDetector, NoiseSensor, smokeSensor, TemperatureAndHumditysensor, ThermalImagingCamera, UltrasonicFlowRatesensor, UltrasonicLevelGauge
19	MachineVisionSensor DisjointWith PeopleCountingSensor
20	DisjointClasses: MatchingCurrentTransformer, TemperatureSensor, WirelessMeteringMeter
21	DisjointClasses: AbnormalCrack, AbnormalVibration, StructuralCorrosion, StructuralDeformation, StructuralDisplacement, StructuralOverload, StructuralTilt
22	DisjointClasses: AbnormalHumidity, AbnormalNoise, AbnormalTemperature, AirQualityWarning, FireWarning, FloodWarning
23	FallingEvent DisjointVith RunningEvent
24	DisjointClasses: PlatformLevel, StationConcourseLevel, stationForecourt, TransferCorridor, WaitingHall
25	DisjointClasses: AirConditioningUnit, DistributionBox, PumpAssembly
26	DisjointClasses: CanopyColumn, ConnectionNode, GlassFacadeCable, Pillar, StructuralColumn, Truss
27	MaintenanceOverdue DisjointWith NotWorking

References

Ancione

Ansaldi

S. M.

Bragatto

Agnello

Milazzo

M. F.

(2024). An ontological approach increasing the knowledge about equipment ageing including the effects of current transitions. Journal of Loss Prevention in the Process Industries, 92, 105453. https://doi.org/10.1016/j.jlp.2024.105453

Angsuchotmetee

Chbeir

Cardinale

(2020). MSSN-onto: An ontology-based approach for flexible event processing in multimedia sensor networks. Future Generation Computer Systems, 114, 1140–1158. https://doi.org/10.1016/j.future.2018.01.044

Canito

Corchado

Marreiros

(2022). A systematic review on time-constrained ontology evolution in predictive maintenance. Artificial Intelligence Review, 55(4), 3183–3211. https://doi.org/10.1007/s10462-021-10079-z

Cardinale

Freites

Valderrama

Aguilera

Angsuchotmetee

(2022). Semantic framework of event detection in emergency situations for smart buildings. Digital Communications and Networks, 8(1), 64–79. https://doi.org/10.1016/j.dcan.2021.06.005

Chandra

Agarwal

Singh

(2022). Semantic sensor network ontology-based decision support system for forest fire management. Ecological Informatics, 72, 101821. https://doi.org/10.1016/j.ecoinf.2022.101821

Chen

Jiang

Wang

Tang

(2020). Modeling and reasoning of iot architecture in semantic ontology dimension. Computer Communications, 153, 580–594. https://doi.org/10.1016/j.comcom.2020.02.006

Chen

Yan

Fan

(2023). Elements of the core area transport system oriented to station–city integration. Computers and Electrical Engineering, 110, 108842. https://doi.org/10.1016/j.compeleceng.2023.108842

Civitarese

Sztyler

Riboni

Bettini

Stuckenschmidt

(2021). Polaris: Probabilistic and ontological activity recognition in smart-homes. IEEE Transactions on Knowledge and Data Engineering, 33(1), 209–223. https://doi.org/10.1109/TKDE.2019.2930050

Cui

Zhang

Zhao

(2023). An ontology-based probabilistic framework for comprehensive seismic risk evaluation of subway stations by combining Monte Carlo simulation. Tunnelling and Underground Space Technology, 135, 105055. https://doi.org/10.1016/j.tust.2023.105055

10.

De Nicola

Villani

M. L.

(2021). Smart city ontologies and their applications: A systematic literature review. Sustainability, 13(10), 5778. https://doi.org/10.3390/su13105578

11.

Diamantini

Mircoli

Potena

Storti

(2023). Process-aware iiot knowledge graph: A semantic model for industrial IoT integration and analytics. Future Generation Computer Systems, 139, 224–238. https://doi.org/10.1016/j.future.2022.10.003

12.

Diao

(2019). Towards sustainable urban transport in Singapore: Policy instruments and mobility trends. Transport Policy, 81, 320–330. https://doi.org/10.1016/j.tranpol.2018.05.005

13.

Dinh

D. H.

Hoang

V. T.

N. T.

Bang

T. Q.

(2024). A predictive maintenance policy for manufacturing systems considering degradation of health monitoring device. Reliability Engineering & System Safety, 248, 110177. https://doi.org/10.1016/j.ress.2024.110177

14.

Duobiene

Ratautas

Trusovas

Ragulis

Šlekas

Simniškis

Raciukaitis

(2022). Development of wireless sensor network for environment monitoring and its implementation using sail technology. Sensors, 22(14), 5343. https://doi.org/10.3390/s22145343

15.

Giannios

Mpaltadoros

Alepopoulos

Grammatikopoulou

Stavropoulos

T. G.

Nikolopoulos

Lazarou

Tsolaki

Kompatsiaris

(2024). A semantic framework to detect problems in activities of daily living monitored through smart home sensors. Sensors, 24(4), 1107. https://doi.org/10.3390/s24041107

16.

Glimm

Horrocks

Motik

Stoilos

Wang

(2014). Hermit: An owl 2 reasoner. Journal of Automated Reasoning, 53, 245–269.

17.

Gouda Mohamed

Ghaly

J. E.

Marzouk

(2024). Revolutionizing semantic integration of maintenance cost prediction for building systems using artificial neural networks. Journal of Building Engineering, 96, 110416. https://doi.org/10.1016/j.jobe.2024.110416

18.

Gruber

T. R.

(1995). Toward principles for the design of ontologies used for knowledge sharing?International Journal of Human-Computer Studies, 43(5-6), 907–928. https://doi.org/10.1006/ijhc.1995.1081

19.

Guo

Niu

Wang

Pun

M. O.

Yang

(2021). An indoor knowledge graph framework for efficient pedestrian localization. IEEE Sensors Journal, 21(4), 5151–5163. https://doi.org/10.1109/JSEN.2020.3029098

20.

Guyo

E. D.

Hartmann

Snyders

(2023). An ontology to represent firefighters data requirements during building fire emergencies. Advanced Engineering Informatics, 56, 101992. https://doi.org/10.1016/j.aei.2023.101992

21.

Haller

Janowicz

Cox

Lefrançois

Taylor

Phuoc

Lieberman

García Castro

Atkinson

Stadler

(2018). The modular SSN ontology: A joint W3C and OGC standard specifying the semantics of sensors, observations, sampling, and actuation. Semantic Web, 10(1), 9–32. https://doi.org/10.3233/sw-180320

22.

Huang

C. Y.

Chiang

Y. H.

Tsai

(2022). An ontology integrating the open standards of city models and internet of things for smart-city applications. IEEE Internet of Things Journal, 9(20), 20444–20457. https://doi.org/10.1109/JIOT.2022.3178903

23.

Janowicz

Haller

Cox

S. J. D.

Le Phuoc

Lefrancois

(2019). Sosa: A lightweight ontology for sensors, observations, samples, and actuators. Journal of Web Semantics, 56, 1–10. https://doi.org/10.1016/j.websem.2018.06.003

24.

Furuya

Luo

(2021). Case comparison of typical transit-oriented-development stations in Tokyo district in the context of sustainability: Spatial visualization analysis based on fahp and gis. Sustainable Cities and Society, 68, 102788. https://doi.org/10.1016/j.scs.2021.102788

25.

Keet

C. M.

Khan

Z. C.

(2024). Discerning and characterising types of competency questions for ontologies. https://arxiv.org/abs/2412.13688.

26.

Kurteva

Chhetri

T. R.

Tauqeer

Hilscher

Fensel

Nagorny

Correia

Zilverberg

Schestakov

Funke

Demidova

(2023). The smashhitcore ontology for gdpr-compliant sensor data sharing in smart cities. Sensors, 23(13), 6188. https://doi.org/10.3390/s23136188

27.

Kuster

Hippolyte

J. L.

Rezgui

(2020). The UDSA ontology: An ontology to support real-time urban sustainability assessment. Advances in Engineering Software, 140, 102731. https://doi.org/10.1016/j.advengsoft.2019.102731

28.

(2022). Application of artificial intelligence system based on wireless sensor network in enterprise management. Computational Intelligence and Neuroscience, 2022, 2169521. https://doi.org/10.1155/2022/2169521

29.

Yang

Jiang

Liu

(2021). Ontologies-based domain knowledge modeling and heterogeneous sensor data integration for bridge health monitoring systems. IEEE Transactions on Industrial Informatics, 17(1), 321–332. https://doi.org/10.1109/TII.2020.2967561

30.

Yang

Yuan

Donkers

Liu

(2022). Bim-enabled semantic web for automated safety checks in subway construction. Automation in Construction, 141, 104454. https://doi.org/10.1016/j.autcon.2022.104454

31.

Z. M.

Yan

(2023). Rdf(s) store in object-relational databases. Journal of Database Management, 35(1), 1–32.

32.

Montero Jimenez

J. J.

Schwartz

Vingerhoeds

Grabot

Salaün

(2020). Towards multi-model approaches to predictive maintenance: A systematic literature survey on diagnostics and prognostics. Journal of Manufacturing Systems, 56, 539–557. https://doi.org/10.1016/j.jmsy.2020.07.008

33.

Navabian

Beskhyroun

Matulich

(2020). Development of wireless smart sensor network for vibration-based structural health monitoring of civil structures. Structure and Infrastructure Engineering, 18(3), 345–361. https://doi.org/10.1080/15732479.2020.1850801

34.

Noy

N. F.

McGuinness

D. L.

(2002). Ontology development 101: A guide to creating your first ontology. Technical report, Stanford Knowledge Systems Laboratory. http://protege.stanford.edu/publications/ontology_development/ontology101.html.

35.

Periñán Pascual

(2023). From smart city to smart society: A quality-of-life ontological model for problem detection from user-generated content. Applied Ontology, 18(3), 263–306. https://doi.org/10.3233/AO-230281

36.

Santos

Eggly

Gutierrez

Chesñevar

C. I.

(2023). Extending the IoT-stream model with a taxonomy for sensors in sustainable smart cities. Sustainability, 15(8), 6594. https://doi.org/10.3390/su15086594

37.

Sayah

Kazar

Lejdel

Laouid

Ghenabzia

(2021). An intelligent system for energy management in smart cities based on big data and ontology. Smart and Sustainable Built Environment, 10(2), 169–192. https://doi.org/10.1108/SASBE-07-2019-0087

38.

Shi

Pan

Jiang

Zhai

(2023). An ontology-based methodology to establish city information model of digital twin city by merging bim, gis, and iot. Advanced Engineering Informatics, 57, 102114. https://doi.org/10.1016/j.aei.2023.102114

39.

Sobral

Galvão

Borges

(2021). Knowledge-assisted visualization of multi-level origin-destination flows using ontologies. IEEE Transactions on Intelligent Transportation Systems, 22(4), 2168–2177. https://doi.org/10.1109/TITS.2021.3056228

40.

Stavropoulos

T. G.

Meditskos

Lazarou

Mpaltadoros

Papagiannopoulos

Tsolaki

Kompatsiaris

(2021). Detection of health-related events and behaviours from wearable sensor lifestyle data using symbolic intelligence: A proof-of-concept application in the care of multiple sclerosis. Sensors, 21(18), 6230. https://doi.org/10.3390/s21186230

41.

Tan

Qiu

Guo

(2021). Research on the construction of a knowledge graph and knowledge reasoning model in the field of urban traffic. Sustainability, 13, 3191. https://doi.org/10.3390/su13063191

42.

Tsoutsa

Fitsilis

Iatrellis

(2022). Towards an ontology for smart city competences. In Proceedings of the 25th Pan-Hellenic conference on informatics, PCI ’21, (pp. 254–259). New York, NY, USA: association for computing machinery. ISBN 9781450395557. https://doi.org/10.1145/3503823.3503871.

43.

van Dinter

Tekinerdogan

Catal

(2022). Predictive maintenance using digital twins: A systematic literature review. Information and Software Technology, 151, 107008. https://doi.org/10.1016/j.infsof.2022.107008

44.

Viktorovic

Yang

Vries

(2020). Connected traffic data ontology (CTDO) for intelligent urban traffic systems focused on connected (semi) autonomous vehicles. Sensors, 20(10), 2961. https://doi.org/10.3390/s20102961

45.

Völker

Fleischhacker

Stuckenschmidt

(2015). Automatic acquisition of class disjointness. Journal of Web Semantics, 35, 124–139. https://doi.org/10.1016/j.websem.2015.07.001

46.

Wang

Zhang

Shi

(2017). Forecasting of short-term metro ridership with support vector machine online model. Journal of Advanced Transportation, 2018(1), 3189238. https://doi.org/10.1155/2018/3189238

47.

(2023). Design and construction of lightweight domain ontology of tectonic geomorphology. Journal of Earth Sciences, 34(6), 1350–1357. https://doi.org/10.1007/s12583-022-1779-x

48.

Huo

Pang

(2022). Identification of environmental pollutants in construction site monitoring using association rule mining and ontology-based reasoning. Buildings, 12(12), 2111. https://doi.org/10.3390/buildings12122111

49.

Yang

Zheng

Ala-Laurinaho

Autiosalo

Seppänen

Tammi

(2023). Ontology-based knowledge representation of industrial production workflow. Advanced Engineering Informatics, 58, 102185. https://doi.org/10.1016/j.aei.2023.102185

A Semantic Ontology Model Construction Approach for the Station–City Integration Cyberspace

Abstract

Keywords

1. Introduction

2. Related Work

2.2. Sensor Data Integration and Intelligent Decision Support

2.3. Summary of Related Work

3. Methodology

3.2. Knowledge Acquisition and Conceptualization

3.2.2. Dynamic Monitoring Information of Sensors

3.4. Evaluation

4. Semantic Fusion Framework for Sensor Data

4.1. Ontology Development for Smart O&M in Station–City Integration Cyberspace

4.2.1. SPARQL-Based Smart Operation and Maintenance Rules

5.1. Automated Consistency Checking

5.2. Answering CQs

Footnotes

Acknowledegments

ORCID iDs

Author Contributions

Funding

Declaration of Conflicting Interests

Data Availability Statement

A.1 Static Deployment Information of Sensors

A.2 The Class Hierarchy Structure

A.3 The Class Disjointness Axioms

References