Multi-source data federated query method and system for power equipment operation and maintenance ontology semantics

Abstract

The application discloses a kind of power equipment operation and maintenance ontology-oriented multi-source data federation query method and system, by constructing multi-source heterogeneous data source access adaptation mechanism, unified registration and abstraction are carried out to database and API, and metadata ledger is established;The semantic mapping between the operation and maintenance field ontology model and the heterogeneous data source is constructed;Receiving user query request and parsing into uniform intermediate representation, and then rewriting and splitting into local subquery for different data sources;According to the cost model, a federation execution plan is generated, the scheduling optimization and parallel / serial execution of the subquery are realized;The semantic fusion, conflict resolution and standardization processing of multi-source return result are carried out, and the uniform format result set is output;The system also supports query task monitoring, log management and mapping rule version management;The application realizes cross-source accurate collaborative query without changing the original system, and alleviates the problems of semantic inconsistency, high extension and maintenance cost and data aggregation delay.

Description

Technical Field

[0001] This invention belongs to the field of data query technology, and in particular relates to a multi-source data federated query method and system oriented towards the semantics of power equipment operation and maintenance ontology. Background Technology

[0002] With the increasing digitalization of power systems, the power industry has gradually formed multiple heterogeneous business systems, such as equipment management systems, production management systems, and online monitoring platforms, in areas such as equipment operation and maintenance, condition monitoring, and repair management. Each system stores core data such as ledger information, alarm information, maintenance records, and operating status, with a wide range of data sources and diverse types. When conducting health assessments, fault tracing, and maintenance decisions, operation and maintenance personnel often need to access data from multiple systems simultaneously for comprehensive comparison and joint analysis.

[0003] To address the query requirements in the aforementioned multi-source heterogeneous data environment, existing technologies typically employ the following implementation methods: First, develop dedicated data access interfaces or adapters for each business system, and implement data reading and transformation through hard coding; second, periodically extract and clean data from various systems, aggregate it into a unified data warehouse or data platform, and then establish a centralized query view; third, based on database middleware or enterprise service bus, encapsulate and call the interfaces of each data source, and achieve cross-source association through manual configuration of field mapping.

[0004] However, the aforementioned existing technologies have obvious drawbacks: the naming, encoding, and semantic expression of the same business object are inconsistent across systems, and there is a lack of unified semantic layer support, making it difficult to accurately associate data during cross-source queries, and the completeness and correctness of query results cannot be guaranteed; at the same time, developing adaptation logic separately for each data source leads to high system expansion and maintenance costs; while centralized data aggregation solutions introduce problems such as data redundancy, synchronization delay, and difficulty in maintaining consistency, and cannot achieve real-time collaborative queries without changing the original system storage structure. Summary of the Invention

[0005] Purpose of the invention: The purpose of this invention is to provide a multi-source data federated query method and system oriented towards the semantics of power equipment operation and maintenance ontology. Without changing the original storage structure and operation mode of each business system, it supports accurate association and real-time collaborative query of cross-source data through a unified semantic layer, thereby alleviating the problems of lack of semantic consistency, high system expansion and maintenance costs, and data redundancy and synchronization delay caused by centralized aggregation in the prior art.

[0006] Technical solution: The multi-source data federated query method for power equipment operation and maintenance ontology semantics described in this invention includes the following steps:

[0007] S1. Construct a multi-source heterogeneous data source access and adaptation mechanism, uniformly register, uniformly identify and abstract relational databases, time-series databases, document databases and external API interfaces related to power equipment operation and maintenance, form standardized data source description information, and establish metadata ledgers corresponding to each data source.

[0008] S2. Establish the semantic mapping relationship between the ontology model of power equipment operation and maintenance and multi-source heterogeneous data sources, obtain the ontology model of power equipment operation and maintenance, parse the classes, attributes and relationships in the ontology model of power equipment operation and maintenance, form an ontology element set, and establish the mapping rules between the ontology element set and the fields of multi-source heterogeneous data sources.

[0009] S3. Receive user query requests and perform semantic parsing. Parse the natural language query, SPARQL query, or SQL extended query submitted by the user, extract the query object, constraints, time range, returned fields, and query intent, and generate a unified intermediate query representation.

[0010] S4. Perform query rewriting and query splitting. Based on the mapping rules between the ontology element set and the fields of the multi-source heterogeneous data source, rewrite the intermediate query representation into local subqueries executed for different data sources, and split the cross-data source association query into multiple subquery tasks.

[0011] S5. Generate a federated query execution plan. Based on the data source access capability, data volume, network latency, query complexity, and cost model, schedule and optimize the subquery tasks to determine the execution order, parallel strategy, and result aggregation strategy.

[0012] S6. Execute multi-source federated queries. According to the federated query execution plan, distribute each subquery task to the corresponding data source and execute them in parallel or serially to obtain the intermediate query results returned by each data source.

[0013] S7. Perform semantic fusion and standardization on intermediate query results. Perform field alignment, type conversion, duplicate resolution, conflict resolution and semantic normalization on intermediate query results returned by each data source to generate a unified format federated query result set.

[0014] S8. Output the federated query results. Sort, filter, paginate, or format the federated query result set in the unified format according to user requirements and return it to the upper-layer business application.

[0015] S9. Manage and monitor the query tasks generated during the execution of steps S3 to S8, submit, pause, resume, delete and query the status of the query tasks, and monitor the system running status, data source connection status, query task time and resource usage, and record query logs, exception logs and operation logs.

[0016] S10. Perform version management on the mapping rules between the ontology element set and the fields of the multi-source heterogeneous data source, record the change information of the mapping rules, and store historical versions and switch versions according to the version identifier.

[0017] This technical solution, while fully preserving the original storage structure and operation mode of each power business system, effectively alleviates the problem of difficulty in associating multi-source heterogeneous data due to lack of semantic consistency by constructing a unified data source access and adaptation mechanism (S1) and semantic mapping relationship (S2). Furthermore, by utilizing semantic parsing of various query requests (S3), query rewriting and splitting (S4), and optimization of federated execution plans based on cost models (S5), it can reduce the complexity of cross-source queries and the system expansion and maintenance costs, while avoiding redundant storage and synchronization delays caused by centralized data aggregation. Through parallel or serial distribution of query tasks (S6), conflict resolution and semantic normalization of intermediate results (S7), on-demand formatted output (S8), and combined with full-process task management and monitoring (S9) and version management of mapping rules (S10), it significantly improves the efficiency of multi-source data collaborative query, system observability, and operation and maintenance flexibility for power equipment operation and maintenance ontology semantics, providing real-time, accurate, and semantically unified federated query results for upper-layer business applications.

[0018] Preferably, step S1 includes:

[0019] S11. Collect the data source address, access method, interface type, authentication method, supported protocols, and access scope of each business system;

[0020] S12. Generate a unique identifier for each data source and create a data source configuration file containing data source type, connection parameters, capability description and status information;

[0021] S13. Record the query capabilities, return formats, response latency, concurrency capabilities, and access permissions supported by the data source to form a data source capability ledger;

