A knowledge reasoning method and system

Abstract

The present application relates to the technical field of knowledge graph reasoning, and particularly relates to a knowledge reasoning method and system, comprising: receiving a user query sentence containing a reasoning rule identifier, identifying the reasoning rule identifier according to a preset rule, if the reasoning rule identifier exists, based on the reasoning rule identifier, calling rule definition information containing reasoning condition information and a top rule type from a rule database; if the reasoning condition information contains a nested reasoning rule identifier, converting it into a basic triple pattern set layer by layer through recursive analysis, and then structurally processing the set according to the top rule type to obtain intermediate query elements, combining the original query sentence of the user to generate a query sentence, and executing to obtain a reasoning result. The fixed architecture of the traditional reasoning engine is difficult to adapt to dynamics, resulting in the need to redeploy the engine after updating the rules, and the need to modify the reasoning logic when the data structure changes, thereby limiting the application flexibility and expansion capability of the reasoning engine. The present application has the effect of improving the flexibility and expansion of knowledge reasoning.

Description

Technical Field

[0001] This invention relates to the technical field of knowledge graph reasoning, and in particular to a knowledge reasoning method and system. Background Technology

[0002] Against the backdrop of rapid development in information technology, knowledge graphs, as the core carrier of structured knowledge, have become a key technological support for fields such as intelligent question answering, recommendation systems, and decision support. Through precise modeling of entities and relationships, they enable the systematic storage and efficient querying of massive amounts of knowledge. As the application scenarios of knowledge graphs expand, the complexity of users' reasoning needs continues to increase.

[0003] In existing technologies, inference engines are mostly built on fixed rule sets or specific logic programming languages. They use preset static rules to logically deduce data in knowledge graphs to obtain unknown entity relationships or attribute information. However, in practical applications, the data structure of knowledge graphs changes dynamically with business scenarios, and inference rules also need to be adjusted according to new knowledge logic or business requirements. The fixed architecture of traditional inference engines is difficult to adapt to this dynamism, resulting in the need to redeploy the engine after rule updates and to modify the inference logic extensively when the data structure changes. This greatly limits the application flexibility and scalability of inference engines. Summary of the Invention

[0004] The purpose of this invention is to provide a knowledge reasoning method that improves the flexibility and scalability of knowledge reasoning.

[0005] The above-mentioned objective of this invention is achieved through the following technical solution:

[0006] A knowledge reasoning method, comprising:

[0007] Respond to query requests and receive query statements entered by the user;

[0008] The system determines whether the query statement contains an inference rule identifier based on preset recognition rules.

[0009] If a reasoning rule identifier exists, the corresponding rule definition information is retrieved from the preset rule database based on the reasoning rule identifier. The rule definition information includes reasoning condition information and top-level rule type.

[0010] The reasoning condition information is parsed. If the reasoning condition information contains nested reasoning rule identifiers, the rule definition information corresponding to the nested reasoning rule identifiers is recursively obtained and parsed until all reasoning condition information is converted into a basic set of triplet patterns.

[0011] Based on the top-level rule type, the basic triplet pattern set is structured accordingly to obtain intermediate query elements;

[0012] Based on the intermediate query elements and the query statement entered by the user, the query statement is obtained;

[0013] Execute the query statement to obtain the inference results.

[0014] By adopting the above technical solution, the query statement input by the user is first judged based on the preset recognition rules to identify the inference rule identifier. When an inference rule identifier exists, the corresponding rule definition information is retrieved from the rule database based on the inference rule identifier. For possible nested rules, they are transformed into a basic set of triplet patterns layer by layer through a recursive parsing mechanism, which effectively avoids the problem of logical breakage in complex reasoning scenarios. Then, the top-level rule type is used for structured processing, and the query statement is reconstructed in combination with the original query statement. Finally, the inference result is output based on the query statement, which dynamically adapts to different reasoning needs. This not only ensures the integrity and accuracy of knowledge reasoning, but also greatly improves the flexibility and scalability of knowledge reasoning.

[0015] In a preferred embodiment, the present invention can be further configured as follows:

[0016] Based on preset recognition rules, the system identifies whether the query statement contains inference rule identifiers, including:

[0017] Extract semantic information from the query statement;

[0018] The semantic information is matched with the preset recognition rules. If the match is successful, it is determined that there is a reasoning rule identifier.

[0019] By adopting the above technical solution, when the semantic information of the query statement successfully matches the preset recognition rules, it is determined that there is a reasoning rule identifier, which effectively improves the accuracy of reasoning triggering and enables knowledge reasoning to adapt to different business scenarios.

[0020] In a preferred embodiment, the present invention can be further configured as follows:

[0021] Inference rule identifiers include rule name information;

[0022] If an inference rule identifier exists, the corresponding rule definition information is retrieved from the preset rule database based on the inference rule identifier, including:

[0023] Retrieve the default database rule configuration table;

[0024] Enter the rule name information into the rule configuration table to retrieve the corresponding rule configuration information;

[0025] Extract the rule configuration information to obtain the rule definition information.

[0026] By adopting the above technical solution, the target rule definition information can be quickly located based on the mapping relationship between rule name information and rule configuration table, which not only ensures the accuracy of rule invocation but also improves rule retrieval efficiency.

[0027] In a preferred embodiment, the present invention can be further configured as follows:

[0028] Top-level rule types include relation types;

[0029] Rule definition information includes return definition information and filtering information;

[0030] Based on the top-level rule type, the basic triplet pattern set is structured to obtain intermediate query elements, including:

[0031] If the top-level rule type is a relational type, then extract the logical operators between the triplet patterns in the basic triplet pattern set;

[0032] The initial query element is obtained by combining the returned definition information, the basic set of triplet patterns, and logical operators; the filter information is then transformed to obtain the constraint expression.

[0033] Intermediate query elements are obtained based on constraint expressions and initial query elements.

[0034] By adopting the above technical solution, the logical relationships between triple patterns are extracted by identifying the characteristics of relational rules. The returned definition information is combined with the parsed basic triple patterns to form initial query elements. At the same time, the filtered information is transformed to generate standardized constraint expressions. Finally, these elements are integrated into a complete intermediate query structure. This not only preserves the semantic integrity of the original rules but also optimizes query execution efficiency, effectively improving the flexibility and accuracy of relational knowledge reasoning.

[0035] In a preferred embodiment, the present invention can be further configured as follows:

[0036] Top-level rule types also include attribute types;

[0037] Based on the top-level rule type, the basic triplet pattern set is structured to obtain intermediate query elements, including:

[0038] If the top-level rule type is an attribute type, then extract the logical operators between the triplet patterns in the basic triplet pattern set;

[0039] The basic graph pattern is obtained by combining the triples that are associated through shared variables in the basic triple pattern set.

[0040] The basic graph patterns are logically combined based on logical operators to form the first graph pattern;

[0041] The filtered information is transformed to obtain the constraint expression;

[0042] The target diagram pattern is generated by merging the first diagram pattern with the constraint expression.

[0043] Based on the target graph pattern and the returned definition information, the intermediate query elements are determined.

[0044] By adopting the above technical solution, the characteristics of attribute type rules are identified, the triplet pattern set is traversed to obtain multiple triplets, triplets with shared variables are combined with logical operators to obtain the first graph pattern, the filtering information is transformed to generate standardized constraint expressions, the first graph pattern is merged with the constraint expressions to generate the target graph pattern, and finally the target graph pattern is combined with the returned definition information to obtain the intermediate query element. This not only effectively preserves the semantic details of attribute rules, but also effectively improves query efficiency and the flexibility of knowledge reasoning through optimized combination.

