Data query method and system based on ontology semantic data network and ABC paradigm

Abstract

The application provides a data query method and system based on an ontology semantic data network and an ABC paradigm, the data query method based on the ontology semantic data network and the ABC paradigm comprises the following steps: constructing an ontology semantic data network ONN; receiving a natural language query and verifying answerability; distributing a task that passes the verification to an ABC deep analysis process by using a scheduling Agent; generating an OQS intermediate representation based on the ABC paradigm; translating the OQS into a pipeline DSL by using a DSL generation Agent; and executing the pipeline DSL and assembling a return execution result. In the above technical solution, the semantic gap is eliminated, and the query accuracy is improved.

Description

Technical Field

[0001] This application relates to the fields of artificial intelligence and data processing technology, and in particular to a data query method and system based on ontology semantic data network and ABC paradigm. Background Technology

[0002] As the scale and complexity of enterprise data continue to grow, the need to directly query databases using natural language is becoming increasingly urgent. Existing technical solutions mainly suffer from the following shortcomings:

[0003] The illusion and low availability of Text-to-SQL solutions. These solutions attempt to allow large language models to directly translate natural language into SQL statements. However, there is a significant semantic gap between business concepts in natural language and the table structure of the physical database. When faced with multi-table joins and complex business logic, large models are prone to illusions such as erroneous fields and incorrect join paths. The generated SQL statements are difficult to debug and verify, resulting in low availability in production environments.

[0004] Retrieval Enhanced Generation (RAG) has limitations in structured query processing. While RAG technology assists large models in generating answers by retrieving external document fragments and is suitable for question-and-answering of unstructured documents, it cannot perform precise aggregation calculations, multi-dimensional sorting, and cross-table join analysis on structured data (such as relational database tables), thus failing to meet the needs of enterprise-level precise data queries.

[0005] The pre-built question-and-answer pairs lack generalization ability. Solutions that match databases with pre-built question-and-answer pairs lack coverage of long-tail user query needs, and maintenance costs increase linearly with business changes.

[0006] Graph subgraph representation is inefficient. In scenarios that require handling complex object relationship subgraphs, if the adjacency matrix representation is used, its token consumption increases by O(n²) with the number of nodes, and the sparse matrix will distract the attention of large models, resulting in poor understanding of graph topology and generation accuracy.

[0007] There is a lack of automated quality control mechanisms that do not rely on manual annotation. Existing solutions, after generating query code, cannot determine whether the semantics of the generated code match the user's original intent unless an execution-level error occurs. Figure 1 For example, if a user queries "sales amount," the system might actually query "order amount." Current technology lacks effective methods for automatically detecting such semantic discrepancies. Summary of the Invention

[0008] This application provides a data query method and system based on ontology semantic data network and ABC paradigm to eliminate semantic gap and improve query accuracy.

[0009] Firstly, a data query method based on ontology semantic data network and ABC paradigm is provided, including the following steps:

[0010] Construct an ontology semantic data network (ONN);

[0011] Perform natural language query reception and responsiveness verification;

[0012] The scheduling agent is used to distribute the verified tasks to the ABC deep parsing process;

[0013] OQS intermediate representation is generated based on ABC paradigm;

[0014] The OQS is translated into a pipelined DSL by generating an agent using the DSL.

[0015] Execute the pipelined DSL and assemble and return the execution result.

[0016] In the above technical solution, an ontology semantic data network (ONN) is constructed; natural language queries are received and their responsiveness is verified; a scheduling agent is used to distribute verified tasks to the ABC deep parsing process; an intermediate OQS representation is generated based on the ABC paradigm; an agent is generated using a DSL to translate the OQS into a pipelined DSL; the pipelined DSL is executed and the execution result is assembled and returned; thus, the semantic gap is eliminated and the query accuracy is improved.

[0017] In one specific implementation scheme, the method further includes: performing quality inspection on the execution result based on double-blind quality inspection using reverse semantic reconstruction to obtain the quality inspection result.

[0018] In one specific implementation scheme, it also includes:

[0019] The ontology semantic data network (ONN) is self-grown based on the quality inspection results.

[0020] In one specific implementation scheme, the Ontology Semantic Data Network (ONN) includes an ontology model layer, an instance network layer, and a behavior implementation layer, wherein...

[0021] The model layer uses various types of nodes and relationships to define the CBC pattern.

[0022] In one specific implementation scheme, the self-growth of the ontology semantic data network (ONN) includes:

[0023] Use metrics to learn agents and accumulate high-frequency query templates;

[0024] Utilize knowledge-based learning agents to update ONN model layer constraints and rules;

[0025] Utilize user profiling to analyze agent intent and optimize parameters.

[0026] In one feasible implementation, natural language queries are received and their responsiveness is verified through an intent clarification agent and an intent verification agent.

[0027] In one feasible implementation, the query planning agent, condition filtering agent, field extraction agent, and calculation method agent work together in sequence to generate the OQS intermediate representation based on the ABC paradigm.

[0028] Secondly, a data query system based on ontology semantic data network and ABC paradigm is provided, including:

[0029] The building module is used to construct the ontology semantic data network ONN;

[0030] The verification module is used to receive and verify the responsiveness of natural language queries.

[0031] The scheduling module is used to distribute verified tasks to the ABC deep parsing process using the scheduling agent;

[0032] The ABC module is used to generate OQS intermediate representations based on the ABC paradigm.

[0033] The DSL module is used to generate an agent using DSL to translate OQS into pipelined DSL;

[0034] The execution module is used to execute the pipeline DSL and assemble and return the execution results.

[0035] In the above technical solution, an ontology semantic data network (ONN) is constructed; natural language queries are received and their responsiveness is verified; a scheduling agent is used to distribute verified tasks to the ABC deep parsing process; an intermediate OQS representation is generated based on the ABC paradigm; an agent is generated using a DSL to translate the OQS into a pipelined DSL; the pipelined DSL is executed and the execution result is assembled and returned; thus, the semantic gap is eliminated and the query accuracy is improved.

[0036] In one specific implementation scheme, it also includes:

[0037] The quality inspection module is used to perform quality inspection on the execution result based on double-blind quality inspection of reverse semantic reconstruction, and obtain the quality inspection result.

[0038] In one specific implementation scheme, it also includes:

[0039] The self-growth module is used to perform system self-growth of the ontology semantic data network (ONN) based on the quality inspection results. Attached Figure Description