[0022] S14. When a data source is added, modified, or becomes invalid, the data source configuration file and capability ledger will be automatically updated.

[0023] The preferred step S1 systematically collects key parameters such as data source addresses, access methods, and authentication information from various business systems (S11), and generates a unique identifier and a configuration file containing complete connection parameters and status information for each data source (S12). This effectively alleviates the problems of poor scalability and maintenance difficulties caused by scattered information and non-standard descriptions during the access of multi-source heterogeneous data. At the same time, by recording the query capabilities, return formats, response latency, and access permissions of each data source (S13), and automatically updating the configuration file and capability ledger when a data source is added, modified, or becomes invalid (S14), the system's adaptability to dynamically changing data environments is further enhanced, reducing the risk of access failures or query errors caused by data source changes. This provides a stable, accurate, and timely updated data source foundation for subsequent semantic mapping and federated queries.

[0024] Preferably, step S2 includes:

[0025] S21. Import the ontology model of power equipment operation and maintenance, wherein the ontology model includes at least one or more of the following: equipment, lines, transformers, switches, measuring points, alarms, work orders, faults and status objects.

[0026] S22. Analyze the classes, attributes, instances and relationships in the ontology model to establish an ontology element set;

[0027] S23. Establish one-to-one, one-to-many, or many-to-one mapping rules between the ontology element set and the fields of the multi-source heterogeneous data source, and configure data type conversion rules, unit conversion rules, and exception handling rules.

[0028] S24. Perform addition, modification, deletion and query management on the mapping rules, and save the mapping configuration version.

[0029] The preferred step S2 imports an ontology model of power equipment operation and maintenance covering core objects such as equipment, lines, transformers, measurement points, alarms, and work orders (S21), and systematically parses the classes, attributes, instances, and relationships within it to form an ontology element set (S22), providing a unified semantic benchmark for multi-source heterogeneous data. On this basis, one-to-one, one-to-many, or many-to-one mapping rules between ontology elements and fields of each data source are established, while data type conversion, unit conversion, and exception handling rules are configured (S23), which can effectively alleviate the difficulties in cross-source association caused by semantic inconsistencies, data format, and unit differences between different data sources. By adding, modifying, deleting, and querying mapping rules, and saving the mapping configuration version (S24), the maintenance cost of frequently modifying mapping relationships due to changes in business requirements or adjustments to data sources is further reduced, enhancing the flexibility and traceability of the semantic mapping layer, and laying an accurate and configurable semantic bridge for subsequent query parsing and result fusion.

[0030] Preferably, step S3 includes:

[0031] S31. Receive query requests submitted by users using natural language, SPARQL, SQL extended statements, or system-defined query language;

[0032] S32. Identify the query topic, constraints, time range, spatial range, aggregation conditions, and output requirements in the query request;

[0033] S33. Combine ontology knowledge and semantic rules to perform intent parsing on the query request and generate a unified intermediate query representation;

[0034] S34. Perform syntax and semantic checks on the query request. If errors are found, output a prompt message and correct them.

[0035] The preferred step S3 effectively alleviates the limitation of different business personnel or upper-level applications being unable to uniformly access multi-source data due to differences in query syntax by supporting various query request forms such as natural language, SPARQL, SQL extended statements, and system-defined query language (S31). On this basis, the system identifies the topic, constraints, time range, spatial range, aggregation conditions, and output requirements in the query request (S32), and further combines ontology knowledge and semantic rules to perform intent parsing and generate a unified intermediate query representation (S33). This can significantly reduce the query comprehension bias caused by diverse user expressions or semantic ambiguity. At the same time, by performing syntax and semantic verification on the query request and outputting prompts and corrections when errors exist (S34), the user-friendliness and fault tolerance of the query input are improved, providing a standardized, accurate, and semantically consistent intermediate representation foundation for subsequent query rewriting and splitting.

[0036] Preferably, step S4 includes:

[0037] S41. Based on the mapping rules between the ontology element set and the fields of the multi-source heterogeneous data source, the unified intermediate query representation is rewritten into a query expression oriented towards a specific data source;

[0038] S42. Break down a complex query involving multiple data sources into multiple independent subquery tasks;

[0039] S43. Push the filtering conditions, time conditions, and constraints to the data source corresponding to the subquery task for execution;

[0040] S44. Establish association keys, connection paths, and connection conditions for cross-source related queries to form cross-source query dependencies.

[0041] The preferred step S4 rewrites the unified intermediate query representation into a query expression oriented towards a specific data source based on the mapping rules between ontology elements and fields of multi-source data sources (S41), effectively alleviating the semantic translation barriers caused by differences in query languages ​​and structures of different data sources; by splitting the composite query involving multiple data sources into multiple independent sub-query tasks (S42), and pushing the filtering, time and other constraints to be executed locally in each data source (S43), the computation and data transmission burden of the federated query engine can be reduced; at the same time, establishing association keys, connection paths and connection conditions for cross-source relational queries to form clear cross-source query dependencies (S44) helps to reduce the risk of low query efficiency and incorrect results caused by disordered cross-source connections or missing conditions, and provides a clear, decomposable and pushdownable query task foundation for the subsequent optimized scheduling of the federated execution plan.

[0042] Preferably, step S5 includes:

[0043] S51. Calculate the query cost based on the data source response time, network overhead, query complexity, and data volume.

[0044] S52. Determine the execution order and parallel execution group of the sub-query tasks based on the query cost;

[0045] S53. Generate a federated query execution plan that includes subquery tasks, execution nodes, scheduling order, timeout policy, and rollback policy;

[0046] S54. During execution, dynamically adjust the federated query execution plan based on the data source status and execution feedback.

[0047] The preferred step S5 calculates the query cost by comprehensively considering multiple factors such as data source response time, network overhead, query complexity, and data volume (S51), providing a quantitative basis for the scheduling optimization of federated queries and alleviating the problem of low execution efficiency caused by inaccurate cost estimation. Based on this, the execution order and parallel execution group of subquery tasks are reasonably determined according to the query cost (S52), and a federated query execution plan containing subquery tasks, execution nodes, scheduling order, timeout policy, and rollback policy is generated (S53), which helps to reduce the risk of resource contention and task blocking in cross-source queries. At the same time, the federated query execution plan is dynamically adjusted according to the data source status and real-time execution feedback during the execution process (S54), which enhances the system's adaptability to data source load fluctuations or temporary failures, reduces query timeouts or failures caused by fixed execution plans, and provides adaptive scheduling support for the efficient and stable execution of subsequent multi-source federated queries.

[0048] Preferably, step S6 includes:

[0049] S61. Distribute the subquery task to the corresponding data source;

[0050] S62. Parallel execution is used for independent subquery tasks, and cascading execution is used for subquery tasks with dependencies.

[0051] S63. Receive intermediate query results returned by each data source and record the execution log;

[0052] S64. When a data source fails, times out, or returns an exception, execute a retry, skip, or downgrade processing strategy.