[0045] In a preferred embodiment, the present invention can be further configured as follows:

[0046] Based on the intermediate query elements and the user-input query statement, the query statement is obtained, including:

[0047] The query statement entered by the user is merged with the intermediate query elements to generate an intermediate query statement;

[0048] Perform variable validity checks on intermediate query statements;

[0049] If the verification passes, the intermediate query statement will be determined as the query statement.

[0050] By adopting the above technical solution, the reconstructed intermediate query elements are integrated with the user's original input query statement. This not only preserves the core requirements of the user's original query but also expands the depth of query reasoning. As a result, the final generated intermediate query statement can reflect the user's explicitly expressed query needs and also cover the implicit knowledge associations derived through rule reasoning. This effectively improves the flexibility of knowledge reasoning. Furthermore, the intermediate query statement is subjected to variable validity verification, avoiding query failures caused by variable issues.

[0051] In a preferred embodiment, the present invention can be further configured as follows:

[0052] The query statement entered by the user is fused with intermediate query elements to generate an intermediate query statement, including:

[0053] Parse the user's query to obtain the original graph pattern;

[0054] Traverse each triplet pattern in the original graph pattern to obtain the target triplet pattern containing the inference rule identifier;

[0055] Replace the inference rule identifier in the target triplet pattern with the intermediate query element to obtain the replaced graph pattern;

[0056] The replaced graph pattern is combined with the rest of the original pattern to generate an intermediate query statement.

[0057] By adopting the above technical solution, the user's original query statement is decomposed into an original graph pattern, and the key triplet pattern containing the inference rule identifier is accurately determined. The inference rule identifier is transformed into intermediate query elements after structured processing to obtain the replaced graph pattern. Finally, it is combined with the original graph pattern that has not been replaced. This not only ensures the logical coherence of the generated statement, but also enables the intermediate query statement to accurately express the user's initial query intent, and fully integrate the extended knowledge derived through rule inference, effectively improving the flexibility and accuracy of knowledge inference.

[0058] The second objective of this invention is to provide a knowledge reasoning system that improves the flexibility and scalability of knowledge reasoning.

[0059] The second objective of this invention is achieved through the following technical solution:

[0060] A knowledge reasoning system, comprising:

[0061] The receiving module is used to respond to query requests and receive query statements entered by the user;

[0062] The judgment module is used to determine whether the query statement contains an inference rule identifier based on preset recognition rules;

[0063] The acquisition module is used to retrieve the corresponding rule definition information from the preset rule database based on the inference rule identifier if an inference rule identifier exists. The rule definition information includes inference condition information and top-level rule type.

[0064] The first parsing module is used to parse the inference condition information. If the inference condition information contains nested inference rule identifiers, it recursively obtains and parses the rule definition information corresponding to the nested inference rule identifiers until all inference condition information is converted into a basic set of triplet patterns.

[0065] The second parsing module is used to perform corresponding structured processing on the basic triplet pattern set based on the top-level rule type to obtain intermediate query elements;

[0066] The query building module is used to generate a query statement based on intermediate query elements and the query statement entered by the user;

[0067] The execution engine module is used to execute query statements and obtain inference results.

[0068] By adopting the above technical solution, the receiving module and the judgment module use preset recognition rules to identify the inference rule identifier of the user-input query statement. When the acquisition module detects the inference rule identifier, it retrieves the corresponding rule definition information from the rule database based on the inference rule identifier. The first parsing module, for possible nested rules, uses a recursive parsing mechanism to transform them layer by layer into a basic set of triplet patterns, effectively avoiding the logical breakage problem in complex reasoning scenarios. Then, the second parsing module performs structured processing based on the top-level rule type. The query module reconstructs the query statement based on the original query statement, and the execution engine module executes the query statement to generate the inference result. By dynamically adapting to different inference needs, it not only ensures the integrity and accuracy of knowledge reasoning but also greatly improves the flexibility and scalability of knowledge reasoning.

[0069] The third objective of this invention is to provide a device that improves the flexibility and scalability of knowledge reasoning.

[0070] The above-mentioned objective three of this invention is achieved through the following technical solution:

[0071] An apparatus includes a memory and a processor, wherein the memory stores a computer program capable of being loaded by the processor and executing the knowledge reasoning method described above.

[0072] The fourth objective of this invention is to provide a computer storage medium capable of storing corresponding programs, which facilitates the improvement of the flexibility and scalability of knowledge reasoning.

[0073] The fourth objective of this invention is achieved through the following technical solution:

[0074] A computer-readable storage medium storing a computer program that can be loaded by a processor and executed by any of the aforementioned knowledge reasoning methods.

[0075] In summary, the present invention has at least one of the following beneficial technical effects:

[0076] 1. This invention transforms rule-based reasoning into a native database query execution method. This process dynamically adapts to different reasoning needs. At the same time, by combining nested rule parsing and integrating reasoning rules with query statements, it not only ensures the integrity and accuracy of knowledge reasoning, but also improves the flexibility and scalability of knowledge reasoning as well as the efficiency of complex reasoning tasks.

[0077] 2. When processing relational rules, this invention extracts the logical relationships between triple patterns by identifying their features, combines the returned definition information with the parsed basic triple patterns to form initial query elements, and at the same time transforms the filtering information to generate standardized constraint expressions, and finally integrates them into a complete intermediate query structure. This not only preserves the semantic integrity of the original rules and optimizes the query execution efficiency, but also improves the flexibility and accuracy of relational knowledge reasoning.

[0078] 3. This invention integrates the reconstructed intermediate query elements with the user's original query statement, which not only retains the core requirements of the user's original query, but also expands the depth of query reasoning. This allows the generated intermediate query statement to take into account both the user's explicit query requirements and the implicit knowledge associations derived from rule reasoning, effectively improving the flexibility of knowledge reasoning. Attached Figure Description

[0079] Figure 1 This is a flowchart illustrating the steps of a knowledge reasoning method provided in Embodiment 1 of the present invention.

[0080] Figure 2 This is a reasoning engine architecture diagram of a knowledge reasoning method provided in Embodiment 1 of the present invention.

[0081] Figure 3 This is a flowchart illustrating the steps of another knowledge reasoning method provided in Embodiment 2 of the present invention.

[0082] Figure 4 This is a structural block diagram of a knowledge reasoning system provided in Embodiment 3 of the present invention. Detailed Implementation

[0083] This invention provides a knowledge reasoning method to address the technical problem that the fixed architecture of traditional reasoning engines is difficult to adapt to dynamics, resulting in the need to redeploy the engine after rule updates and to modify the reasoning logic extensively when data structures change, which greatly limits the application flexibility and scalability of reasoning engines.

[0084] To make the objectives, features, and advantages of this invention more apparent and understandable, the technical solutions of the embodiments of this invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the embodiments described below are only some embodiments of this invention, and not all embodiments. Based on the embodiments of this invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this invention.

[0085] It should be noted that the terms "first," "second," etc., used in this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this disclosure described herein can be implemented in orders other than those illustrated or described herein. The implementations described in the following exemplary embodiments do not represent all implementations consistent with this disclosure.

[0086] Furthermore, the term "and / or" in this article is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, or B existing alone. Additionally, the character " / " in this article, unless otherwise specified, generally indicates that the preceding and following related objects have an "or" relationship.

[0087] Example 1:

[0088] It should be noted that the inference engine of this invention comprises, from top to bottom: an application layer, a rule parsing layer, a rule definition layer, a rule execution layer, and a database layer.

[0089] Please see Figure 1 and Figure 2 , Figure 1 This is a flowchart illustrating the steps of a knowledge reasoning method provided in Embodiment 1 of the present invention. Figure 2 This is a reasoning engine architecture diagram of a knowledge reasoning method provided in Embodiment 1 of the present invention.

[0090] This invention provides a knowledge reasoning method, comprising:

[0091] Step 101: Respond to the query request and receive the query statement entered by the user.

[0092] A query response refers to the initial instruction received by the knowledge reasoning engine in response to a user triggering a knowledge query or reasoning task. This request is usually initiated by the user in the front-end application layer (such as a human-computer interaction interface, command-line terminal, or application called via API). In other words, the application layer has a human-computer interaction interface to interact with the user.

[0093] A query statement refers to a string of instructions entered by the user to express the intent of the query. Query statements must conform to the SPARQL specification.

[0094] It is worth mentioning that the application layer performs preliminary validation of the query statement format during the receiving process. If there are syntax errors or missing identifiers, the application layer will return prompt information to the user to correct the input, ensuring that the subsequent rule parsing layer can receive valid input normally.

[0095] Preliminary checks include, but are not limited to, SPARQL syntax integrity checks and basic variable validity checks.

[0096] In this embodiment of the invention, in response to a query request initiated by the user at the application layer, the SPARQL query statement input by the user is accepted.

[0097] Step 102: Identify whether the query statement contains an inference rule identifier based on the preset identification rules.

[0098] The inference rule identifier refers to a unique marker associated with a predefined inference rule.

[0099] The standard format of inference rules is: <rule:rulename>Among them, RULE is a fixed keyword as a signal to start the rule inference engine, and RuleName is a parameter whose value is the unique name of the target inference rule.

[0100] It is worth mentioning that the rule name parameter (RuleName) in the inference rule identifier is a variable parameter, and its specific content corresponds one-to-one with the predefined inference rules in the rule database. By changing this parameter, users can flexibly call different inference logics, which are not specifically defined here.

[0101] The preset recognition rule refers to the logic rule configured in advance to determine whether the query statement contains an inference rule identifier. Based on the fixed format of the inference rule identifier, the matching logic is set to quickly identify the query statement that needs to trigger the inference process.

[0102] It can be understood that taking the example where the user inputs a query statement through the application layer:

[0103] "select?k?name where{?x <name> "Zhang San".?x RULE: uncle?k.?k <name>?name.}" as an example:

[0104] The process of identifying whether there is an inference rule identifier is as follows:

[0105] In the first step, call the preset recognition rule, "traverse the predicate part of all triple patterns in the SPARQL statement to detect whether there is a 'RULE:' prefix.

[0106] In the second step, it is detected that the predicate of the triple "?x RULE: uncle?k." in the statement is "RULE: uncle", which conforms to the preset format of "RULE: RuleName". It is determined that the query statement has an inference rule identifier (the identifier is "RULE: uncle"), and then the subsequent process of "retrieving the rule definition information of 'uncle' from the rule database" is triggered.

[0107] It is worth mentioning that if the user inputs a normal query statement (without an inference rule identifier): "select?y where{<Zhang San> <mother>?y}", after the system detects it through the preset recognition rule and does not find a predicate with a 'RULE:' prefix, it is determined that there is no inference rule identifier, and it is directly sent to the database layer for execution, bypassing the subsequent rule inference process.

[0108] In the embodiment of the present invention, based on the preset recognition rule, the query statement input by the user is judged. If there is an inference rule identifier, the SPARQL statement is transmitted to the rule parsing layer.

[0109] Step 103: If there is an inference rule identifier, obtain the corresponding rule definition information from a preset rule database based on the inference rule identifier. The rule definition information includes inference condition information and a top-level rule type.

[0110] The preset rule database refers to a repository that is pre-configured to store all available inference rule definitions. This database is implemented in the form of a file (such as Rules.json) and is accessed and managed through a rule definition layer. Each rule definition is stored in a structured data format, and its detailed structure can be seen in Table 1, the Basic Structure Table of Inference Rules.

[0111] Table 1: Basic Structure Table of Inference Rules

[0112]

[0113]

[0114] Rule definition information refers to a structured data object that completely describes all the attributes and logics of an inference rule.

[0115] Inference condition information refers to the part in the rule definition information that describes the premise logic of the rule. The inference condition information exists in the form of an array (corresponding to conditions in Table 1). Each group of conditions (condition) is a JSON object that contains patterns, filters, and logical operators (logic).

[0116] The top-level rule type refers to a metadata label that distinguishes the application method of an inference rule. It is a key field in the "rule definition information" (corresponding to type in Table 1) and includes Relation and Property.

[0117] It can be understood that taking the rule identifier <RULE: uncle> as an example:

[0118] The rule parsing layer extracts the rule name uncle from this identifier. Then, the rule definition layer receives this name and queries the JSON object with the name uncle in the Rules.json file to obtain the corresponding inference condition information (such as triples involving mother, sibling, gender, etc.) and the top-level rule type (Relation). The rule definition layer returns this complete rule definition information to the rule parsing layer for subsequent recursive parsing.

[0119] In the embodiment of the present invention, if there is an inference rule identifier, the corresponding inference condition information and top-level rule type are obtained from a preset database based on this identifier, effectively avoiding the blindness of rule invocation.

[0120] Step 104: Analyze the inference condition information. If the inference condition information contains nested inference rule identifiers, recursively obtain and analyze the rule definition information corresponding to the nested inference rule identifiers until all the inference condition information is converted into a basic triple pattern set.

[0121] Analyzing the inference condition information means that the rule parsing layer processes the conditions field in the rule definition information obtained from Step 103, and is used to convert the inference conditions that may contain complex logics into basic triple patterns that can be directly executed by the underlying graph database.

[0122] The nested inference rule identifier refers to other inference rule identifiers (such as <RULE: Sibling>) existing in the patterns array of the current rule. It can be understood that the implementation of the current rule depends on the inference result of another sub-rule.

[0123] The specific process of recursively obtaining and analyzing is as follows:

[0124] The first step: Identify nesting: The parser traverses the patterns array of the current rule and detects whether the elements in it are inference rule identifiers, that is, to judge whether they conform to the <RULE:...> format.

[0125] The second step: Recursive call: For each identified nested identifier, the parser recursively executes Step 103 and Step 104:

[0126] Obtain sub-rule definition: Use the rule name (Sibling) in this nested identifier (such as <RULE: Sibling>) as the key, and call the rule definition layer again to obtain its corresponding rule definition information from the rule database.

[0127] Analyze sub-rule conditions: Recursively execute this parsing process for the conditions in the obtained sub-rule definition information.

[0128] The third step: Replace and expand: Replace the inference rule identifiers in the original patterns array with the basic triple pattern set obtained after recursive parsing of their corresponding sub-rules.

[0129] The fourth step: Termination condition: When there are no longer any inference rule identifiers in the patterns array of a certain rule and all are composed of basic triple patterns, the recursive process terminates.

[0130] The basic triple pattern set refers to the result finally output by recursive parsing, which only contains an array of basic triples and filtering conditions, and all nested rule identifiers have been fully expanded and replaced.

[0131] It is understandable that examples of continuing the "uncle" rule:

[0132] The rule parsing layer starts to parse the conditions of the "uncle" rule and finds that its patterns contain a nested rule identifier. For example, <RULE: sibling>. The parsing process pauses the parsing of the "uncle" rule and instead recursively processes <RULE: sibling> to obtain the rule definition information of the "sibling" rule and parse the conditions of the "sibling" rule. If there is no further nesting in the "sibling" rule, it is converted into a set of basic triple patterns, and <RULE: sibling> in the patterns of the "uncle" rule is replaced with the set of basic triple patterns for "sibling" just obtained. Then, it recursively returns and continues to complete the parsing of the remaining part of the "uncle" rule, finally obtaining a complete set that only contains basic triples and filtering conditions.

[0133] It is worth mentioning that if there is no inference rule identifier containing nesting in the inference conditions, that is, all are composed of basic triple patterns, there is no need to perform recursive operations. Directly read the patterns array and filter array of the current rule to form a set of basic triple patterns, and then proceed to step 105.

[0134] It is understandable that a "father" rule may be directly defined as:

[0135]

[0136] All the elements in the patterns array of this rule are basic triples and do not contain any <RULE:...> identifier. Therefore, the parser does not need to recurse and can directly output it as the final set of basic triple patterns to continue the subsequent process.

[0137] It is worth mentioning that during the recursive parsing process, a variable scope isolation mechanism must be adopted to prevent variable naming conflicts between rules at different levels. Variable naming conflicts refer to the situation that when recursively expanding nested rules, in the triple patterns from rules at different levels, variables with the same name may be used, but these variables represent different meanings in their original rules.

[0138] It is understandable that when replacing the set of basic triple patterns obtained by parsing the sub-rule back into the parent rule, first perform variable scope analysis, that is, extract the set of all variable names used in the sub-rule set and the set of all variable names that already exist in the current scope of the parent rule, and calculate the intersection of the two sets to identify variables that may have naming conflicts. If the intersection is empty, it means there is no variable conflict and direct replacement can be performed. If the intersection is non-empty, for each conflicting variable, the system automatically generates a unique new variable name and then synchronously updates the variable names.

[0139] In this embodiment of the invention, the inference condition information is parsed. If the inference condition information contains nested inference rule identifiers, the rule definition information corresponding to the inference rule identifiers is recursively obtained and parsed until the inference condition information no longer contains nested inference rule identifiers.

[0140] Step 105: Perform corresponding structured processing on the basic triplet pattern set based on the top-level rule type to obtain intermediate query elements.

[0141] The top-level rule type refers to the type of the inference rule that the user initially invokes.

[0142] The corresponding structured processing refers to assembling the flattened set of basic triplet patterns, filtering conditions, and return definition information into query fragments that conform to the SPARQL syntax specification, according to different rule types.

[0143] Intermediate query elements refer to code snippets generated through structured processing that can be directly embedded into the WHERE clause of a SPARQL query. Intermediate query elements are not complete query statements, but rather modules waiting to be integrated with the user's original query.

[0144] It is worth mentioning that this step is completed by the rule execution layer, which receives the basic triplet pattern set from the rule parsing layer and the top-level rule type and return definition information from the rule definition layer, and outputs standardized intermediate query elements according to the above rules.

[0145] In this embodiment of the invention, by solidifying the processing logic of different rule types into a structured processing flow, the business logic expressed by user-defined, complex reasoning rules (including all their nested sub-rules) is completely and accurately converted into standard SPARQL graph pattern fragments that the underlying graph database can natively understand and execute, which greatly improves query efficiency and enhances the flexibility and scalability of knowledge reasoning.

[0146] Step 106: Based on the intermediate query elements and the query statement entered by the user, obtain the query statement.

[0147] The query statement integrates the reasoning logic with the user's original query requirements into a target SPARQL query statement. This statement is the final instruction that can be directly executed in the underlying graph database (such as gStore / topGraph) of the inference engine of this invention to obtain the reasoning results.

[0148] Understandably, let's take the user's original query statement as an example:

[0149]

[0150] The intermediate query element is the triplet pattern and filtering condition obtained after parsing the "uncle" rule. Its logic is equivalent to: {? x < mother> ? y.? y < mother? z.? k < mother> ? z.? k < gender> "male".FILTER(?y!=?k)};

[0151] The target query statement obtained by combining the two is:

[0152]

[0153] In this embodiment of the invention, the intermediate query statement and the user-input query statement are merged to obtain the final query statement that can be directly executed by the underlying graph database of the engine.

[0154] Step 107: Execute the query statement to obtain the reasoning result.

[0155] The inference result refers to the data set returned by the underlying graph database after executing the target query statement.

[0156] Understandably, the engine's database layer receives the fused target query statement issued by the rule execution layer and calls the query interface of the underlying graph database to execute the target query statement. The specific steps are as follows:

[0157] Step 1: Query Distribution: The rule execution layer distributes the generated target query statement to the database layer through the database interface.

[0158] The second step is native execution: The database layer calls the query engine of the underlying graph database. The graph database treats the received target query statement as a standard SPARQL query and executes the query natively using its internal query optimizer, indexes and other components without any additional rule interpretation.

[0159] The third step is result retrieval and return: After the graph database completes the query, it returns the result set to the database layer. The database layer then returns the result layer by layer upwards, and finally presents it to the user through the application layer.

[0160] It is worth mentioning that the final form of the reasoning result is determined by the type of the initial top-level rule: if it is a relational rule, the result is usually a list of entity pairs that satisfy the rule conditions; if it is an attribute rule, the result is usually a list of entities and their corresponding computed attribute values.

[0161] Example following step 106:

[0162]

[0163] The results show that an entity named "Zhang San" deduced two uncles through the "uncle" rule, whose IDs are "Li Si" and "Wang Wu" respectively, and their names are also "Li Si" and "Wang Wu".

[0164] In this embodiment of the invention, the database layer calls the query engine of the underlying graph database to execute a query statement and finally obtains the reasoning result.

[0165] Example 2:

[0166] Please see Figure 3 , Figure 3 This is a flowchart illustrating the steps of another knowledge reasoning method provided in Embodiment 2 of the present invention.

[0167] This invention provides a knowledge reasoning method, comprising:

[0168] Step 201: Respond to the query request and receive the query statement entered by the user.

[0169] The specific implementation process of step 201 is similar to that of step 101, and will not be repeated here.

[0170] In this invention, a query request is responded to by receiving the query statement input by the user.

[0171] Step 202: Extract semantic information from the query statement.

[0172] Extracting semantic information from a query statement refers to the process of parsing and analyzing a received user query statement and extracting key feature information that can characterize its syntactic structure and constituent elements.

[0173] Semantic information includes, but is not limited to, syntactic structure information and text feature information.

[0174] When semantic information is syntactic structure information, the syntactic structure information is obtained by parsing the Abstract Syntax Tree (AST) of the query statement. Specifically, the SPARQL parser is first used to parse the query statement to generate an AST, and then this AST is traversed to extract the predicate part of all triple patterns. Inference rule identifiers are a special type of predicate.

[0175] When the semantic information is text feature information, the text feature information is extracted directly from the query statement string. Specifically, the entire query statement or the extracted predicate list is first treated as a text string, and then regular expressions or string matching algorithms are used to scan these strings to detect whether they contain a preset keyword prefix (such as "RULE:").

[0176] It is worth mentioning that the above two methods can be used independently or in combination to improve the accuracy and robustness of recognition. For example, by first accurately locating all predicates through parsing the AST and then performing text feature matching on these predicates, it is possible to effectively avoid misjudging the text "RULE:" in comments or string literals as an inference rule identifier.