[0040] Figure 1 A flowchart illustrating the data query method based on ontology semantic data network and ABC paradigm provided in the embodiments of this application;

[0041] Figure 2 The structural block diagram of the data query system based on ontology semantic data network and ABC paradigm provided in the embodiments of this application. Detailed Implementation

[0042] The present application will now be described in further detail with reference to the accompanying drawings and embodiments. Through these descriptions, the features and advantages of the present application will become clearer and more apparent.

[0043] The term “exemplary” as used herein means “serving as an example, embodiment, or illustration.” Any embodiment illustrated herein as “exemplary” is not necessarily to be construed as superior to or better than other embodiments. Although various aspects of embodiments are shown in the accompanying drawings, the drawings are not necessarily drawn to scale unless specifically indicated otherwise.

[0044] Furthermore, the technical features involved in the different embodiments of this application described below can be combined with each other as long as they do not conflict with each other.

[0045] Therefore, this application provides a data query method and system based on ontology semantic data network and ABC paradigm to eliminate the semantic gap and improve query accuracy. The following detailed description, in conjunction with specific accompanying drawings, illustrates the embodiments.

[0046] In order to accurately define the technical scope of this application, the core terms are defined and explained as follows:

[0047] Ontology Semantic Data Network (ONN): A computable semantic network data structure with ontologies as nodes, semantic relations as edges, and CBC (Context-Behavior-Constraint) as the unified logical kernel. This network expresses relationships between business objects through graph-structured semantic connections and reasoning. The term "network" specifically refers to the semantic graph topology composed of ontology classes, relation classes, instance nodes, and their attributes, rather than a deep learning parameterized model based on artificial neuron weights and backpropagation algorithms. ONN natively supports unified modeling of objects, relations, behaviors, and contexts, as well as multimodal data mounting.

[0048] The ABC paradigm (Acquire-Build-Calculate) is a methodology for breaking down complex natural language queries into standardized operational steps. Step A (Acquire Objects) identifies the object classes involved in the problem and constructs a subgraph of object relationships; Step B (Build Dataset) determines the filtering criteria and data fields to be extracted from the objects in the subgraph; and Step C (Calculate Metrics) determines the calculation formulas between the fields.

[0049] ONN Query Specification (OQS): A structured intermediate representation output by the problem analysis agent group. It describes the query intent based on the ONN model layer in a node-edge separation format and carries all semantic information of the ABC steps.

[0050] Pipeline DSL (Domain Specific Language): A set of executable instructions for a low-level engine, which is translated from OQS by a DSL-generated agent. It uses JSON format and supports multi-step chained computation.

[0051] AI-generated structured artifacts (AI-generated structured artifacts, often referred to as "target artifacts") are machine-executable products with interpretable logical structures automatically generated by large language models or intelligent agent systems based on large language models, based on the user's natural language task description. These target artifacts include, but are not limited to: data query instructions (such as SQL, DSL, GraphQL, etc.), program code (such as Python functions, Java methods, etc.), API call sequences and their parameters, intelligent agent workflow orchestration definitions, ETL data pipeline configurations, automated test scripts, system configuration files, etc. Their common characteristic is that they possess clearly defined logical elements (operation objects, execution conditions, expected output, processing flow, etc.), and can be interpreted and translated into natural language item by item.

[0052] Reverse Semantic Restoration: A process of interpreting and translating the logical elements of a target product into natural language descriptions. Specifically, it involves restoring the operational objects in the target product into business entity names, the execution conditions into natural language constraints, the expected output into information requirement descriptions, and the processing flow into step-by-step task descriptions. These are ultimately combined into a complete "system understanding description" that describes "what the product is actually doing."

[0053] Double-Blind Quality Inspection: A verification mechanism based on information isolation. In this invention, "double-blind" specifically refers to two layers of independence guarantees: First, the quality inspection verification agent does not receive the user's original natural language task description as input when performing quality inspection, but only performs reverse semantic reconstruction based on the target product itself; Second, the quality inspection verification agent performing reverse semantic reconstruction and the generation agent performing forward generation of the target product are independent of each other, and do not share intermediate reasoning processes, prompt word content, and contextual memory. This double isolation design ensures that the quality inspection results are not affected by the anchoring effect of the original task description and the path dependency of the forward generation logic.

[0054] Semantic Consistency Comparison: This is the process of performing multi-dimensional semantic entailment analysis on the "system understanding description" generated by the quality inspection verification agent through reverse semantic reconstruction and the user's original natural language task description, in order to determine whether the two are equivalent in terms of business semantics.

[0055] Semantic Consistency Score: A comprehensive score calculated based on multi-dimensional comparison results and according to preset dimensional weights, used to quantify the degree of semantic matching between the target product and the user's original intent.

[0056] Targeted Correction: When quality inspection fails, based on the specific differences in each dimension in the multi-dimensional comparison, a feedback instruction containing a clear deviation location and correction direction is sent to the upstream generation system, so that the upstream system only corrects the parts with deviations, rather than regenerating the entire dataset.

[0057] Node-Edge Separated Structure: A graph structure representation method that describes the node information (object class, filtering conditions, extraction fields) and edge information (relationship type, direction) of the graph using independent data structures, instead of using a two-dimensional matrix representation of the adjacency matrix. This structure has a storage space complexity of O(n+e) (where n is the number of nodes and e is the number of edges), significantly reducing the token consumption required for processing large language models compared to the O(n²) of the adjacency matrix.

[0058] Condition Source Annotation (CSA): A mechanism that records both the condition value and its source in the filtering criteria. The source of each filtering condition is annotated as either "User Question" (explicitly raised by the user) or "Business Default Rule" (automatically injected by CBC constraints in the ontology model layer), making the ontology-driven condition injection process fully traceable and auditable.

[0059] Ontology Semantic Data Network (ONN) is a computable semantic network data structure with ontology classes as nodes, semantic relation classes as edges, and a CBC (Content Contextualization) pattern as its unified logical kernel. ONN consists of three layers: an ontology model layer (defining object classes, relation classes, and their CBC strategies), an instance network layer (storing specific instance data and automatically inheriting the CBC strategies from the model layer), and a behavior implementation layer (associating semantic behaviors with specific execution implementations). The term "network" specifically refers to the semantic graph topology structure composed of ontology classes, relation classes, instance nodes, and their attributes and strategies, rather than a deep learning parameterized model based on artificial neuron weights and backpropagation algorithms.