[0053] The preferred step S6 effectively alleviates the problem of excessive overall query response delay caused by a single serial execution mode by distributing subquery tasks to each data source according to their corresponding relationships (S61) and using parallel execution for independent tasks and cascading execution for tasks with dependencies based on the dependencies between tasks (S62). By receiving intermediate query results returned by each data source and recording execution logs (S63), a data foundation is provided for subsequent result fusion and problem tracing. At the same time, when a data source fails, times out, or returns an exception, retry, skip, or degradation processing strategies can be executed (S64), reducing the negative impact of local data source failures on the overall federated query, improving the robustness and completion rate of the multi-source query process, and providing the most complete and traceable set of intermediate query results possible for subsequent semantic fusion and result output.

[0054] Preferably, steps S7 and S8 include:

[0055] S71. Standardize the field names, field order, field types, and field units in intermediate query results returned from different data sources;

[0056] S72. Remove duplicate records based on primary key, business key, or semantic key;

[0057] S73. When different data sources produce inconsistent intermediate query results for the same object, conflict resolution shall be carried out based on timestamp, source priority, or credibility rules.

[0058] S74. Aggregate, correlate, and normalize the intermediate query results returned by each data source to generate a federated query result set in a unified format.

[0059] S81. Sort the federated query result set according to time, level, relevance, or user-specified rules;

[0060] S82. Perform conditional filtering, range filtering, or label filtering on the federated query result set;

[0061] S83. Paginate the federated query result set according to the request parameters;

[0062] S84. Output the federated query result set to the upper-layer business application in table, JSON, XML or Excel format.

[0063] The preferred steps S7 and S8 unify the field names, order, type, and units of the intermediate query results returned by different data sources (S71), and deduplicate records based on primary keys, business keys, or semantic keys (S72). This effectively alleviates the semantic conflicts and data bloat caused by structural differences and redundant storage in multi-source data. When different data sources have inconsistent results for the same object, conflict handling is performed based on timestamps, source priority, or credibility rules (S73), further reducing the interference of data inconsistency on the accuracy of query results. Based on this, the intermediate query results returned by each data source are aggregated. The system performs association and normalization processes to generate a unified format of federated query result sets (S74), and sorts them by time, level, relevance, or user-specified rules (S81). Combined with conditional filtering, range filtering, or tag filtering (S82) and pagination (S83), it can alleviate the user experience degradation caused by excessively large result sets or unreasonable sorting. Finally, the federated query result sets are output to upper-layer business applications in formats such as tables, JSON, XML, or Excel (S84), which improves the flexibility and integrability of result output and provides semantically unified, structurally clear, and easy-to-use query results for different business scenarios.

[0064] Preferably, steps S9 and S10 include:

[0065] S91. Submit, pause, resume, delete, and query the status of query tasks generated during the execution of steps S3 to S8.

[0066] S92. Obtain the data source connection information and the execution status information of the query task corresponding to the execution process of step S6, and monitor and record them.

[0067] S93. Record the execution record, execution exception information, and user operation record of the query task;

[0068] S94. When the data source connection information or the execution status information of the query task meets the preset alarm conditions, an alarm message is generated.

[0069] S101. Record the version identifier, creation time, and changes of the mapping rules between the ontology element set and the fields of the multi-source heterogeneous data source;

[0070] S102. Read the mapping rules for the corresponding version based on the version identifier;

[0071] S103. Publish the mapping rules to the federated query execution environment.

[0072] The preferred steps S9 and S10 manage the entire lifecycle of the query task (submission, pause, resumption, deletion, and status query) (S91), and combine data source connection information and execution status monitoring records (S92), as well as complete records of execution records, exception information, and user operation logs (S93). This effectively alleviates the difficulties in problem localization and system maintenance caused by opaque task status and lack of traceability of exceptions. When the data source connection or task execution status meets the preset alarm conditions, alarm information is generated in a timely manner (S94), which helps to reduce the continuous impact of potential faults on the federated query service. At the same time, by recording the version identifier, creation time, and change content of the mapping rules between ontology elements and data source fields (S101), and supporting reading the corresponding version by version identifier (S102) and publishing the mapping rules to the federated query execution environment (S103), the risk of query semantic deviation and system incompatibility caused by frequent changes in mapping rules or the effect of incorrect versions is alleviated, and the traceability, canary release capability, and overall operation and maintenance flexibility of the semantic mapping layer are improved.

[0073] The multi-source data federated query system for power equipment operation and maintenance ontology semantics as described in this invention includes:

[0074] The data source layer includes various heterogeneous data sources involved in the operation and maintenance of power equipment, including at least one or more of relational databases, time-series databases, document databases, and external API interfaces, which are used to provide raw data storage and access capabilities.

[0075] An interface adaptation layer, connected to the data source layer, is used for unified access, protocol conversion, format adaptation, connection pool management, and data source proxying of the heterogeneous data sources, shielding the interface differences of the underlying data sources and providing a unified data access interface to the upper layers; the interface adaptation layer includes a data source registration unit, a connection pool management unit, a protocol conversion unit, and a format adaptation unit;

[0076] The federated query layer, connected to the interface adaptation layer, serves as the core logic layer of the system. It is used to parse query requests based on the ontology semantics of the power equipment operation and maintenance domain, perform query rewriting, subquery splitting, federated execution plan generation, subquery scheduling and distribution, and fuse multi-source return results. The federated query layer includes a semantic parsing unit, a query rewriting unit, a subquery splitting unit, a cost evaluation and plan generation unit, a subquery distribution and parallel execution unit, and a result standardization and fusion unit.

[0077] The application service layer, connected to the federated query layer, provides a unified federated query entry point, receives query requests from upper-layer business applications, returns a federated query result set, and manages query tasks, result display, and log monitoring. The application service layer includes a unified query interface unit, a task management unit, a result display unit, and a log monitoring unit.

[0078] The system also includes an ontology semantic modeling and mapping configuration module, which is connected to the federated query layer. This module is used to import ontology models in the power equipment operation and maintenance domain, parse the classes, attributes, and relationships in the ontology models to form an ontology element set, and establish mapping rules between the ontology element set and each data source field in the data source layer, supporting version management of the mapping rules.

[0079] Beneficial Effects: Compared with existing technologies, this invention has the following significant advantages: 1. Without changing the original storage structure and operation mode of each business system, this invention, through a unified power equipment operation and maintenance ontology semantic layer, parses, rewrites, and splits user query requests into local sub-queries for heterogeneous data sources. It supports accurate association and real-time collaborative querying of cross-source data in a federated execution manner, alleviating query bias caused by lack of semantic consistency, high system expansion and maintenance costs, and storage redundancy and synchronization delays caused by centralized data aggregation; 2. By establishing mapping rules between ontology elements and multi-source data fields, and combining query rewriting and filtering condition push-down mechanisms, it reduces the amount of cross-source data transmission while supporting parallel and cascaded execution. 3. Improve the response efficiency of federated queries; 4. Perform field alignment, type conversion, deduplication, and semantic conflict handling on intermediate results from different data sources to generate a unified format result set, enhancing the consistency, accuracy, and interpretability of cross-source query results; 5. Integrate a full lifecycle management and monitoring mechanism for query tasks, supporting task submission, pause, resumption, and abnormal retry and degradation handling strategies. Combined with data source capability ledgers and dynamic execution plan adjustments, it improves the stability and maintainability of the system in multi-source heterogeneous environments; 6. Through version management of ontology mapping rules, it supports rule change records, historical version storage, and dynamic switching, reducing the mapping maintenance costs caused by the evolution of business semantics and facilitating continuous system expansion and iterative adaptation. Attached Figure Description