[0177] It can be understood that taking the query statement SELECT?x WHERE {?x <RULE: affiliated team> "Team_A"} as an example:

[0178] Step 1: The SPARQL parser will generate an AST, from which the unique triple pattern (?x, <RULE: affiliated team>, "Team_A") can be accurately extracted, and then its predicate part: <RULE: affiliated team> can be obtained.

[0179] Step 2: Text feature matching: Perform string matching on the extracted predicate "<RULE: affiliated team>", and it is found that it contains "RULE:".

[0180] In the implementation of the present invention, the semantic information extracted from the query statement is the inference rule identifier that the string "RULE:" is included in its predicate list.

[0181] Step 203: Match the semantic information with the preset recognition rules. If the match is successful, it is determined that there is an inference rule identifier.

[0182] The preset recognition rules refer to a set of rules that are pre-configured and used for logical judgment of semantic information. The core is based on the fixed format of the inference rule identifier ( <rule:rulename>The matching logic set by ).

[0183] Understandably, the semantic information extracted in step 202 is used as input and matched with the pattern defined by the preset recognition rules.

[0184] The matching process is as follows:

[0185] Step 1, Rule Definition: The preset recognition rule is defined as: "Determine whether any predicate in the extracted predicate list exists whose string form conforms to the regular expression pattern ^".<RULE:\w+> The '$' symbol, where '^' and '$' represent the beginning and end of the string, ensuring an exact match, 'RULE' is a fixed keyword, and '\w+' is used to match one or more alphanumeric or underscore characters, representing a variable rule name.

[0186] Step 2: Perform matching: Match and validate each element in the predicate list (semantic information) extracted in step 202 against the regular expression pattern described above.

[0187] Step 3: Make a judgment: If a match is successful, that is, one or more completely matching ^ signs are found in the list.<RULE:\w+> If a predicate matches the $ pattern, the query statement is determined to contain an inference rule identifier. The process then proceeds to the rule retrieval step. If the match fails (i.e., none of the predicates in the list conform to the pattern), the query statement is determined to contain no inference rule identifier. The engine will bypass the inference process and directly send the original query statement to the database layer for execution.

[0188] In this invention, the semantic information in the query statement input by the user is obtained and matched with the preset recognition rules to determine whether there is a reasoning rule identifier.

[0189] Step 204: The inference rule identifier includes rule name information;

[0190] Rule name information refers to the core parameters parsed from the complete string of the inference rule identifier, which are used to uniquely identify and retrieve a specific inference rule in the rule database.

[0191] If a reasoning rule identifier exists, the corresponding rule definition information is retrieved from the preset rule database based on the reasoning rule identifier. The rule definition information includes reasoning condition information and top-level rule type.

[0192] In this embodiment of the invention, if a reasoning rule identifier exists, the corresponding reasoning condition information and top-level rule type are obtained from a preset database based on this identifier, effectively avoiding the blindness of rule invocation.

[0193] Preferably, step 204 includes the following sub-steps:

[0194] Step 11: Obtain the preset database rule configuration table.

[0195] The rule configuration table refers to the set of all rule definitions in the structured data file (Rules.json) mentioned above.

[0196] In this invention, a preset database rule configuration table is obtained.

[0197] Step 12: Input the rule name information into the rule configuration table to query and obtain the corresponding rule configuration information.

[0198] Rule configuration information refers to the complete rule definition object in the rule configuration table that successfully matches the query key (i.e., rule name information). This object contains all the configuration attributes of the rule.

[0199] Preferably, the rule configuration information includes, but is not limited to, rule identification information, inference condition information, top-level rule type, return definition information, rule description information, and filtering information.

[0200] Understandably, the query process is as follows:

[0201] The first step is to traverse the rule configuration table in memory and compare the value of the name field of each rule with the input "rule name information".

[0202] The second step is as follows: If the match is successful, it means that a rule object with the same name field value as the input value has been found, and the rule object is returned as "rule configuration information". If the match fails, it means that no corresponding rule name was found after traversing the entire rule configuration table, so an empty value is returned or an exception message "rule not found" is thrown.

[0203] In this invention, the rule name information is entered into the rule configuration table for querying to obtain the corresponding rule configuration information.

[0204] Step 13: Extract rule configuration information to obtain rule definition information.

[0205] In this invention, rule configuration information is extracted to obtain rule definition information that includes inference condition information and top-level rule types.

[0206] Step 205: Parse the inference condition information. If the inference condition information contains nested inference rule identifiers, recursively parse the nested inference rule identifiers until all inference condition information is parsed into a set of basic triplet patterns.

[0207] The specific implementation process of step 205 is similar to that of step 104, and will not be repeated here.

[0208] In this invention, the inference condition information is parsed. If the inference condition information contains nested inference rule identifiers, the rule definition information corresponding to the inference rule identifiers is recursively obtained and parsed until the inference condition information no longer contains nested inference rule identifiers.

[0209] Step 206: Perform corresponding structured processing on the basic triplet pattern set based on the top-level rule type to obtain intermediate query elements.

[0210] In this invention, the basic triplet pattern set is structured based on the top-level rule type to obtain intermediate query elements.

[0211] Preferably, step 206 includes the following sub-steps:

[0212] Top-level rule types include relation types.

[0213] The relation type refers to a specific value of the top-level rule type, which indicates that the corresponding inference rule aims to infer and output a certain semantic relationship between two entities.

[0214] Understandably, the ultimate goal of this type of rule execution is to establish a new, implicit relationship edge between two entity nodes in the knowledge graph.

[0215] The rule definition information includes the return definition information and filtering information.

[0216] The returned definition information is a structured field used to define the final output format of the inference result.

[0217] The returned definition information includes: Source: a variable name that specifies the starting entity in the reasoning relation; Target: a variable name that specifies the target entity in the reasoning relation; and Label: a string that defines the predicate or attribute name of the reasoning result.

[0218] Filtering information refers to a subfield of each condition object in the conditions array of the rule definition information, which is used to impose additional value restrictions on the variables declared in the inference condition information.

[0219] Step 21: If the top-level rule type is a relation type, extract the logical operators between the triplet patterns in the basic triplet pattern set.

[0220] Logical operators are defined in the `logic` attribute of the original rule definition and are used to specify the logical relationships between triplet patterns within a set.

[0221] The specific process for extracting the logical operators between triplet patterns in the basic triplet pattern set is as follows:

[0222] Step 1: Locate the source rule: Based on the top-level rule type, locate the corresponding top-level rule definition information that was initially obtained from the rule database.

[0223] The second step is to read the logical attribute: From the `conditions` field of the top-level rule definition information, read the defined `logic` attribute value. This value is a string, usually "and" (logical AND), indicating that all triplet patterns must be satisfied simultaneously. Some extended implementations may also support other logical relations (such as "or" logical OR).

[0224] Step 3, Logical Transmission: The read logical operators are used as a unified logical relationship to combine all "basic triplet patterns".

[0225] It is worth mentioning that even if a relational rule recursively calls multiple sub-rules, all the output conditions of these sub-rules will be connected according to the "AND" logic specified by the top-level rule when they are finally combined, forming a complete reasoning premise.

[0226] Understandably, taking the "uncle" rule as an example:

[0227] In its rule definition, the logic attribute value under the conditions field is "and". After recursive parsing, its basic triple pattern set contains multiple triples from different nesting levels (such as triples about mother, grandmother, sibling, and gender). All triple patterns in the set are combined into a graph pattern using AND logic.

[0228] In this invention, logical operators between triplet patterns in the basic triplet pattern set are extracted.