[0060] Ontology Class (OC): An abstract type definition for business objects in the ONN model layer; it serves as a "template" or "blueprint" for things. Each ontology class contains: a class identifier, a classpath, a set of attribute definitions, a semantic boundary description, and a set of associated CBC strategies. Ontology classes are divided into entity classes (Nouns, describing static objects such as equipment and personnel) and event classes (Verbs, describing dynamic activities such as process execution and quality inspection).

[0061] Link Class (LC): An abstract type definition of business relationships in the ONN model layer. Each link class contains: a source ontology class, a target ontology class, a relationship cardinality (one-to-one / one-to-many / many-to-many), relationship constraints, and optional attribute definitions. A link class is not just a simple "connection"; it can also attach independent attributes and CBC strategies, becoming a computable semantic entity.

[0062] CBC (Context-Behavior-Constraint) pattern: The unified logical core of ONN, endowing each ontology class and relation class with context awareness, behavior execution, and constraint governance capabilities. Its three dimensions are: Context defines the environmental boundaries and preconditions for behavior and constraint to take effect; Behavior defines the callable operations that encapsulate business logic, described in natural language for easy understanding by AI agents; and Constraint defines the business rule checks that must be passed before executing a behavior.

[0063] Policy (Pol): The carrier unit of CBC patterns. A policy contains a complete set of three-dimensional CBC definitions (contextual conditions, behavioral descriptions, and constraint rules), which can be associated with one or more ontology classes or relation classes. The contextual, behavioral, and constraint descriptions in the policy are in natural language, which AI agents can directly read and understand without reverse engineering the program code.

[0064] Behavior Implementation Layer: This layer acts as an "execution bridge" connecting the ONN semantic world with the enterprise's existing IT and AI capabilities. Each behavior in the strategy is described in natural language at the semantic layer (for easy AI understanding) and can be associated with one or more specific implementations. Implementations are divided into two categories: traditional IT implementations (program code functions: executed directly within the platform; API calls: driving external microservices or enterprise applications such as ERP and MES) and AI-native implementations (Agent workflows: triggering AI agents to complete complex tasks; MCP services: connecting external tools and data sources through model context protocols; A2A collaboration: coordinating execution with other AI agents through inter-agent communication protocols; Skills packages: predefined reusable AI capability modules).

[0065] Instance Inheritance: The core mechanism in the ONN instance network layer. Each ontology instance (OI) automatically inherits all CBC strategies defined in the model layer of its parent ontology class, eliminating the need for redefinition. When the CBC strategy in the model layer changes, the change is automatically propagated to all corresponding instances.

[0066] AI-Native Read-Write Loop: ONN's unique AI interaction mode. The AI ​​agent can achieve a complete "read-understand-write" closed loop in ONN: read CBC natural language descriptions to understand business rules, make inferences and decisions based on understanding, and securely invoke rules-protected behaviors to execute business operations.

[0067] System Memory: In this invention, system memory is a self-evolving object. It is a collection of structured knowledge assets continuously accumulated and updated by multiple learning agents, including: an indicator template library (validated query logic reuse templates), knowledge update records (corrections and supplements to the ONN model layer), a user profile library (personalized understanding configurations for each user), and a hot data cache (a fast response channel for high-frequency queries). System memory is not private data of any particular agent, but rather a public resource that can be consumed and used by all agents.

[0068] Metric Templates: Reusable query logic units extracted from historical queries after passing double-blind quality control verification. A metric template contains a complete OQS (Online Query Specification) structure and a corresponding pipelined DSL (Domain-Specific Language). Metric templates are divided into two categories: fixed metric templates (all parameters of the query question are fixed, directly reusing the complete DSL) and dynamic metric templates (parameters such as object classes, filtering conditions, and extraction fields in the query question are variable, achieving reuse through parameterized placeholders).

[0069] Coverage Score: A quantitative metric that measures the semantic matching degree between a user query and an existing metric template. The coverage score is calculated using a semantic alignment algorithm. When the score exceeds a preset threshold, the system directly retrieves the matching metric template from the hot data cache, without needing to re-execute the ABC parsing and DSL generation process.

[0070] Three-Way Parallel Dispatch: Upon receiving a verified user query, the system simultaneously initiates three processing paths: fixed-indicator hot data retrieval (exact matching), dynamic-indicator hot data retrieval (parameterized matching + semantic alignment), and ABC deep parsing (a completely new parsing). Based on the coverage score of each path, the system selects the optimal result to return, achieving intelligent scheduling of "instant response if hot data is hit, deep parsing if no match is found."

[0071] Knowledge Backward Update: When feedback signals such as quality inspection failure, manual error correction, or business rule changes occur during system operation, the knowledge learning agent systematically analyzes and classifies these feedback signals and updates them back to the ONN model layer (including correcting CBC constraints, supplementing synonym mappings, adding default rules, and improving business knowledge descriptions), so as to continuously refine the ontology semantic network.

[0072] User Profile: A personalized understanding configuration automatically built by the system based on a user's query history. The user profile consists of three dimensions: the user's frequently used ontology categories (which object classes the user typically queries), the user's organization and job description (determining their permissions and perspective), and the user's explicitly requested preferences and habits from past conversations. During the intent clarification phase, the user profile provides personalized contextual supplementation to the AI ​​agent, enabling the system to more accurately understand the user's query intent.

[0073] The QA-Driven Self-Evolution Loop is the core closed-loop mechanism of this invention. Double-blind QA generates two types of signals: query results that pass (high score) trigger the indicator learning agent to be stored as indicator templates; query results that fail trigger the knowledge learning agent to analyze the reasons for errors and update the ONN in reverse. These two types of signals drive the system's "efficiency optimization" and "accuracy correction" respectively, forming a positive cycle.

[0074] exist Figure 1 In this application, an embodiment provides a data query method based on ontology semantic data network and ABC paradigm, including the following steps:

[0075] Construct an ontology semantic data network (ONN);

[0076] Perform natural language query reception and responsiveness verification;

[0077] The scheduling agent is used to distribute the verified tasks to the ABC deep parsing process;

[0078] OQS intermediate representation is generated based on ABC paradigm;

[0079] The OQS is translated into a pipelined DSL by generating an agent using the DSL.