[0080] Figure 1 This is a schematic diagram of the system architecture of the present invention;

[0081] Figure 2 This is a schematic diagram of the method flow of the present invention;

[0082] Figure 3 This is a schematic diagram illustrating the semantic mapping relationship between the power equipment operation and maintenance ontology and multi-source data fields of the present invention;

[0083] Figure 4 This is a schematic diagram of the federated query request parsing, subquery splitting and distribution process of the present invention;

[0084] Figure 5 This is a schematic diagram of the multi-source data federation execution and result fusion process of the present invention. Detailed Implementation

[0085] The technical solution of the present invention will be further described below with reference to the accompanying drawings.

[0086] This invention provides a multi-source data federated query system and method oriented towards the semantics of power equipment operation and maintenance ontology. It aims to solve the problem of "data silos" formed by multi-source heterogeneous data (such as relational databases, time-series databases, document databases, and API interfaces) in the power industry due to semantic inconsistencies and interface non-uniformity, leading to low cross-system query efficiency and difficulties in collaborative analysis. This invention achieves unified organization, description, and querying of cross-source, multi-format data without changing the original data storage structure or compromising the independence of business systems, thereby improving the sharing capability, query efficiency, and business support capability of power equipment operation and maintenance data.

[0087] I. System Overall Architecture

[0088] like Figure 1 As shown, the overall system architecture of this invention includes, from bottom to top, a data source layer, an interface adaptation layer, a federated query layer, and an application service layer.

[0089] Data source layer: Includes various heterogeneous data sources involved in the operation and maintenance of power equipment, such as relational databases (equipment ledgers, alarm tables, work order tables), time series databases (monitoring values, curves, timestamps), document databases, and external API interfaces (defect records, operation and maintenance events, metadata).

[0090] Interface adaptation layer: responsible for protocol conversion, format adaptation, connection pool management and data source proxy, providing a unified data access interface to the upper layer and shielding the access differences of the underlying data source.

[0091] Federated Query Layer: As the core logic layer of the system, it is responsible for semantic parsing, query plan generation, subquery scheduling, and fusion processing of multi-source return results.

[0092] Application service layer: Provides a unified query portal to the outside world and manages query tasks, result display and log monitoring.

[0093] II. Overall Method Flow

[0094] like Figure 2 As shown, the overall process of the method of the present invention includes the following core steps:

[0095] 1. Multi-source data access and adaptation: Unified registration, identification and abstraction of various heterogeneous data sources.

[0096] 2. Ontology Model Import and Mapping Configuration: Establish a semantic bridge between the power equipment operation and maintenance ontology and the fields of the physical data source.

[0097] 3. Federated Query Request Reception and Parsing: Receives and parses various forms of query requests submitted by users.

[0098] 4. Query splitting and subquery generation: Decompose global query requests into subqueries targeting specific data sources.

[0099] 5. Subquery dispatch and execution: Distribute subqueries to the corresponding data sources for parallel or serial execution.

[0100] 6. Result standardization and fusion processing: Unify and semantically fuse the results returned by various data sources.

[0101] 7. Unified output: Return the merged result set to the upper layer application as needed.

[0102] III. Detailed Implementation Methods for Each Step

[0103] (I) Step S1: Multi-source data access and adaptation mechanism

[0104] First, a multi-source heterogeneous data source access and adaptation mechanism is constructed. This involves unified registration, identification, and abstraction of relational databases, time-series databases, document databases, and external API interfaces related to power system automation, forming standardized data source description information, and establishing a metadata ledger for each data source. Specifically, this includes the following sub-steps:

[0105] S11. Data source information collection: Collect the data source address, access method, interface type, authentication method, supported protocols, and access scope of each business system.

[0106] S12. Unified modeling of data sources: Generate a unique identifier for each data source and establish a data source configuration file that includes data source type, connection parameters, capability description and status information.

[0107] S13. Data source capability registration: Record the query capabilities, return formats, response latency, concurrency capabilities, and access permissions supported by the data source to form a data source capability ledger.

[0108] S14. Dynamic Update of Data Source: When a data source is added, modified, or becomes invalid, the data source configuration file and capability ledger are automatically updated.

[0109] Through the above mechanism, the system can uniformly access and standardize the description of heterogeneous data sources in the field of power equipment operation and maintenance, support multiple data source access methods, form a unified data source management foundation, and provide standardized access capabilities for subsequent federated queries.

[0110] (ii) Step S2: Importing the ontology model and configuring semantic mapping

[0111] Establish a semantic mapping relationship between the ontology model of power equipment operation and maintenance and multi-source heterogeneous data sources. Obtain the ontology model of power equipment operation and maintenance, parse its classes, attributes, and relationships to form an ontology element set, and establish mapping rules between the ontology element set and the fields of the multi-source heterogeneous data sources. Specifically, this includes the following sub-steps:

[0112] S21. Import Ontology Model: Import an ontology model from the power sector. The ontology model must include at least one or more of the following: equipment, lines, transformers, switches, measurement points, alarms, work orders, faults, and status objects. OWL, RDF, and other ontology formats are supported.

[0113] S22. Ontology Element Parsing: Parse the classes, attributes, instances and relationships in the ontology to establish an ontology element ledger.

[0114] S23. Mapping rule configuration: Establish one-to-one, one-to-many, or many-to-one mapping relationships between ontology elements and data source fields, and configure data type conversion rules, unit conversion rules, and exception handling rules.

[0115] S24. Mapping Rule Management: Manages the addition, modification, deletion, and query of the mapping relationships, and saves the mapping configuration version. Supports version recording, version comparison, version rollback, and version release.

[0116] like Figure 3 As shown, ontology classes (such as equipment, lines, transformers, defects, alarms, and work orders) and their attributes (equipment number, name, status, time, location, and alarm level) are associated with data sources A (relational databases: equipment table / alarm table / work order table), B (time-series databases: monitoring values / curves / timestamps), and C (document databases / API interfaces: defect records / maintenance events / metadata) through semantic mapping (field name matching, semantic similarity matching, regular expression matching, type conversion, version management, etc.). This configuration enables business applications to express query intent using ontology concepts without directly interacting with the underlying heterogeneous data structures.

[0117] (III) Step S3: Receive user query requests and perform semantic parsing

[0118] The system receives query requests submitted by users via natural language, SPARQL queries, or extended SQL queries, performs semantic parsing, extracts the query object, constraints, time range, returned fields, and query intent, and generates a unified intermediate query representation. Specifically, it includes the following sub-steps:

[0119] S31. Query Statement Reception: Receives query requests submitted by users using natural language, SPARQL, SQL extended statements, or system-defined query language.

[0120] S32. Semantic element identification: Identify the query topic, constraints, time range, spatial range, aggregation conditions, and output requirements in the query request.

[0121] S33. Query Intent Analysis: Combine ontology knowledge and semantic rules to parse the intent of the query request and generate a unified intermediate query representation.

[0122] S34. Query validity check: Perform syntax and semantic checks on the query request. If errors are found, output a prompt message and support correction.

[0123] like Figure 4 As shown on the left, the semantic parsing module is responsible for identifying entities, attributes, conditions, and relationships in the query, laying the foundation for subsequent query rewriting.

[0124] (iv) Step S4: Perform query rewriting and query splitting

[0125] Based on the mapping rules between the ontology element set and the fields of the multi-source heterogeneous data sources, the intermediate query representation is rewritten as a local subquery executed for different data sources, and the cross-data source join query is split into multiple subquery tasks. Specifically, this includes the following sub-steps:

[0126] S41. Query Mapping Rewriting: Based on the mapping relationship between ontology elements and data source fields, the unified intermediate query representation is rewritten into a query expression oriented towards a specific data source.

[0127] S42, Subquery Splitting: Split a complex query involving multiple data sources into multiple independent subquery tasks.

[0128] S43. Condition Pushdown: Push down filtering conditions, time conditions, and constraints to the target data source as far as possible to reduce the size of intermediate results.

[0129] S44. Connection relationship generation: Establish association keys, connection paths and connection conditions for cross-source association queries to form cross-source query dependencies.

[0130] like Figure 4As shown in the middle section, the query rewriting module further processes the standardized federated query expression to generate multiple independently executable subqueries and labels the target data source type (relational database, time series database, API / document database).

[0131] (v) Step S5: Generate a federated query execution plan

[0132] Based on data source access capabilities, data volume, network latency, query complexity, and cost model, the sub-query task is scheduled and optimized to determine the execution order, parallelization strategy, and result aggregation strategy. Specifically, this includes the following sub-steps:

[0133] S51. Cost Assessment: Calculate the query cost based on the data source response time, network overhead, query complexity, and data volume.

[0134] S52. Execution order determination: Determine the execution order and parallel execution group of subqueries based on the query cost.

[0135] S53. Execution Plan Generation: Generates a federated query execution plan that includes subquery tasks, execution nodes, scheduling order, timeout policy, and rollback policy.

[0136] S54. Dynamic Adjustment of Plan: The query plan is dynamically adjusted during execution based on the data source status and execution feedback.

[0137] (vi) Step S6: Execute multi-source federated query

[0138] According to the federated query execution plan, each subquery task is distributed to its corresponding data source and executed in parallel or sequentially to obtain the intermediate query results returned by each data source. Specifically, this includes the following sub-steps:

[0139] S61, Subquery Distribution: Distribute the subquery task to the corresponding data source or data access agent.

[0140] S62. Parallel execution control: Independent subquery tasks are executed in parallel, while dependent subquery tasks are executed in cascade.

[0141] S63. Intermediate Result Acquisition: Receive intermediate query results returned by each data source and record the execution log.

[0142] S64. Exception handling: When a data source fails, times out, or returns an exception, a retry, skip, or degradation handling strategy is executed.

[0143] like Figure 4 As shown on the right, each subquery is distributed in parallel to the target data source (relational database, time series database, API / document database), and the execution status is tracked.

[0144] (vii) Step S7: Perform semantic fusion and standardization on intermediate query results.

[0145] The intermediate query results returned from each data source are processed for field alignment, type conversion, deduplication, conflict resolution, and semantic normalization to generate a unified formatted federated query result set. This includes the following sub-steps:

[0146] S71. Field Standardization: Standardize the field names, field order, field types, and field units in the results returned by different data sources.

[0147] S72. Duplicate Removal: Remove duplicate records based on primary key, business key, or semantic key.

[0148] S73. Conflict Resolution: When different data sources produce inconsistent results for the same object, conflict resolution is carried out based on timestamps, source priority, or credibility rules.

[0149] S74. Result Fusion: Aggregate, associate, and normalize the results of multiple subqueries to generate a unified federated result set.

[0150] like Figure 5 As shown, the results of subquery A from the relational database, subquery B from the time-series database, and subquery C from the API / document database are standardized (field alignment, type conversion, and time unification) and semantically normalized (expressed uniformly according to ontology concepts). Then, the federated execution engine performs deduplication and conflict resolution, association, and aggregation to finally generate a unified result set.

[0151] (viii) Step S8: Output the federated query results

[0152] The unified formatted federated query result set is sorted, filtered, paginated, or formatted according to user requirements and returned to the upper-layer business application. Specifically, this includes the following sub-steps:

[0153] S81. Result sorting: Sort the result set according to time, level, relevance, or user-specified rules.

[0154] S82. Result Filtering: Perform conditional filtering, range filtering, or label filtering on the result set.

[0155] S83, Paginated Output: Paginate the result set according to the request parameters.

[0156] S84, Multi-format return: Output the result set to the upper-level business application in table, JSON, XML or Excel format.

[0157] (ix) Query Management and Monitoring Steps

[0158] During the execution of steps S3 to S8, the generated query tasks undergo full lifecycle management, and the system's operating status, query process, and anomaly information are monitored and recorded. Specifically, this includes:

[0159] S91. Query Task Management: Submit, pause, resume, delete, and check the status of query tasks.

[0160] S92. Operation monitoring: Monitor the system's operating status, data source connection status, query task time, and resource usage.

[0161] S93. Log recording: Record query logs, exception logs, and operation logs.

[0162] S94 Alarm Push: When the monitoring indicators reach the preset threshold, an alarm is triggered and pushed to the monitoring platform or maintenance personnel.

[0163] (x) Mapping Version Management Steps

[0164] Version management is implemented for the mapping rules between the ontology element set and fields from multi-source heterogeneous data sources. Changes to these mapping rules are recorded, and historical versions are stored and switched based on version identifiers. Specifically, this includes:

[0165] S101, Version Record: Record the version changes to the ontology mapping rules and query configuration.

[0166] S102, Version Comparison: Supports comparison of differences between different versions.

[0167] S103, Version Rollback: When there is an error or anomaly in the current version configuration, roll back to a previously valid version.

[0168] S104, Version Release: Release the verified mapping rule version to the federated query execution environment.

[0169] IV. Implementation Example: Multi-source data federated query example based on equipment ledger system, online monitoring system and maintenance work order system

[0170] (a) Case Background

[0171] A provincial power company has established an equipment ledger system, an online monitoring system, and a maintenance work order system for its power equipment operation and maintenance. The equipment ledger system stores basic information about equipment such as substations, lines, main transformers, and switches, using a relational database and providing an SQL access interface. The online monitoring system collects real-time monitoring data on equipment operating status, temperature, current, voltage, and partial discharge, using a time-series database and providing a RESTful API interface. The maintenance work order system manages equipment defects, inspection records, maintenance records, and defect elimination results, using a document database and an HTTP API interface for external service.