[0229] Step 22: Based on the returned definition information, the basic set of triplet patterns, and logical operators, combine them to obtain the initial query elements.

[0230] The initial query element refers to a preliminarily assembled query fragment that conforms to SPARQL syntax.

[0231] The specific combination process is as follows:

[0232] Step 1: Construct the basic graph pattern: Connect all the triplet patterns in the basic triplet pattern set using the logical operators extracted in step 21 to form a complete basic graph pattern.

[0233] The second step is to integrate the returned definitions: integrate the binding relationships corresponding to the core variables defined in the returned definition information into the basic graph pattern mentioned above.

[0234] In this invention, the returned definition information, the basic set of triplet patterns, and logical operators are combined into a semantic query block as the initial query element.

[0235] Step 23: Transform the filtering information to obtain the constraint expression.

[0236] The constraint expression refers to the complete SPARQL FILTER statement generated after the transformation.

[0237] The specific conversion process is as follows:

[0238] Step 1: Traverse the filter array: Process each string element in the "filter information" array one by one.

[0239] The second step is syntax encapsulation: encapsulate each string element into a standard SPARQL FILTER statement format.

[0240] Step 3: Combine the output: If there are multiple filtering conditions in the array, connect all the generated FILTER statements with a newline character or a space to obtain the constraint expression.

[0241] For example, taking the "uncle" rule as an example: Filter information: ["?y!=?k"]; Transformation process: Encapsulate the unique element "?y!=?k" in the array to obtain the constraint expression: FILTER(?y!=?k).

[0242] It's worth noting that this transformation process requires ensuring that all variables referenced in the filter conditions have been declared and used in the basic graph schema contained in the "initial query element". If they are not declared and used, the current rule definition is considered to have an error, the process is terminated, and the process is returned to the application layer.

[0243] In this invention, the original filtering information is converted into filtering instructions that the underlying graph database can directly understand and execute.

[0244] Step 24: Obtain intermediate query elements based on constraint expressions and initial query elements.

[0245] For example, if the initial query element is: {? x<mother>? y.? y<mother>? z.? k<mother>? z.? k<gender>"male".}, and the constraint expression is: FILTER(?y!=?k), then the intermediate query element is {? x<mother>? y.? y<mother>? z.? k<mother>? z.? k<gender>"male".FILTER(?y!=?k)}.

[0246] In this invention, the basic graph pattern and the FILTER statement are combined into a whole by concatenating strings, which serves as an intermediate query element.

[0247] Preferably, step 206 further includes the following sub-steps:

[0248] Top-level rule types also include attribute types.

[0249] The attribute type refers to another specific value of the top-level rule type, which indicates that the corresponding inference rule is intended to calculate and output an attribute value for a certain entity.

[0250] Understandably, the ultimate goal of attribute type execution is not to connect two entities, but to calculate a new attribute value for an entity node in the knowledge graph.

[0251] The rule definition information includes the return definition information and filtering information.

[0252] Step 31: If the top-level rule type is an attribute type, extract the logical operators between the triplet patterns in the basic triplet pattern set.

[0253] The specific implementation process of step 31 is similar to that of step 21, and will not be repeated here.

[0254] In this invention, logical operators between triplet patterns in the basic triplet pattern set are extracted.

[0255] Step 32: Combine the triples that are associated through shared variables in the basic triplet pattern set to obtain the basic graph pattern.

[0256] Shared variable association refers to a triplet pattern that is linked together by the same variable.

[0257] A basic graph pattern refers to one or more combinations that are naturally connected by shared variables.

[0258] The specific steps for combining triples that are related through shared variables in the basic triple pattern set are as follows: First, analyze the variable dependencies between all triple patterns in the basic triple pattern set and identify which triples are related through shared variables.

[0259] The second step is to group all triplet patterns that share at least one common variable into the same group. That is, all relevant conditions that jointly describe an entity attribute are grouped together.

[0260] The third step is to arrange all the triplet patterns in the same group using spaces or newlines to form a syntactically complete SPARQL basic graph pattern.

[0261] Understandably, let's take a "whether you are a senior user" rule as an example:

[0262] ? user <registetdate>?date.

[0263] ?user <points>? points.

[0264] The set of triples contains triple 1 and triple 2. These two triples are related to the "? user" variable. Therefore, they are grouped into the same group, resulting in the basic graph pattern as follows:

[0265]

[0266] In this invention, logically related triple patterns are combined into a semantically meaningful query block, namely the basic graph pattern, which can effectively improve query performance while ensuring semantic correctness.

[0267] Step 33: Logically combine the basic graph patterns based on logical operators to form the first graph pattern.

[0268] The first graph pattern refers to a syntactically complete SPARQL basic graph pattern formed by combining basic graph patterns based on logical operators when processing attribute-based reasoning rules.

[0269] The specific steps for logically combining basic graph patterns are as follows:

[0270] The first step is to read the logical operators extracted from the top-level rules.

[0271] The second step is to perform a logical combination of one or more basic graph patterns generated in step 32, based on the semantics of the operator.

[0272] Understandably, assuming a more complex attribute rule, "Important VIP Customer," its final flattened set of basic triplet patterns contains two non-overlapping sets of variables. Therefore, step 32 will generate two independent basic graph patterns: Basic graph pattern A (derived from a set of triples linked by ?cust, describing consumption information):

[0273] {? cust:totalSpent? amount.? cust:lastOrderDate? orderDate.}

[0274] Basic graph pattern B (derived from another set of triples associated via ?user, describing account information):

[0275] {? user:accountLevel"premium".? cust:hasAccount? user.}

[0276] Logical operator: "and";

[0277] The first diagram pattern is formed as follows:

[0278]

[0279] In this invention, based on business logic and logical operators, the basic graph pattern is integrated to obtain the first graph pattern, which is used to merge multiple independent query contexts into a unified query context through logical operators, thereby enabling the encoding of complex attribute rules.

[0280] Step 34: Transform the filtering information to obtain the constraint expression.

[0281] The specific implementation process of step 34 is similar to that of step 213, and will not be repeated here.

[0282] In this invention, the filtering information is transformed to obtain a constraint expression.

[0283] Step 35: Merge the first diagram pattern with the constraint expression to generate the target diagram pattern.

[0284] The target graph pattern refers to the final, completed SPARQL query fragment constructed for attribute-based rules.

[0285] It is understandable that the string content of the first diagram pattern and the string content of the second constraint expression are concatenated in order, and the combined form is "{[content of the first diagram pattern][second constraint expression]}".

[0286] In this invention, by integrating the data matching pattern (first graph pattern) and the data filtering condition (second constraint expression) into the target graph pattern, the complete semantics of "finding all data in the database that satisfy pattern A, pattern B, and filtering condition C" are clearly expressed, and can be executed independently and correctly by the database engine.

[0287] Step 36: Determine the intermediate query elements based on the target graph pattern and the returned definition information.

[0288] For attribute-based rules, the purpose is to bind an attribute value to an entity. Therefore, the intermediate query element is usually in the form of a BIND expression, which is used to calculate and bind the matching result of the target graph pattern to the specified attribute.

[0289] Based on the target graph pattern and the returned definition information, the specific steps to determine the intermediate query elements are as follows:

[0290] The first step is to obtain the source (target entity variable, such as ?cust) and label (attribute key, such as isVIP) from the returned definition information.

[0291] The second step is to construct a BIND expression based on the complete logic expressed by the target graph pattern, and bind the calculation result (usually a Boolean value or a specific value) to a new variable named by the label.