[0080] Execute the pipelined DSL and assemble and return the execution result.

[0081] In the above technical solution, an ontology semantic data network (ONN) is constructed; natural language queries are received and their responsiveness is verified; a scheduling agent is used to distribute verified tasks to the ABC deep parsing process; an intermediate OQS representation is generated based on the ABC paradigm; an agent is generated using a DSL to translate the OQS into a pipelined DSL; the pipelined DSL is executed and the execution result is assembled and returned; thus, the semantic gap is eliminated and the query accuracy is improved.

[0082] Specifically, the beneficial effects include:

[0083] Eliminating the semantic gap and improving query accuracy. By introducing the OQS intermediate representation layer, the query task is broken down into a two-stage transformation of "natural language → OQS → DSL". This allows the large model to focus only on the structured filling of business semantics, without directly generating complex underlying query code. Compared with the direct Text-to-SQL solution, this significantly reduces the probability of query illusions.

[0084] Unsupervised self-checking ensures query credibility. The double-blind quality inspection mechanism of reverse semantic reconstruction enables the system to have "self-reading comprehension" capabilities. It can automatically determine whether the generated query instructions accurately express the user's intent without relying on manually labeled standard answers, effectively intercepting semantic deviations.

[0085] It supports efficient processing of complex graph topologies. The node-edge separated OQS structure reduces the token consumption of graph representation from O(n²) to O(n+e), while decoupling the topology from attribute information, which conforms to the serialization characteristics of large models and significantly improves the accuracy of understanding and generating complex subgraphs such as chains, trees, and stars.

[0086] This achieves decoupling between semantics and execution. The ONN behavior implementation layer separates the business behaviors described in natural language from the underlying program code, so that changes to business rules can be automatically propagated to all instances by only modifying the model layer definition, without modifying the query code or redeploying the system.

[0087] It possesses continuous evolution capabilities. Through three self-growth mechanisms—metric learning, knowledge learning, and user profile analysis—the system's response efficiency and understanding accuracy can continuously improve with increasing usage under normal operating conditions.

[0088] In one specific implementation scheme, the method further includes: performing quality inspection on the execution result based on double-blind quality inspection using reverse semantic reconstruction to obtain the quality inspection result.

[0089] In one specific implementation scheme, it also includes:

[0090] The ontology semantic data network (ONN) is self-grown based on the quality inspection results.

[0091] In one specific implementation scheme, the Ontology Semantic Data Network (ONN) includes an ontology model layer, an instance network layer, and a behavior implementation layer, wherein...

[0092] The model layer uses various types of nodes and relationships to define the CBC pattern.

[0093] In one specific implementation scheme, the self-growth of the ontology semantic data network (ONN) includes:

[0094] Use metrics to learn agents and accumulate high-frequency query templates;

[0095] Utilize knowledge-based learning agents to update ONN model layer constraints and rules;

[0096] Utilize user profiling to analyze agent intent and optimize parameters.

[0097] In one feasible implementation, natural language queries are received and their responsiveness is verified through an intent clarification agent and an intent verification agent.

[0098] In one feasible implementation, the query planning agent, condition filtering agent, field extraction agent, and calculation method agent work together in sequence to generate the OQS intermediate representation based on the ABC paradigm.

[0099] In one specific implementation scheme, the data query method based on ontology semantic data network and ABC paradigm includes the following steps:

[0100] Step S1: Construct the Ontology Semantic Data Network (ONN).

[0101] Building an ONN with a three-layer architecture:

[0102] (a) Ontology Model Layer. Defines the abstract classification (ontology class) of business objects and their attributes, relationship classes and their connection constraints. This layer defines CBC (Context-Behavior-Constraint) patterns for various nodes and relationships. Context defines the conditions under which an object is visible or operable; Behavior defines the operations that an object can perform, described in natural language; Constraint defines the rules that must be met when performing the behavior.

[0103] (b) Instance Network Layer. Stores concrete object instances and relationship instances. Each instance automatically inherits the CBC pattern defined in the model layer of its ontology class. This layer supports the unified mounting of multiple modalities of data, such as structured data, time-series data, text data, and vector data, onto the attributes of object instances, forming holographic data nodes centered on business objects.

[0104] (c) Behavior Implementation Layer. This layer serves as the execution bridge between the ONN semantic world and the actual IT system. Each behavior described in natural language within the model layer can be associated with one or more specific implementation methods, including: a piece of program code or function, an API call from an external system, or an AI Agent workflow. This layer decouples semantic description from computational execution.

[0105] Step S2: Receive user natural language queries and perform intent clarification and intent verification.

[0106] (a) Intent Clarification. The intent clarification agent receives the user's natural language input and completes the omitted information through multiple rounds of dialogue, transforming vague expressions into clear task descriptions.

[0107] (b) Intent Verification. The intent verification agent performs answerability checks based on the ONN model layer, verifying whether the object classes, attribute names, and relationship types involved in the user's question exist in the ONN model layer definition. If the concepts involved are not within the system's knowledge scope, the agent provides feedback to the user on why the query cannot be processed, avoiding the illusion caused by the system forcibly generating a query without knowledge support.

[0108] Step S3: The scheduling agent distributes the tasks.

[0109] The scheduling agent acts as the central hub of the execution layer, distributing query tasks verified in step S2 to step S4 to initiate the ABC deep parsing process.

[0110] Furthermore, the scheduling agent can also initiate hot data retrieval paths in parallel to optimize response efficiency, including: a fixed-indicator hot data retrieval path, which retrieves high-frequency fixed query DSL templates cached in the system and determines whether they cover the user's current query requirements; and a dynamic-indicator hot data retrieval path, which retrieves recently generated semantically similar query DSL templates and determines whether their coverage meets the standards. The hot data cached objects are verified OQS and DSL templates, not the data results after query execution. If the coverage score of the above hot data paths reaches a preset threshold, the cached DSL templates are directly reused to execute the query and return the results, without needing to execute subsequent steps S4 to S6.

[0111] Step S4: Based on the ABC paradigm, multiple dedicated agents collaborate serially to generate OQS.

[0112] The problem analysis process is executed sequentially by the following Agents:

[0113] (a) Query Planning Agent (corresponding to step A). ​​Based on the ontology definition of the ONN model layer, identify the object classes and their topological relationships involved in the user's question, and construct a semantic subgraph.