[0172] Because the aforementioned systems differ significantly in data structure, field naming, access protocols, and semantic expression, maintenance personnel need to write separate query logics for different systems when performing tasks such as "equipment status query, defect tracking, and maintenance correlation analysis." This results in high data integration costs, low query efficiency, and difficulty in achieving unified retrieval at the business semantic level. This example uses the method provided by this invention to incorporate the equipment ledger system, online monitoring system, and maintenance work order system into a unified federated query framework, achieving cross-source collaborative query and result fusion based on ontology semantics.

[0173] (II) System Deployment and Configuration

[0174] In this example, the system is deployed in the provincial power company's data center, adopting a centralized and service-oriented architecture. Each functional module is deployed in a unified application server or container platform. The specific configuration steps are as follows:

[0175] 1. Business data source access and virtual table construction configuration

[0176] The configuration information for three business data sources is created through the multi-source data access module:

[0177] The unique identifier of the equipment ledger system data source is DS001, the access method is JDBC, the database type is MySQL, the request address is jdbc:mysql: / / IP:3306 / equip_ledger, and it supports basic equipment information queries.

[0178] The online monitoring system's data source is uniquely identified by DS002, accessed via RESTful API, with the request address being http: / / IP / monitor / api, and authentication using Token authentication.

[0179] The maintenance work order system has a unique data source identifier of DS003, accessed via HTTP API, with the request address being http: / / IP / workorder / api. No certificate authentication is required, and a unified JSON request / response format is used.

[0180] The virtual table construction submodule abstracts the above data source and generates virtual tables corresponding to business semantics, for example:

[0181] device_ledger_interface_data: corresponds to the device ledger system.

[0182] monitoring_status_interface_data: corresponds to the online monitoring system.

[0183] maintenance_order_interface_data: corresponds to the maintenance work order system.

[0184] At the same time, the mapping relationship between each virtual table field and the underlying source field, the data type conversion rules, and the field constraints are clearly defined, providing a unified access point for subsequent federated queries.

[0185] 2. Interface Acquisition and Interface Abstraction Configuration

[0186] The API interface acquisition submodule collects data from five interfaces of the online monitoring system, including: real-time equipment status query interface, equipment temperature monitoring interface, current and voltage monitoring interface, partial discharge monitoring interface, and alarm event interface. Simultaneously, it collects data from four interfaces of the maintenance work order system, including: defect registration interface, maintenance work order query interface, defect elimination result interface, and inspection record interface. An API interface ledger is established, and the interface information update frequency is set to 30 minutes.

[0187] The interface abstraction submodule performs unified abstraction processing on the collected heterogeneous interfaces, eliminating differences in interface request formats, return formats, and parameter naming. For example:

[0188] The device_code in the online monitoring system and the equipment_id in the equipment ledger system are uniformly abstracted into equipment_id.

[0189] The defect_level in the maintenance work order system and the alarm_level in the online monitoring system are uniformly abstracted into fault_level.

[0190] The monitor_time, collect_time, and record_time are all abstracted into event_time.

[0191] Ultimately, a standardized interface description specification was formed, providing consistent data interface semantics for ontology semantic mapping and federated queries.

[0192] 3. Virtual table generation

[0193] The virtual table generation submodule generates standardized virtual tables based on the abstracted interface information and clarifies the correspondence between the interface return parameters and the virtual table fields. For example:

[0194] The equipment_ledger_interface_data field includes: equipment_id, equipment_name, voltage_level, station_name, install_date, etc.

[0195] monitoring_status_interface_data fields include: equipment_id, event_time, temperature, current_value, voltage_value, status_code, etc.

[0196] The maintenance_order_interface_data fields include: equipment_id, defect_id, fault_level, maintenance_time, maintenance_content, rectification_result, etc.

[0197] Simultaneously, field constraint rules and type conversion rules can be set to support relational queries and joint filtering between data from multiple interfaces.

[0198] 4. Ontology mapping configuration

[0199] The ontology import submodule imports an ontology model (OWL format) for the power equipment operation and maintenance domain, and parses the core elements in the ontology, including: equipment classes, substation classes, defect information attributes, operating status attributes, maintenance record attributes, and alarm level attributes. After establishing the ontology element ledger, the mapping rule configuration submodule establishes the semantic mapping relationship between ontology elements and virtual table fields, for example:

[0200] The "Equipment Number" attribute of "Equipment Class" is mapped to the equipment_id field in three virtual tables, forming a one-to-many mapping.

[0201] Map the "Running Status" attribute to the status_code field in the monitoring_status_interface_data table.

[0202] Map the "Defect Information" attribute to the defect_id and fault_level fields in the maintenance_order_interface_data table.

[0203] Map the "Maintenance Record" attribute to the maintenance_content field in the maintenance_order_interface_data table.

[0204] The data conversion rules are set as follows: numeric types are uniformly set to floating-point numbers; time types are uniformly set to YYYY-MM-DDHH:MM:SS; enumeration types are uniformly set to standard code table encoding; and null values ​​are handled using a default value and missing value flag mechanism. The exception handling strategy is set as follows: if a query returns an exception, it will automatically retry twice; if it still fails, an exception log will be recorded and a standard error message will be returned.

[0205] The mapping verification submodule verifies the legality and consistency of mapping rules to ensure that the mapping relationship is complete and conflict-free. The mapping version management submodule records the current mapping rule version as V1.0, supporting version release, rollback, and auditing.

[0206] 5. Unified access service and proxy configuration

[0207] The unified access service module provides a sub-module that offers a standardized RESTful access interface: http: / / IP / unified / federation / api. This interface supports operations such as querying, statistics, correlation analysis, and pagination, and defines a unified request and response format.

[0208] The request conversion submodule of the business data access proxy module configures the relationship between virtual tables and underlying API / database interfaces, enabling rapid conversion from SQL subqueries and SPARQL semantic queries to specific data source call instructions.

[0209] The API calls submodules employ a synchronous call mode for faster-responding equipment ledger queries and maintenance work order queries, while a parallel asynchronous call mode is used for real-time monitoring data queries to improve the efficiency of federated queries.

[0210] The exception handling submodule allows for the configuration of exception logging functions, which record in detail the time, reason, failure process, and processing result of interface calls, facilitating subsequent troubleshooting and maintenance analysis.

[0211] (III) Method Execution Process

[0212] In this example, the process by which the power equipment operation and maintenance application collaboratively accesses data from the equipment ledger system, online monitoring system, and maintenance work order system through the system of this invention is as follows:

[0213] Step S1: Multi-source data access and adaptation (corresponding to) Figure 1 (Data source layer and interface adaptation layer)

[0214] The system has completed the unified registration, unique identification, and abstraction of the equipment ledger system (relational database), online monitoring system (time series database), and maintenance work order system (document database / API) according to the above deployment steps, and established a metadata ledger containing information such as data source type, connection parameters, and capability description.

[0215] Step S2: Establishment of ontology model and semantic mapping (corresponding to) Figure 3 )