[0292] The third step is to combine the target graph pattern with the BIND expression to form the final intermediate query element.

[0293] For example, the following definition information is returned: source: ? cust, label: isVIP;

[0294] The target graph pattern is:

[0295]

[0296] The intermediate query element is:

[0297]

[0298] The meaning of this element is: for customers who match the above graph pattern and pass the filtering conditions, bind an attribute isVIP with a value of true to them? cust.

[0299] It is worth mentioning that the intermediate query element can also be in the form of a SELECT query clause, which directly outputs the calculated attribute value.

[0300] In this invention, based on the target graph pattern and the returned definition information, the intermediate query element is determined, clarifying what the output of this segment is and which entity this output belongs to, making the generated query semantics clear, easy to understand and maintain.

[0301] Step 207: Based on the intermediate query elements and the query statement entered by the user, obtain the query statement.

[0302] In this invention, a query statement is obtained based on intermediate query elements and the query statement input by the user.

[0303] Preferably, step 207 includes the following sub-steps:

[0304] Step 41: Perform query fusion processing on the user-input query statement and intermediate query elements to generate an intermediate query statement.

[0305] Query fusion processing refers to the process of replacing the intermediate query element representing the reasoning result with the corresponding reasoning rule identifier in the user's original query statement, thereby generating a complete SPARQL query statement.

[0306] In this invention, the user-input query statement and intermediate query elements are fused together to generate an intermediate query statement.

[0307] Preferably, step 41 includes the following sub-steps:

[0308] Step 410: Parse the user's input query statement to obtain the original graph pattern.

[0309] The original graph pattern refers to the graph pattern portion extracted from the abstract syntax tree and located in the WHERE clause.

[0310] Understandably, when the SPARQL parser is called, the input is the user's query string. The parser will check the syntax of the statement and generate a structured AST. It will traverse the generated AST, locate the syntax node representing the WHERE clause, and extract the subtree of the entire graph pattern structure from the node. This subtree completely encodes all the data matching logic of the user query and outputs it as the "original graph pattern".

[0311] For example, the statement entered by the user is:

[0312]

[0313] Therefore, the parsed original graph pattern is the entire content within the curly braces {} after the WHERE keyword:

[0314]

[0315] It is worth mentioning that this step does not change any semantics of the query statement; it only performs syntax structure parsing and extracts key parts.

[0316] In this invention, the query statement entered by the user is parsed, and all the content within the curly braces of the WHERE keyword is obtained as the original graph pattern.

[0317] Step 411: Traverse each triplet pattern in the original graph pattern to obtain the target triplet pattern containing the inference rule identifier.

[0318] The target triple pattern refers to a specific triple whose predicate part matches the inference rule identifier format during traversal.

[0319] Understandably, starting from the root node of the original graph pattern, each triplet pattern node under it is recursively or iteratively visited. For the currently visited triplet pattern node, the string value of its predicate part is extracted, and the extracted predicate string is matched and verified with the preset recognition rules. If the match is successful, the current triplet pattern is determined to be the target triplet pattern, the node is recorded, and the process is exited or continued. If the match fails, the process continues to traverse the next triplet pattern node.

[0320] In the implementation of the present invention, each triple pattern in the original graph pattern is traversed to obtain a target triple pattern containing an inference rule identifier.

[0321] Step 412: Replace the inference rule identifier in the target triple pattern with an intermediate query element to obtain a replaced graph pattern.

[0322] The replaced graph pattern refers to a new graph pattern obtained after the replacement operation.

[0323] It can be understood that the entire predicate part (i.e., the inference rule identifier) of the triple pattern node is replaced with a placeholder or directly deleted to prepare for receiving new content, and then the syntax tree of the intermediate query element is inserted into the position in the AST where the target triple pattern node was just located, ensuring that the newly inserted graph pattern is correctly connected to other parts in the original graph pattern, thereby obtaining the replaced graph pattern.

[0324] Exemplarily, the target triple pattern:?x < RULE: uncle >?K;

[0325] The intermediate query element is:

[0326]

[0327] Replace?x < RULE: uncle >?K in the entire target triple with the above intermediate query element to obtain the replaced graph pattern:

[0328] In the implementation of the present invention, replacing the inference rule identifier in the target triple pattern with an intermediate query element to obtain a replaced graph pattern effectively avoids syntax errors that may be caused by string concatenation and greatly improves the accuracy of inference.

[0329] Step 413: Combine the replaced graph pattern with the remaining parts in the original pattern to generate an intermediate query statement.

[0330] The remaining parts in the original pattern refer to all other syntactic components except the graph pattern in the WHERE clause.

[0331] Preferably, the remaining parts include but are not limited to the SELECT clause, GROUP BY clause, HAVING clause, ORDER BY clause, etc.

[0332] It can be understood that from the abstract syntax tree (AST) parsed in step 401, the syntactic nodes of non-graph pattern parts such as SELECT and GROUP BY are extracted, integrated with the graph pattern replaced in step 412, and the integrated complete AST is serialized (i.e., converted) back to the standard SPARQL query string format.

[0333] It is worth mentioning that this step, which involves structured assembly at the syntax tree level, fundamentally guarantees the absolute syntactic correctness of the generated "intermediate query statement" and avoids any syntax errors that might result from manual splicing.

[0334] In this invention, the replaced graph pattern is combined with all other syntactic components except the graph pattern in the WHERE clause to generate a standard SPARQL query string format.

[0335] Step 42: Perform variable validity checks on the intermediate query statements.

[0336] Variable validity verification refers to performing static analysis on the intermediate query statement generated in step 41 to check whether the declaration and use of all variables conform to the semantic rules of the SPARQL language, in order to prevent query execution failure due to incorrect rule definition or variable problems introduced during the fusion process.

[0337] Variable validity checks include, but are not limited to, variable scope checks and variable naming conflict checks.

[0338] Variable scope checking is used to ensure that each variable used in a query has been correctly defined and bound within its current scope.

[0339] Variable naming conflict checking is used to ensure that there is no semantic confusion caused by duplicate variable names during query fusion.

[0340] Understandably, the intermediate query statement is parsed again to generate an AST. The AST is traversed to build a variable symbol table, which records the definition and usage of each variable. Based on the symbol table, it is checked whether each variable usage has a corresponding variable binding statement that is syntactically preceding it.

[0341] In this invention, variable validity is validated for intermediate query statements, and the timing of detecting rule configuration errors is moved from query runtime to query construction, thus avoiding performance waste caused by submitting erroneous queries to the underlying database.

[0342] Step 43: If the verification passes, the intermediate query statement is determined as the query statement.

[0343] If the validation passes, it means that all variables are valid, and the intermediate query statement is then determined as the query statement.

[0344] It is worth mentioning that if the verification fails, i.e., if an unbound variable or scope error is found, the verification is deemed to have failed, the process will be aborted, and a clear error message will be returned to the application layer.

[0345] In this invention, if the verification passes, the intermediate query statement is determined as the query statement.

[0346] Step 208: Execute the query statement to obtain the reasoning result.

[0347] The specific implementation process of step 208 is similar to that of step 107, and will not be repeated here.

[0348] In this invention, a query statement is executed to obtain the reasoning result.

[0349] Example 3:

[0350] Please see Figure 4 , Figure 4 This is a structural block diagram of a knowledge reasoning system provided in Embodiment 3 of the present invention.

[0351] This invention provides a knowledge reasoning system, comprising:

[0352] The receiving module 101 is used to respond to query requests and receive query statements input by the user.