[0114] (b) Condition Filtering Agent (corresponding to the first stage of step B). For each object class in the subgraph constructed in step A, add filtering conditions to each object class, including conditions explicitly proposed by the user in the question and business default rules defined in the ONN model layer. Further refine and verify the completeness and compliance of the filtering conditions.

[0115] (c) Field Extraction Agent (corresponding to the second stage of step B). Based on the subgraph, determine the specific attribute fields that need to be extracted from each object instance according to the information the user wants to view.

[0116] (d) Calculation Method Agent (corresponding to step C). Based on the extracted fields determined in step B, analyze the implicit or explicit calculation requirements in the user's question, and determine the calculation logic such as aggregation functions, sorting rules, and ratio formulas.

[0117] The collaborative output of the four agents is an OQS (ONN Query Specification), which adopts a structured format with node-edge separation. The node part records the filtering conditions and extracted fields for each object class; the edge part records the relationship type and direction between object classes; and the calculation part records the calculation formulas between the fields.

[0118] The choice of OQS to use a node-edge separation structure instead of an adjacency matrix is ​​based on the following considerations:

[0119] First, the storage space of the adjacency matrix increases by O(n²) with the number of nodes, while the node-edge separation representation is only O(n+e) (n is the number of nodes and e is the number of edges), which significantly reduces the token consumption required for processing large models.

[0120] Secondly, the attention mechanism of large language models is better at handling serialization and tree structures, and its accuracy in understanding the path description method of "source node-relationship-target node" is significantly better than the random access understanding of sparse two-dimensional matrices.

[0121] Third, the node-edge separation structure naturally supports attaching filtering conditions and extraction fields to nodes, thereby decoupling the topology and attribute information.

[0122] Step S5: The DSL-generated Agent translates the OQS into a pipelined DSL.

[0123] The DSL-generating agent reads the OQS and translates it into a pipelined DSL executable by the underlying graph data engine according to the following mapping rules:

[0124] (a) The edge list in OQS is transformed into a graph pattern matching clause in DSL, which defines the path matching between object nodes;

[0125] (b) The filtering conditions of each node in OQS are converted into the Conditions clause in DSL;

[0126] (c) The extracted fields of each node in OQS are converted into the Output Fields clause in DSL;

[0127] (d) The calculation formula in OQS is transformed into pipeline steps in DSL, which supports multi-step chain execution: that is, the output of the previous step can be stored as a temporary table for subsequent steps to use as input reference, thereby realizing complex nested queries and reuse of intermediate results.

[0128] Step S6: Execute the DSL and assemble the results.

[0129] The computation execution agent submits the pipelined DSL to the graph data engine. The engine performs graph pattern matching at the instance network layer of the ONN, sequentially executing subgraph matching, conditional filtering, field extraction, and computation operations according to the pipeline steps, ultimately returning structured data results. The answer response agent assembles the data results into user-understandable responses; the chart / report generation agent visualizes the results as needed.

[0130] Step S7 (optional): Double-blind quality inspection based on reverse semantic reconstruction.

[0131] Furthermore, after executing the DSL and returning the result in step S6, the system can initiate the quality inspection and verification agent to perform the following closed-loop verification process for this query:

[0132] (a) Reverse semantic reconstruction. The quality inspection and verification agent does not accept the user's original question as input, but only the pipeline DSL generated in step S5. The agent interprets the DSL item by item, and reverse-translates the logical elements such as graph pattern matching, condition filtering, and output projection into a complete natural language description (hereinafter referred to as "system understanding description").

[0133] (b) Semantic consistency comparison. The system understanding description is compared with the user's original natural language question in a semantic implication analysis, and the coverage of core elements is compared item by item, including: whether the object classes involved are consistent, whether the filtering conditions are complete, whether the extracted fields match, and whether the relationship path is correct.

[0134] (c) Scoring and Decision-Making. Calculate the semantic consistency score based on the comparison results. If the score reaches a preset threshold (this threshold can be configured according to the fault tolerance requirements of the business scenario, with a default value between 60 and 80 points), the query is deemed semantically correct and the result is valid, and is directly returned to the user; if the score is below the threshold, a semantic deviation is determined, the system marks the query result as unreliable, triggers the correction process to re-execute steps S4 to S6, or initiates clarification and follow-up inquiries with the user.

[0135] Step S8 (optional): System self-growth.

[0136] Furthermore, the system may also include the following continuous evolution mechanisms:

[0137] (a) Metric Learning. The Metric Learning Agent automatically analyzes historical query records, identifies frequently occurring query patterns, and precipitates the corresponding ABC parsing results and DSL templates as standard metrics. These metrics are then incorporated into the hot data query cache layer to improve the response speed of subsequent identical or similar queries.

[0138] (b) Knowledge Learning. The knowledge learning agent receives cases that fail quality inspection and feedback from manual error correction, and updates the constraints, synonym mappings or business default rules in the ONN model layer accordingly, so as to continuously improve the semantic understanding capability of the system.

[0139] (c) User profiling analysis. The user profiling analysis agent learns the query habits and preferences of users with different roles, optimizes the context parameters in the intent clarification stage, and improves the accuracy of intent understanding.

[0140] In one specific implementation scheme, the system of the present invention adopts a three-layer multi-agent cooperative architecture:

[0141] (1) Interaction layer, which includes: Intent Clarification Agent and Intent Verification Agent. It is responsible for receiving, understanding, completing and verifying the business boundary of user intent.

[0142] (2) Execution layer, which is orchestrated and coordinated by the scheduling agent as the central hub, includes:

[0143] Problem Analysis Agent Group: Query Planning Agent (Step A), Condition Filtering Agent (Step B, first stage), Field Extraction Agent (Step B, second stage), Calculation Method Agent (Step C), these four agents work together in sequence to complete the ABC paradigm analysis;

[0144] DSL Query Agent: Translates OQS into Pipeline DSL;

[0145] Computation Execution Agent: Schedules the ONN graph data engine and external computing resources to execute the DSL;

[0146] Quality Inspection Verification Agent: Performs double-blind quality inspection by reversing semantic reconstruction;

[0147] Answer to Agent: Assemble the final answer;

[0148] Chart / Report Generation Agent: Visualizes the results.

[0149] After receiving a task that has been verified by the interaction layer, the scheduling agent initiates three paths in parallel: fixed indicator hot data retrieval, dynamic indicator hot data retrieval, and ABC deep analysis. The final decision on which path to use is based on the coverage score.