[0216] The system has imported an ontology model from the power equipment operation and maintenance domain (including classes such as equipment, lines, alarms, and work orders, as well as attributes such as equipment number, status, and time), and established mapping rules between ontology elements and three data source fields (including field name matching, semantic similarity matching, and type conversion). The specific mapping relationships are as follows: Figure 3 As shown: The ontology class is connected to data source A (device table / alarm table / work order table), data source B (monitoring value / curve / timestamp) and data source C (defect record / operation and maintenance event / metadata) through semantic mapping.

[0217] Step S3: Receive query requests and perform semantic parsing (corresponding to...) Figure 4 (Left side)

[0218] The power equipment operation and maintenance application sends a query request to the unified access service module. The request content is: "Query the real-time operating status, alarm information of the past 24 hours, and the most recent maintenance record of all equipment in a substation, and filter out equipment with high temperature alarms and the most recent maintenance time exceeding 30 days." The request format is JSON, and the return format is also specified as JSON, requiring the following information: equipment number, equipment name, current operating status, alarm time, alarm level, most recent maintenance time, maintenance content, and defect description.

[0219] The query request parsing submodule of the unified access service module receives requests, such as... Figure 4 As shown on the left, semantic parsing is performed to identify the query topic (equipment, alarm, maintenance), constraints (substation range, high temperature alarm, time range of the most recent 24 hours, maintenance time exceeding 30 days), entity relationships (association between equipment and alarm, maintenance), and query intent, and generate a unified intermediate query representation.

[0220] Step S4: Query rewriting and query splitting (corresponding to) Figure 4 middle)

[0221] The system performs query rewriting, standardizing the intermediate query representation into a federated query expression. Then, based on the mapping rules established in step S2, the composite query across data sources is split into three independent subquery tasks, and condition push-over is implemented:

[0222] Subquery A (for the equipment ledger system, relational database): Query the equipment number and name of a specified substation.

[0223] Subquery B (for online monitoring systems, time-series database): Queries high-temperature alarms and times when the device's temperature is ≥75℃.

[0224] Subquery C (for the maintenance work order system, API / document database): Query records and content of equipment maintenance time exceeding 30 days.

[0225] like Figure 4 As shown in the middle, the query rewriting module converts the standardized federated query expression into multiple subqueries and marks the target data source type (relational database, time series database, API / document database).

[0226] Step S5: Generate a federated query execution plan

[0227] Based on the access capabilities, data volume, network latency, and query complexity of each data source, the system determines that subquery tasks A, B, and C are independent and can be executed in parallel. Simultaneously, a timeout policy (e.g., 5 seconds) and a retry policy (e.g., retrying twice on failure) are set for each subquery, generating the final federated query execution plan.

[0228] Step S6: Execute a multi-source federated query (corresponding to...) Figure 4 right side and Figure 5 top)

[0229] like Figure 4 As shown on the right, the federated query execution engine distributes subqueries A, B, and C in parallel to their corresponding data sources (relational databases, time-series databases, and API / document databases) according to the execution plan. After each data source executes the query, it returns intermediate results.

[0230] Subquery A returns a list of equipment ledgers.

[0231] Subquery B returns the time-series data of the high-temperature alarm.

[0232] Subquery C returns maintenance work order records.

[0233] Step S7: Perform semantic fusion and standardization processing on the intermediate query results (corresponding to...) Figure 5 )

[0234] like Figure 5 As shown, the system processes the heterogeneous results returned by various data sources:

[0235] Results standardization: Perform field alignment (e.g., equip_id → equipment_id), type conversion (string to floating-point number), and time standardization (convert to YYYY-MM-DD HH:MM:SS format).

[0236] Semantic normalization: unifying the expression of data from different sources according to ontology concepts (devices, alarms, work orders).

[0237] Deduplication and conflict resolution: The equipment_id is used as the primary key for association. For duplicate or conflicting records, the records are resolved based on the timestamp (the latest one) and source priority rules (such as online monitoring data taking precedence over manual entry).

[0238] Association and aggregation: Filter out equipment data that simultaneously meet the two conditions of "high temperature alarm" and "last maintenance time more than 30 days", and generate a unified federated query result set.

[0239] Step S8: Output the federated query results (corresponding to...) Figure 5 bottom)

[0240] The system will sort, filter, and paginate the merged unified result set according to user requirements (descending order by alarm level), and finally return it to the upper-layer business application in JSON format. Operations personnel can then use this result to locate, analyze, and make maintenance decisions for high-risk equipment.

[0241] Steps S9 and S10: Query management and monitoring, mapping version management

[0242] Throughout the entire query execution process, the system management module tracks the status of the query task (submission, running, completion) and records execution logs, time consumption, and exception information. Simultaneously, the system manages the mapping rules established in step S2 (V1.0) to ensure that subsequent configuration changes are traceable and rollbackable.

[0243] (iv) Example Results

[0244] Through the above implementation examples, this invention successfully achieves unified, efficient, and collaborative querying of multi-source heterogeneous data based on ontology semantics without altering the original data storage and business system operation. Maintenance personnel do not need to concern themselves with the physical location, interface protocols, and data formats of the underlying data sources; they only need to express their query intent through ontology concepts to obtain a unified result set after semantic fusion. This significantly improves the sharing capability, query efficiency, and business support capability of power equipment operation and maintenance data, solving problems such as data fragmentation and isolation, inconsistent query interfaces, inconsistent semantic expressions, low efficiency of cross-source queries, and difficulties in system expansion and maintenance in existing technologies.

Claims

1. A multi-source data federated query method for power equipment operation and maintenance ontology semantics, characterized in that, Includes the following steps: S1. Construct a multi-source heterogeneous data source access and adaptation mechanism, uniformly register, uniformly identify and abstract relational databases, time-series databases, document databases and external API interfaces related to power equipment operation and maintenance, form standardized data source description information, and establish metadata ledgers corresponding to each data source. S2. Establish the semantic mapping relationship between the ontology model of power equipment operation and maintenance and multi-source heterogeneous data sources, obtain the ontology model of power equipment operation and maintenance, parse the classes, attributes and relationships in the ontology model of power equipment operation and maintenance, form an ontology element set, and establish the mapping rules between the ontology element set and the fields of multi-source heterogeneous data sources. S3. Receive user query requests and perform semantic parsing. Parse the natural language query, SPARQL query, or SQL extended query submitted by the user, extract the query object, constraints, time range, returned fields, and query intent, and generate a unified intermediate query representation. S4. Perform query rewriting and query splitting. Based on the mapping rules between the ontology element set and the fields of the multi-source heterogeneous data source, rewrite the intermediate query representation into local subqueries executed for different data sources, and split the cross-data source association query into multiple subquery tasks. S5. Generate a federated query execution plan. Based on the data source access capability, data volume, network latency, query complexity, and cost model, schedule and optimize the subquery tasks to determine the execution order, parallel strategy, and result aggregation strategy. S6. Execute multi-source federated queries. According to the federated query execution plan, distribute each subquery task to the corresponding data source and execute them in parallel or serially to obtain the intermediate query results returned by each data source. S7. Perform semantic fusion and standardization on intermediate query results. Perform field alignment, type conversion, duplicate resolution, conflict resolution and semantic normalization on intermediate query results returned by each data source to generate a unified format federated query result set. S8. Output the federated query results. Sort, filter, paginate, or format the federated query result set in the unified format according to user requirements and return it to the upper-layer business application. S9. Manage and monitor the query tasks generated during the execution of steps S3 to S8, submit, pause, resume, delete and query the status of the query tasks, and monitor the system running status, data source connection status, query task time and resource usage, and record query logs, exception logs and operation logs. S10. Perform version management on the mapping rules between the ontology element set and the fields of the multi-source heterogeneous data source, record the change information of the mapping rules, and store historical versions and switch versions according to the version identifier.