[0353] The judgment module 102 is used to identify whether the query statement has an inference rule identifier based on preset recognition rules.

[0354] The acquisition module 103 is used to obtain the corresponding rule definition information from the preset rule database based on the inference rule identifier if an inference rule identifier exists. The rule definition information includes inference condition information and top-level rule type.

[0355] The first parsing module 104 is used to parse the inference condition information. If the inference condition information contains nested inference rule identifiers, it recursively obtains and parses the rule definition information corresponding to the nested inference rule identifiers until all inference condition information is converted into a basic set of triplet patterns.

[0356] The second parsing module 105 is used to perform corresponding structured processing on the basic triplet pattern set based on the top-level rule type to obtain intermediate query elements.

[0357] The query building module 106 is used to obtain a query statement based on intermediate query elements and the query statement entered by the user.

[0358] The execution engine module 107 is used to execute query statements and obtain inference results.

[0359] Since the above is a system that corresponds one-to-one with a knowledge reasoning method, its implementation principle and knowledge reasoning method will not be elaborated here.

[0360] Example 4:

[0361] An electronic device according to an embodiment of the present invention includes: a memory and a processor, wherein the memory stores a computer program; when the computer program is executed by the processor, the processor performs a knowledge reasoning method as described in any of the above embodiments.

[0362] The memory can be an electronic memory such as flash memory, EEPROM (Electrically Erasable Programmable Read-Only Memory), EPROM, hard disk, or ROM. The memory has storage space for program code used to perform any of the method steps described above. For example, the storage space for program code may include individual program codes for implementing the various steps in the methods described above. This program code can be read from or written to one or more computer program products. These computer program products include program code carriers such as hard disks, compact discs (CDs), memory cards, or floppy disks. The program code may be compressed, for example, in a suitable form. When run by a computing processing device, this code causes the computing processing device to perform the various steps in the methods described above.

[0363] Example 5:

[0364] This invention provides a computer-readable storage medium storing a computer program thereon, which, when executed, implements the knowledge reasoning method as described in any embodiment of this invention.

[0365] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0366] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be an indirect coupling or communication connection between apparatuses or units through some interfaces, and may be electrical, mechanical, or other forms.

[0367] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0368] Furthermore, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0369] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0370] The above-described embodiments are only used to illustrate the technical solutions of the present invention, and are not intended to limit it. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention.< / points> < / registetdate> < / rule:rulename> < / rule:rulename>

Claims

1. A knowledge reasoning method, characterized in that, include: Respond to query requests and receive query statements entered by the user; Based on preset recognition rules, it is determined whether the query statement input by the user exists as an inference rule identifier, wherein the inference rule identifier refers to a unique marker associated with a preset inference rule; If a reasoning rule identifier exists, the corresponding rule definition information is retrieved from the preset rule database based on the reasoning rule identifier. The rule definition information includes reasoning condition information and top-level rule type. The inference condition information is parsed. If the inference condition information contains nested inference rule identifiers, the rule definition information corresponding to the nested inference rule identifiers is recursively obtained and parsed until all inference condition information is converted into a basic triplet pattern set. The basic triplet pattern set is the final output of the recursive parsing, which contains only an array of basic triplets and filtering conditions. All nested rule identifiers have been fully expanded and replaced. Based on the top-level rule type, the basic triplet pattern set is subjected to corresponding structured processing to obtain intermediate query elements. The top-level rule type is the type of the inference rule initially invoked by the user, and the top-level rule type includes relation type and attribute type. Based on the intermediate query elements and the query statement entered by the user, the target query statement is obtained, including: The query statement input by the user and the intermediate query elements are fused together to generate an intermediate query statement; Perform variable validity checks on the intermediate query statement; If the verification passes, the intermediate query statement will be determined as the target query statement; Execute the target query statement to obtain the inference result; The query statement input by the user and the intermediate query elements are fused to generate an intermediate query statement, including: Parse the query statement entered by the user to obtain the original graph pattern; Traverse each triplet pattern in the original graph pattern to obtain the target triplet pattern containing the inference rule identifier; The inference rule identifier in the target triplet pattern is replaced with the intermediate query element to obtain the replaced graph pattern; The replaced graph pattern is combined with the rest of the original graph pattern to generate an intermediate query statement.

2. The knowledge reasoning method according to claim 1, characterized in that, Based on preset recognition rules, the system identifies whether the query statement contains inference rule identifiers, including: Extract semantic information from the query statement; The semantic information is matched with the preset recognition rules. If the match is successful, it is determined that there is a reasoning rule identifier.

3. The knowledge reasoning method according to claim 1, characterized in that, Inference rule identifiers include rule name information; If an inference rule identifier exists, the corresponding rule definition information is retrieved from the preset rule database based on the inference rule identifier, including: Retrieve the default database rule configuration table; Enter the rule name information into the rule configuration table to retrieve the corresponding rule configuration information; Extract the rule configuration information to obtain the rule definition information.

4. The knowledge reasoning method according to claim 1, characterized in that, The rule definition information also includes the returned definition information and filtering information; Based on the top-level rule type, the basic triplet pattern set is structured to obtain intermediate query elements, including: If the top-level rule type is a relational type, then extract the logical operators between the triplet patterns in the basic triplet pattern set; The initial query element is obtained by combining the returned definition information, the basic set of triplet patterns, and logical operators. The filtered information is transformed to obtain the constraint expression; Intermediate query elements are obtained based on constraint expressions and initial query elements.

5. The knowledge reasoning method according to claim 4, characterized in that, Based on the top-level rule type, the basic triplet pattern set is structured to obtain intermediate query elements, which also include: If the top-level rule type is an attribute type, then extract the logical operators between the triplet patterns in the basic triplet pattern set; The basic graph pattern is obtained by combining the triples that are associated through shared variables from the basic set of triple patterns. The shared variable association means that the triple patterns are connected together through the same variable. The basic graph patterns are logically combined based on logical operators to form the first graph pattern; The filtered information is transformed to obtain the constraint expression; The constraint expression is combined with the first graph pattern to generate the target graph pattern; Based on the target graph pattern and the returned definition information, the intermediate query elements are determined.

6. A knowledge reasoning system, characterized in that, The system for implementing the knowledge reasoning method as described in claim 1 includes: The receiving module is used to respond to query requests and receive query statements entered by the user; The judgment module is used to determine whether the query statement input by the user has an inference rule identifier based on preset recognition rules; The acquisition module is used to retrieve the corresponding rule definition information from the preset rule database based on the inference rule identifier if an inference rule identifier exists. The rule definition information includes inference condition information and top-level rule type. The first parsing module is used to parse the inference condition information. If the inference condition information contains nested inference rule identifiers, it recursively obtains and parses the rule definition information corresponding to the nested inference rule identifiers until all inference condition information is converted into a basic set of triplet patterns. The second parsing module is used to perform corresponding structured processing on the basic triplet pattern set based on the top-level rule type to obtain intermediate query elements; A query construction module is used to obtain a target query statement based on the intermediate query elements and the query statement input by the user; The execution engine module is used to execute the target query statement and obtain the reasoning result.

7. A device, characterized in that, It includes a memory and a processor, wherein the memory stores a computer program that can be loaded by the processor and executed as any one of the knowledge reasoning methods as claimed in claims 1 to 5.

8. A computer-readable storage medium, characterized in that, The computer program is stored that can be loaded by a processor and executed as any one of the knowledge reasoning methods as claimed in claims 1 to 5.

Images