[0150] (3) Self-growing layer, including: indicator learning agent, knowledge learning agent and user profile analysis agent. The three extract patterns from historical queries, error correction feedback and user behavior respectively, and continuously update the system's hot database and ONN model layer knowledge.

[0151] In a specific feasible implementation, taking the field of university scientific research management as an example, the following object classes and relation classes are defined in the ONN ontology model layer, as shown in Table 1 and Table 2 respectively:

[0152]

[0153] Table 1 Object Class Definition Table

[0154]

[0155] Table 2 Relationship Class Definition Table

[0156] In the instance network layer, each of the above object classes stores specific instance data. For example, the " / univ_demo / paper" class stores instances of each specific paper, and its attributes not only include structured fields (title, keywords, etc.), but can also attach vector indexes (the full-text vector of the paper associated with the paper_file field).

[0157] In one feasible implementation, the user inputs: "Find papers in the field of artificial intelligence, including the authors, supervisors, institutions, and honors received."

[0158] Intent clarification and intent verification (corresponding to step S2) include:

[0159] After receiving user input, the system aims to clarify the Agent's targeting of the query and complete any implicit conditions. The system log shows:

[0160] "Search target identified: Find papers in the field of artificial intelligence, including authors, supervisors, their institutions, and honors received (using fuzzy matching with the keyword field 'artificial intelligence'; when searching for supervisors' current professional titles, add the condition 'current highest title = yes')."

[0161] The "use keyword field fuzzy matching" and "add whether the current highest = yes" are predefined business default rules in the ONN model layer, which are automatically injected by the intent verification agent. The intent verification agent also confirms that concepts such as "paper", "master's student", "faculty and staff", "organization", "professional title change record" and "talent honors and achievements" all exist in the ONN model layer, and the verification is successful.

[0162] Three-way parallel scheduling (corresponding to step S3) includes:

[0163] The Agent is scheduled to launch three paths in parallel:

[0164] Fixed indicator hot data: Retrieve cached high-frequency fixed query DSL templates, hit 1 content, but the coverage score is insufficient, and it is judged as "insufficient coverage".

[0165] Dynamic indicator hot data: Retrieve recently generated semantically similar query DSL templates, find 1 relevant content, but the coverage score is insufficient, and judge it as "insufficient coverage".

[0166] ABC in-depth analysis: Neither of the two hot data paths met the requirements, so the system continued to analyze the ABC path to complete the analysis.

[0167] ABC paradigm analysis and OQS generation (corresponding to step S4) include:

[0168] Step A — Query the output of the planning agent:

[0169] The query identified six object classes, including: faculty and staff, master's students, papers, organizations, records of changes in professional titles, and talent honors and achievements.

[0170] Step B – The outputs of the conditional filtering agent and the field extraction agent are shown in Table 3:

[0171]

[0172] Table 3 Output Tables of Condition Filtering Agent and Field Extraction Agent

[0173] Step C—Calculate the output of the Agent method:

[0174] This query does not require complex aggregation calculations; instead, it is organized into a detailed wide table based on dimensions such as paper author, supervisor, institution, professional title, and honors.

[0175] The product combination of the above three steps is OQS.

[0176] The following is a complete OQS structure example (JSON format) generated by this query:

[0177] {

[0178] "nodes": [

[0179] {

[0180] "id": "n1",

[0181] "class": "paper",

[0182] "class_path": " / univ_demo / paper",

[0183] "filters": [

[0184] {"field": "keywords", "op": "like", "value": "%Artificial Intelligence%", "source": "User Issues"}

[0185] ],

[0186] "extract_fields": ["title", "abstract", "keywords", "journals","level", "type"]

[0187] },

[0188] {

[0189] "id": "n2",

[0190] "class": "Master's Degree"

[0191] "class_path": " / univ_demo / student_master",

[0192] "filters": [],

[0193] "extract_fields": ["name"]

[0194] },

[0195] {

[0196] "id": "n3",

[0197] "class": "faculty and staff",

[0198] "class_path": " / univ_demo / person",

[0199] "filters": [

[0200] {"field": "status", "op": "=", "value": "Employed", "source": "Business default rule"}

[0201] ],

[0202] "extract_fields": ["name"]

[0203] },

[0204] {

[0205] "id": "n4",

[0206] "class": "organization",

[0207] "class_path": " / univ_demo / org",

[0208] "filters": [],

[0209] "extract_fields": ["name"]

[0210] },

[0211] {

[0212] "id": "n5",

[0213] "class": "Professional Title Change Record",

[0214] "class_path": " / univ_demo / tech_duty",

[0215] }

[0216] }

[0217] In OQS, the nodes section carries the filtering conditions (filters) for step A and the extract fields (extract_fields) for step B in the ABC paradigm, the edges section carries the topological relationships between objects, and the metrics section carries the computation logic for step C. This structure achieves decoupling between topology and attributes, and the token cost is only O(n+e).

[0218] DSL generation (corresponding to step S5) includes:

[0219] The DSL generation agent reads the OQS and generates the following pipelined DSL (JSON format):

[0220] Step 0 — Graph Pattern Matching and Temporary Storage:

[0221] {

[0222] "graph": {

[0223] "patterns": [{

[0224] "objects": [

[0225] {

[0226] "idx": 0, "variable": "paper",

[0227] "class": " / univ_demo / paper",

[0228] "conditions": {

[0229] "properties": {

[0230] "operator": "logic",

[0231] "and": [{"field": "keywords", "operator": "like", "value": "%artificial intelligence%"}]

[0232] }

[0233] }

[0234] },

[0235] {"idx": 1, "variable": "student", "class": " / univ_demo / student_master"},

[0236] {

[0237] "idx": 2, "variable": "teacher",

[0238] "class": " / univ_demo / person",

[0239] "conditions": {

[0240] "properties": {

[0241] "operator": "logic",

[0242] "and": [{"field": "status", "operator": "=", "value": "employed"}]

[0243] }

[0244] }

[0245] },

[0246] Note: In the translation of "在职", it is translated as "employed" here, which is a more common English expression in a general context. If there are specific requirements for this term in a particular field, it may need to be adjusted accordingly. Also, "人工智能" is translated as "artificial intelligence".{"idx": 3, "variable": "org", "class": " / univ_demo / org"},

[0247] {

[0248] "idx": 4, "variable": "tech_duty",

[0249] "class": " / univ_demo / tech_duty",

[0250] "conditions": {

[0251] "properties": {

[0252] "operator": "logic",

[0253] "and": [{"field": "last_flag", "operator": "=", "value": "Yes"}]

[0254] }

[0255] }

[0256] The "to_user": false indicates that the result of this step is not directly returned to the user, but is stored in a temporary table save_table for reference in subsequent steps.

[0257] Step 2 (Step 1) — Result Formatting and Output:

[0258] {

[0259] "graph": {

[0260] "patterns": [{

[0261] "objects": [{"class": " / temp01_ai_paper_...", "variable": "temp01"}]

[0262] }],

[0263] "pattern_logic": "and"

[0264] },

[0265] "output": {

[0266] "to_user": true,

[0267] "fields": [

[0268] {"variable": "temp01", "field": "paper_title", "as": "paper title"},

[0269] {"variable": "temp01", "field": "paper_abstract", "as": "paper abstract"},

[0270] {"variable": "temp01", "field": "paper_keywords", "as": "paper keywords"},

[0271] {"variable": "temp01", "field": "student_name", "as": "paper author"},

[0272] {"variable": "temp01", "field": "teacher_name", "as": "instructor"},

[0273] {"variable": "temp01", "field": "org_name", "as": "affiliated unit"},

[0274] {"variable": "temp01", "field": "teacher_duty", "as": "professional and technical position"},

[0275] {"variable": "temp01", "field": "teacher_duty_level", "as": "job level"},

[0276] {"variable": "temp01", "field": "honor_name", "as": "honor name"},

[0277] {"variable": "temp01", "field": "honor_level", "as": "honor level"},

[0278] {"variable": "temp01", "field": "paper_file", "query": "artificial intelligence", "as": "paper file"} ]

[0280] }

[0281] }

[0282] The "to_user": true field indicates that the result of this step is directly returned to the user. The paper_file field carries the "query": "artificial intelligence" parameter, indicating that semantic relevance filtering is performed on this vector type field.

[0283] The above two steps constitute a complete pipelined DSL. This DSL structure reflects the mapping relationship from OQS to executable instructions: the edge list in OQS corresponds to the relationship array in DSL; the filtering conditions of each node in OQS correspond to the conditions object in DSL; and the extracted fields of each node in OQS correspond to the output.fields array in DSL.

[0284] Executing the DSL and returning the result (corresponding to step S6) includes:

[0285] The computation execution agent submits the aforementioned pipeline DSL to the ONN data engine for execution. The engine sequentially completes subgraph matching, condition filtering, and field extraction according to the pipeline steps, ultimately returning structured data results. The answer response agent assembles the data results into a user-understandable response.

[0286] Double-blind quality control (corresponding to step S7) includes:

[0287] After step S6 is completed and the result is returned, the system starts the quality inspection verification agent. The input to this agent is only the above-mentioned pipeline DSL, and does not include the user's original questions.

[0288] (a) Reverse semantic reconstruction: The quality inspection and verification agent interprets each logical element in the DSL item by item to generate a system understanding description:

[0289] "Search for papers containing the keyword 'artificial intelligence' and related information, including the paper's author (master's student), supervisor (current faculty member), supervisor's institution, current professional title, and high-level talent honors received, ultimately returning formatted detailed information."

[0290] The detailed query logic is listed for each item:

[0291] Retrieve paper data from the / univ_demo / paper category, filtering by keywords containing "artificial intelligence".

[0292] Retrieve master's degree student data from the / univ_demo / student_master class (unconditionally).

[0293] Retrieve faculty and staff data from the ` / univ_demo / person` class, filtering by status "employed".

[0294] Retrieve organization data from the / univ_demo / org class (unconditionally)

[0295] Retrieve professional and technical job titles from the ` / univ_demo / tech_duty` class, filtered by `last_flag=yes`.

[0296] Retrieve talent honors data from the class / univ_demo / szxxsb, filtering by whether gccrc belongs to a specified talent level.

[0297] Relationship connection paths: Master's students - Thesis (own_paper), Faculty and staff - Master's students (person_to_master), Faculty and staff - Organizations (person_to_org), Faculty and staff - Title change records (person_to_tech_duty), Faculty and staff - Talent honors (person_to_szxxsb)

[0298] (b) Semantic consistency comparison: The above system understanding description is compared with the user's original question, "Find papers in the field of artificial intelligence, including the authors, supervisors, their institutions, and honors received," as shown in Table 4.

[0299]

[0300] Table 4 Comparison Table

[0301] (c) Scoring Conclusion: The query logic is completely consistent with the user's intent; all key filtering conditions and relational connections conform to the specifications; and the output fields fully cover all dimensions of the user's needs. Score: 100 points. The judgment is passed; execute the DSL and return the results.

[0302] Self-growing records include:

[0303] The indicator learning agent records the query pattern of "AI paper + author + supervisor + institution + honors". If this pattern appears frequently in subsequent queries, the system will automatically encapsulate its corresponding ABC parsing results and DSL template into a hot data query, and subsequent similar queries can directly return the hot data path.

[0304] In a specific feasible implementation, the pipelined DSL has the following key design features:

[0305] (1) Graph Pattern Matching. The `objects` array defines the object nodes participating in the query. Each node specifies its corresponding ONN ontology class (class field) and filtering conditions (conditions field). `conditions` supports logical combination operations (and / or), and supported operators include: = (equal to), like (fuzzy matching), in (set inclusion), etc. The `relationship` array defines the relationship paths between nodes. Each relationship specifies the starting node index (from), the target node index (to), the relationship type (type), and the hop count range (min_hops, max_hops).

[0306] (2) Output Projection. The fields to be extracted are defined by the output.fields array, and each field specifies the source node (variable), source field name (field), and output alias (as). This mechanism corresponds to the field extraction in step B of the ABC paradigm.

[0307] (3) Step Chaining. The pipelined DSL consists of an ordered array of steps. The output of each step can be set with a to_user flag and a save_table path. When to_user is false, the output of this step is stored in a specified temporary table, which can be referenced by subsequent steps as a new object class, thereby realizing the reuse of intermediate results and multi-level computation.

[0308] (4) Multimodal query support. In output.fields, semantic relevance filtering of vector type fields can be performed by adding query parameters, realizing a combination of structured filtering and vector semantic retrieval query.

[0309] The beneficial effects of the above technical solution include:

[0310] Query accuracy is improved. By using OQS intermediate representation, the single-hop transformation from "natural language → query code" is broken down into a two-hop transformation from "natural language → OQS → DSL". The task complexity of the large model in each hop is greatly reduced, and field errors and path illusions caused by directly crossing semantic gaps are reduced.

[0311] Enhanced interpretability. The results of each step of the system's processing are traceable: the subgraph structure of ABC parsing, the intermediate representation of OQS, the execution logic of DSL, and the comparison report of double-blind quality inspection are all recorded and displayed in a structured form, making it easier for maintenance personnel to locate problems.

[0312] Response efficiency is optimized. A three-way parallel scheduling mechanism allows high-frequency queries to return directly from the hot data cache, eliminating the need to repeatedly execute the complete ABC parsing and DSL generation process. A self-growing mechanism ensures that the coverage of hot data continuously expands as the system is used over time.

[0313] It is highly adaptable to business needs. The separation of the ONN model layer and instance layer means that changes to business rules (such as adjusting the default values ​​of filter conditions) only require modification of the model layer definition, and the changes are automatically propagated to all instances without requiring modification of the query code.

[0314] exist Figure 2 In this application, an embodiment provides a data query system based on ontology semantic data network and ABC paradigm, including:

[0315] The building module is used to construct the ontology semantic data network ONN;

[0316] The verification module is used to receive and verify the responsiveness of natural language queries.

[0317] The scheduling module is used to distribute verified tasks to the ABC deep parsing process using the scheduling agent;

[0318] The ABC module is used to generate OQS intermediate representations based on the ABC paradigm.

[0319] The DSL module is used to generate an agent using DSL to translate OQS into pipelined DSL;

[0320] The execution module is used to execute the pipeline DSL and assemble and return the execution results.

[0321] In the above technical solution, an ontology semantic data network (ONN) is constructed; natural language queries are received and their responsiveness is verified; a scheduling agent is used to distribute verified tasks to the ABC deep parsing process; an intermediate OQS representation is generated based on the ABC paradigm; an agent is generated using a DSL to translate the OQS into a pipelined DSL; the pipelined DSL is executed and the execution result is assembled and returned; thus, the semantic gap is eliminated and the query accuracy is improved.

[0322] In one specific implementation scheme, it also includes:

[0323] The quality inspection module is used to perform quality inspection on the execution result based on double-blind quality inspection of reverse semantic reconstruction, and obtain the quality inspection result.

[0324] In one specific implementation scheme, it also includes:

[0325] The self-growth module is used to perform system self-growth of the ontology semantic data network (ONN) based on the quality inspection results.

[0326] Those skilled in the art will know that this application can be implemented as a system, method, or computer program product.

[0327] Therefore, this disclosure can be implemented in the following forms: it can be entirely hardware, entirely software (including firmware, resident software, microcode, etc.), or a combination of hardware and software, generally referred to herein as a "circuit," "module," or "system." Furthermore, in some embodiments, this application can also be implemented as a computer program product in one or more computer-readable media, the computer-readable media containing computer-readable program code.

[0328] Although embodiments of this application have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting this application. Those skilled in the art can make changes, modifications, substitutions, and variations to the above embodiments within the scope of this application. Based on this, various substitutions and improvements can be made to this application, all of which fall within the protection scope of this application.

Claims

1. A data query method based on ontology semantic data network and ABC paradigm, characterized in that, Includes the following steps: Construct an ontology semantic data network (ONN); Perform natural language query reception and responsiveness verification; The scheduling agent is used to distribute the verified tasks to the ABC deep parsing process; OQS intermediate representation is generated based on ABC paradigm; The OQS is translated into a pipelined DSL by generating an agent using the DSL. Execute the pipelined DSL and assemble and return the execution result.

2. The data query method based on ontology semantic data network and ABC paradigm according to claim 1, characterized in that, Also includes: The execution result is inspected using a double-blind quality inspection based on reverse semantic reconstruction to obtain the quality inspection result.

3. The data query method based on ontology semantic data network and ABC paradigm according to claim 2, characterized in that, Also includes: The ontology semantic data network (ONN) is self-grown based on the quality inspection results.

4. The data query method based on ontology semantic data network and ABC paradigm according to claim 3, characterized in that, The ontology semantic data network (ONN) comprises an ontology model layer, an instance network layer, and a behavior implementation layer, wherein... The model layer uses various types of nodes and relationships to define the CBC pattern.

5. The data query method based on ontology semantic data network and ABC paradigm according to claim 4, characterized in that, The self-growth of the ontology semantic data network ONN includes: Use metrics to learn agents and accumulate high-frequency query templates; Utilize knowledge-based learning agents to update ONN model layer constraints and rules; Utilize user profiling to analyze agent intent and optimize parameters.

6. The data query method based on ontology semantic data network and ABC paradigm according to claim 5, characterized in that, Natural language queries are received and their responsiveness is verified through an intent clarification agent and an intent verification agent.

7. The data query method based on ontology semantic data network and ABC paradigm according to claim 6, characterized in that, By utilizing the query planning agent, condition filtering agent, field extraction agent, and calculation method agent in a sequential collaboration, the intermediate representation of OQS is generated based on the ABC paradigm.

8. A data query system based on ontology semantic data network and ABC paradigm, characterized in that, include: The building module is used to construct the ontology semantic data network ONN; The verification module is used to receive and verify the responsiveness of natural language queries. The scheduling module is used to distribute verified tasks to the ABC deep parsing process using the scheduling agent; The ABC module is used to generate OQS intermediate representations based on the ABC paradigm. The DSL module is used to generate an agent using DSL to translate OQS into pipelined DSL; The execution module is used to execute the pipeline DSL and assemble and return the execution results.

9. The data query system based on ontology semantic data network and ABC paradigm according to claim 8, characterized in that, Also includes: The quality inspection module is used to perform quality inspection on the execution result based on double-blind quality inspection of reverse semantic reconstruction, and obtain the quality inspection result.

10. The data query system based on ontology semantic data network and ABC paradigm according to claim 9, characterized in that, Also includes: The self-growth module is used to perform system self-growth of the ontology semantic data network (ONN) based on the quality inspection results.

Images