2. The method according to claim 1, characterized in that, Step S1 includes: S11. Collect the data source address, access method, interface type, authentication method, supported protocols, and access scope of each business system; S12. Generate a unique identifier for each data source and create a data source configuration file containing data source type, connection parameters, capability description and status information; S13. Record the query capabilities, return formats, response latency, concurrency capabilities, and access permissions supported by the data source to form a data source capability ledger; S14. When a data source is added, modified, or becomes invalid, the data source configuration file and capability ledger will be automatically updated.

3. The method according to claim 1, characterized in that, Step S2 includes: S21. Import the ontology model of power equipment operation and maintenance, wherein the ontology model includes at least one or more of the following: equipment, lines, transformers, switches, measuring points, alarms, work orders, faults and status objects. S22. Analyze the classes, attributes, instances and relationships in the ontology model to establish an ontology element set; S23. Establish one-to-one, one-to-many, or many-to-one mapping rules between the ontology element set and the fields of the multi-source heterogeneous data source, and configure data type conversion rules, unit conversion rules, and exception handling rules. S24. Perform addition, modification, deletion and query management on the mapping rules, and save the mapping configuration version.

4. The method according to claim 1, characterized in that, Step S3 includes: S31. Receive query requests submitted by users using natural language, SPARQL, SQL extended statements, or system-defined query language; S32. Identify the query topic, constraints, time range, spatial range, aggregation conditions, and output requirements in the query request; S33. Combine ontology knowledge and semantic rules to perform intent parsing on the query request and generate a unified intermediate query representation; S34. Perform syntax and semantic checks on the query request. If errors are found, output a prompt message and correct them.

5. The method according to claim 1, characterized in that, Step S4 includes: S41. Based on the mapping rules between the ontology element set and the fields of the multi-source heterogeneous data source, the unified intermediate query representation is rewritten into a query expression oriented towards a specific data source; S42. Break down a complex query involving multiple data sources into multiple independent subquery tasks; S43. Push the filtering conditions, time conditions, and constraints to the data source corresponding to the subquery task for execution; S44. Establish association keys, connection paths, and connection conditions for cross-source related queries to form cross-source query dependencies.

6. The method according to claim 1, characterized in that, Step S5 includes: S51. Calculate the query cost based on the data source response time, network overhead, query complexity, and data volume. S52. Determine the execution order and parallel execution group of the sub-query tasks based on the query cost; S53. Generate a federated query execution plan that includes subquery tasks, execution nodes, scheduling order, timeout policy, and rollback policy; S54. During execution, dynamically adjust the federated query execution plan based on the data source status and execution feedback.

7. The method according to claim 1, characterized in that, Step S6 includes: S61. Distribute the subquery task to the corresponding data source; S62. Parallel execution is used for independent subquery tasks, and cascading execution is used for subquery tasks with dependencies. S63. Receive intermediate query results returned by each data source and record the execution log; S64. When a data source fails, times out, or returns an exception, execute a retry, skip, or downgrade processing strategy.

8. The method according to claim 1, characterized in that, Steps S7 and S8 include: S71. Standardize the field names, field order, field types, and field units in intermediate query results returned from different data sources; S72. Remove duplicate records based on primary key, business key, or semantic key; S73. When different data sources produce inconsistent intermediate query results for the same object, conflict resolution shall be carried out based on timestamp, source priority, or credibility rules. S74. Aggregate, correlate, and normalize the intermediate query results returned by each data source to generate a federated query result set in a unified format. S81. Sort the federated query result set according to time, level, relevance, or user-specified rules; S82. Perform conditional filtering, range filtering, or label filtering on the federated query result set; S83. Paginate the federated query result set according to the request parameters; S84. Output the federated query result set to the upper-layer business application in table, JSON, XML or Excel format.

9. The method according to claim 1, characterized in that, Steps S9 and S10 include: S91. Submit, pause, resume, delete, and query the status of query tasks generated during the execution of steps S3 to S8. S92. Obtain the data source connection information and the execution status information of the query task corresponding to the execution process of step S6, and monitor and record them. S93. Record the execution record, execution exception information, and user operation record of the query task; S94. When the data source connection information or the execution status information of the query task meets the preset alarm conditions, an alarm message is generated. S101. Record the version identifier, creation time, and changes of the mapping rules between the ontology element set and the fields of the multi-source heterogeneous data source; S102. Read the mapping rules for the corresponding version based on the version identifier; S103. Publish the mapping rules to the federated query execution environment.

10. A multi-source data federated query system oriented towards the semantics of power equipment operation and maintenance ontology, characterized in that, include: The data source layer includes various heterogeneous data sources involved in the operation and maintenance of power equipment, including at least one or more of relational databases, time-series databases, document databases, and external API interfaces, which are used to provide raw data storage and access capabilities. An interface adaptation layer, connected to the data source layer, is used for unified access, protocol conversion, format adaptation, connection pool management, and data source proxying of the heterogeneous data sources, shielding the interface differences of the underlying data sources and providing a unified data access interface to the upper layers; the interface adaptation layer includes a data source registration unit, a connection pool management unit, a protocol conversion unit, and a format adaptation unit; The federated query layer, connected to the interface adaptation layer, serves as the core logic layer of the system. It is used to parse query requests based on the ontology semantics of the power equipment operation and maintenance domain, perform query rewriting, subquery splitting, federated execution plan generation, subquery scheduling and distribution, and fuse multi-source return results. The federated query layer includes a semantic parsing unit, a query rewriting unit, a subquery splitting unit, a cost evaluation and plan generation unit, a subquery distribution and parallel execution unit, and a result standardization and fusion unit. The application service layer, connected to the federated query layer, provides a unified federated query entry point, receives query requests from upper-layer business applications, returns a federated query result set, and manages query tasks, result display, and log monitoring. The application service layer includes a unified query interface unit, a task management unit, a result display unit, and a log monitoring unit. The system also includes an ontology semantic modeling and mapping configuration module, which is connected to the federated query layer. This module is used to import ontology models in the power equipment operation and maintenance domain, parse the classes, attributes, and relationships in the ontology models to form an ontology element set, and establish mapping rules between the ontology element set and each data source field in the data source layer, supporting version management of the mapping rules.

Images