A supply chain supervision rule conflict detection method based on topological sorting and constraint solving

Abstract

The present invention belongs to the field of knowledge graph rule conflict detection and discloses a rule conflict detection method and system based on topological sorting and constraint solving, which is used to judge the legality and rationality of rules and regulations in enterprise supply chain management systems. The present invention adopts a rule parsing method based on an abstract syntax tree (AST) to parse a rule string written in Datalog syntax into JSON format and semantically associate it with an existing rule set. When adding or modifying a rule in a rule set, the rule set is tested for terminology semantic inconsistency conflicts. If there is no conflict, the addition or modification is successful; otherwise, an error message is displayed and the addition or modification is not performed. A topological sorting method is used to detect whether dependency loop conflicts occur in the rule set to prevent rule reasoning from falling into deadlock. The concept of constraint solving is introduced to detect whether there are mutually exclusive rules in the rule set to avoid errors in the rule reasoning process, thereby ensuring the correctness of rule reasoning.

Description

Technical Field

[0001] The present invention belongs to the field of rule reasoning in computer technology knowledge graphs, and in particular relates to a rule conflict detection method and system based on topological sorting and constraint solving. Background Art

[0002] As the rules in enterprise supply chain management systems become increasingly complex, the monitoring of compliance indicators becomes particularly important. Compliance supervision requires not only strict compliance with relevant laws and regulations, but also compliance with the rules and regulations formulated within the organization. Therefore, in the enterprise supply chain management system, the rules set within the system may have logical loops or conflicts, especially when the rules overlap or the conditions contradict each other. For example, a purchase order may meet multiple review criteria at the same time, and the judgment results of these criteria may conflict, such as the same order is considered compliant under certain conditions, but non-compliant under other conditions. In this case, how to reasonably set and adjust the rules to prevent logical loops and rule conflicts has become the problem to be solved by the present invention.

[0003] Despite the rapid development of knowledge reasoning, most reasoning applications lack sufficient integration with external knowledge. Furthermore, rules require prior analysis of the knowledge structure before they can be defined, often requiring manual code implementation. Reasoning applications using logic programming languages, such as Datalog, lack explicit associations between rules and knowledge. Without semantics, Datalog rules cannot automatically detect semantic inconsistencies during rule modeling. For example, for two functions, function(X) and function(Y), it is impossible to determine whether X and Y refer to the same ontology or concept. Furthermore, rule semantics cannot be used to automatically load external knowledge during reasoning. For example, if a function in a rule uses weight[X], which is associated with an ontology attribute, the rule lacks knowledge graph semantics and cannot automatically identify which ontology and attribute X and weight belong to. Consequently, the relevant attribute values ​​cannot be automatically imported from the knowledge graph, resulting in poor integration with the knowledge graph. Optimizing rule modeling to strongly associate external knowledge with rules and to leverage this external knowledge for reasoning applications remains a hot topic and a technical challenge. At the same time, traditional rule base modeling and reasoning methods also have some problems, such as the difficulty in handling rule conflicts and the difficulty in maintaining rules, which are also problems to be solved.

[0004] Therefore, in response to these limitations of current knowledge graphs and rule reasoning, the present invention can model rules based on external knowledge, realize semantic association between rules and external knowledge, and automatically import fact data from external knowledge based on semantic association, while also supporting manual import of external fact data. In the rule set, conflicts are detected for newly imported rule pairs. The present invention provides a more convenient and efficient rule conflict detection method for enterprise supply chain management systems. This method is suitable for complex scenarios and situations with complex data, can quickly locate problem points for users, and has broad application value and practical significance. Summary of the Invention

[0005] In view of the limitations of current rule reasoning in knowledge graphs and the shortcomings of technology, this paper proposes a supply chain supervision rule conflict detection method based on topological sorting and constraint solving to increase the rationality and correctness of rule reasoning in knowledge graphs.

[0006] To achieve the above objectives, the technical solution of the present invention is: a supply chain supervision rule conflict detection method based on topological sorting and constraint solving, characterized by comprising:

[0007] (1) A rule parsing method based on the abstract syntax tree (AST) is adopted to parse the enterprise supply chain management rule string written in Datalog syntax into JSON format, semantically associate it with the rule set, and automatically complete the rule information.

[0008] 1.1) Define different forms of data parsing logic for rule strings of different types of rules, mainly including function type rules, attribute type rules, constant equation type rules, and mixed type rules.

[0009] 1.2) Using abstract syntax tree technology, write a node traversal method to traverse to find the first node you need, then use this as the root node and recursively traverse downward until all nodes are found.

[0010] 1.3) Determine the processing logic during traversal based on different node types and record the required information. Add a memory function so that if the newly added rule term or function appears in the rule set, this information will be automatically completed during parsing.

[0011] 1.4) Semantically associate the function and parameters or term information of the parsed rule. If the rule to be parsed exists in the rule set, the field completion is performed using the memory module described above, and this step is skipped. Otherwise, the function name is matched with the attribute fields of the ontology by searching the corresponding knowledge graph. If a match is successful, the ontology information is added to the function, associating the function with the ontology. If a match fails, the association information between the function or term and the ontology can be manually filled in later to achieve the ontology association of the function and term.

[0012] (2) When adding or modifying rules in the rule set, perform conflict detection for term semantic inconsistency in the rule set. If there is no conflict, the addition or modification is successful; otherwise, an error message is given and the addition or modification is not allowed.

[0013] 2.1) Use a hash table to record the positions and information of the parameters of all rules in the rule set, forming a HashMap1 of <function name, <parameter position, term information>>.

[0014] 2.2) Perform the same processing on the rule to be added / modified to form a HashMap2 of <function name, <parameter position, term information>>.

[0015] 2.3) For the conclusion and preconditions of the rule to be added / modified, determine whether there is a key value in the HashMap1 generated in the first step that has the same function name as the rule to be added / modified. If not, it means there is no function with the same semantics in the rule set, and the addition / modification is directly performed; otherwise, go to the next step (4).

[0016] 2.4) If the rule to be added / modified and the function with the same semantics in the rule set have ontology information, it is necessary to detect whether there is a term conflict; when the rule to be added / modified and the function with the same semantics in the rule set carry ontology information, the term conflict is detected. Detect whether the ontology information of the corresponding position parameters is consistent. Here, two cases need to be processed: one of the functions with the same semantics has incomplete term ontology information; the term ontology information of the functions with the same semantics is complete. Taking function(A, B) and function(C, D) as an example, a piece of information is recorded in the above HashMap1: <function, <1, term information of A>> and <function, <2, term information of B>>, and a piece of information is recorded in the above HashMap2: <function, <1, term information of C>> and <function, <2, term information of D>>. At this time, compare whether the ontology information corresponding to the same parameter positions is the same to determine whether there is a term conflict.

[0017] 2.5) If the rule to be added / modified does not have ontology information, there cannot be a term conflict situation. At this time, according to the transitivity of the function, we can consider that the ontology of the terms of the function of the rule to be added / modified is completely consistent with that of the function with the same semantics. Then, complete the term information of the rule to be added / modified according to the term information of the function with the same semantics in the rule set. <000003८>(3) Use the method of topological sorting to detect whether there is a dependency loop conflict in the rule set to prevent the rule reasoning from falling into deadlock.

[0019] 3.1) Pre-add the rules to be added to the rule set, or pre-modify the rules to be modified to obtain a rule set to be tested.

[0020] 3.2) Traverse the rule set to build a directed graph, where the nodes are all the conditions in the rules and the edges point from the conclusion to the precondition.

[0021] 3.3) Perform topological sorting on the formed graph, continuously deleting nodes with in-degree 0. If there are still nodes left that cannot be deleted, it can be determined that there is a cycle in the graph and the remaining nodes constitute this cycle. Return the node information where the cycle occurs. Otherwise, there is no cycle in the graph and the rule is successfully added or modified.

[0022] (4) Introduce the idea of ​​constraint solving to detect whether there are mutually exclusive rules in the rule set to avoid errors in the rule reasoning process.

[0023] 4.1) Create conditional variables. Pre-add the rules to be added to the rule set. Then, traverse the rule set and create conditional variables for each rule's precondition and conclusion, forming a list of conditional variables. Build a constraint solver, compile the conditions in the conditional variable list into constraints, and add them to the constraint solver to form a constraint model.

[0024] 4.2) Use a hash table to record identical copies of functions with the same semantics. Processing the list obtained in step 1, since the conditions in the rule contain functions with the same semantics, these identical functions or conditions with the same semantics need to be processed so that they only point to the same condition variable. Otherwise, the constraint solver will fail. This is achieved using a hash table with the structure <condition function name, corresponding condition variable>.

[0025] 4.3) Adding Mutual Exclusion Constraints. Traverse the hash table obtained in step 3. If there are mutually exclusive conditions such as A and ~A, add a mutual exclusion constraint to it and add it to the constraint model. For example, if the constraint expression of the above condition is (A + ~A == 1), it means that A and ~A cannot be true at the same time.

[0026] 4.4) Create rule reasoning constraints. Traverse the rule set and create constraints where preconditions => conclusions. Use if (preconditions) then (conclusions) to represent the constraints and add them to the constraint model.

[0027] 4.5) Solve the constraint model and output a feasible solution, where each conditional variable is either true or false. If a feasible solution is output, it indicates that there are no mutually exclusive rules and the rule set is successfully updated. Otherwise, the process fails and a mutual exclusion conflict message is returned.

[0028] Compared to existing technologies, the present invention offers the following advantages: Traditional reasoning applications typically only check for duplicates when determining the validity of rule sets, without addressing potential rule conflicts. However, conflicts within a rule set can result in inference failure or incorrect conclusions, potentially leading to decision failures and serious consequences. Therefore, ensuring the absolute correctness of rule sets is essential.

[0029] To ensure the correctness of the rule set and reasoning, the present invention adopts a conflict detection solution that combines topological sorting and constraint solving. Before each rule is added or modified, the rule set is tested to ensure that conflicts and errors will not occur. Conflict detection mainly includes term conflict detection and rule conflict detection (dependency loops, rule condition mutual exclusion, etc.). Term conflict detection ensures that functions with the same semantics but different corresponding entities do not appear in the rule set. Rule conflict detection ensures that mutually exclusive rules cannot coexist in the rule set, thereby avoiding errors in the reasoning process and ensuring the correctness of the reasoning. BRIEF DESCRIPTION OF THE DRAWINGS

[0030] In order to more clearly illustrate the technical solutions of the embodiments of the present application, the following is a brief introduction to the drawings required for use in the embodiments of the present application. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0031] Figure 1 It is the rule parsing and semantic association of the present invention; Figure 2 This is the terminology semantic inconsistency conflict detection process in the present invention; Figure 3 is a rule cycle dependency graph in the present invention; Figure 4 It is the rule mutually exclusive graph in the present invention. DETAILED DESCRIPTION

[0032] In order to make the purpose, technical solutions and advantages of the present invention more clearly understood, the present invention is further described in detail below in conjunction with the embodiments. It should be understood that the specific embodiments described herein are only used to explain the present invention and are not intended to limit the present invention.

[0033] In order to solve the problems in the existing technology, the present invention provides a supply chain supervision rule conflict detection method based on topological sorting and constraint solving. The present invention is described in detail below with reference to the accompanying drawings. In the strategy set up in the "digital logistics system" of a certain power company, there is a rule:

[0034]

[0035]

[0036] According to the above rules, the supply chain supervision rule conflict detection method based on topological sorting and constraint solving of the present invention includes the following steps:

[0037] (1) A rule parsing method based on abstract syntax tree (AST) is used to parse the rule string written in Datalog syntax into AST form and semantically associate it with the knowledge graph, such as Figure 1 shown.

[0038] 1.1) Define different forms of data parsing logic for rule strings of different types of rules, mainly including function type rules, attribute type rules, constant equation type rules, and mixed type rules.

[0039] Rules for function types:

[0040] Still in warehouse (Goods) <= Issued (Goods) & ~ Actual use (Goods)

[0041] Rules for attribute types:

[0042] Still in warehouse (Goods) <= ((Outgoing status [Goods] == 'Outgoing') & (Receiving status [Goods] == 'Unreceived'))

[0043] Rules for constant equality types:

[0044] Still in warehouse (Goods) <= (Goods == 'Transformer') & (Issuance status [Goods] == 'Unissued')

[0045] And the rules for mixed types:

[0046] Still in warehouse (Goods) <= (Shipment (Goods) & (Goods == 'Transformer') & Received status [Goods] == 'Unreceived'])

[0047] Among them, Goods means that the material has completed the release procedure in the system, including the quantity released; Actual Used (Goods) means the quantity of a material actually used; Still in Warehouse (Goods) means that although a material has been released, it is still stored in the warehouse and has not been released; Virtual Release (Goods) means that a material has been falsely released; Need Inventory (Goods) means that a material needs to be counted.

[0048] 1.2) Using abstract syntax tree technology, write a node traversal method to traverse to find the first node you need, then use this as the root node and recursively traverse downward until all nodes are found.

[0049] By using Python's abstract syntax tree (AST) technology to traverse and analyze code structures, inheriting NodeVisitor and overriding specific traversal node methods, you can perform custom operations on specific statements or expressions. For the example of mixed-type rules above, you need to overwrite traversal methods such as visit_Call, visit_Compare, and visit_BinOp. By overriding the visit_Call method, you can identify and process function call nodes, such as identifying the call of the function "Still in Warehouse (Goods)"; by overriding the visit_Compare method, you can process comparison operation nodes, such as parsing and processing comparison expressions such as "(outbound status [Goods] == 'outbound') & (issued status [Goods] == 'unissued')"; by overriding the visit_BinOp method, you can process binary operator nodes, which are used to analyze and traverse complex expressions containing logical AND operators such as "Still in Warehouse (Goods) <= (outbound (Goods) & (Goods == 'transformer') & issue status [Goods] == 'unissued')"

[0050] Since the AST parsed result is a tree structure, you can traverse to the first node you need, then use it as the root node and recursively traverse downward until all nodes are found. In the example of mixed-type rules above, when traversing the comparison operator &, it will first be processed into the form (out of inventory (Goods) & A), and then continue traversing the child nodes of A to access and process the contained logical operators.

[0051] 1.3) Determine the processing logic during traversal based on different node types and record the required information. Add a memory function so that if the newly added rule term or function appears in the rule set, this information will be automatically completed during parsing.

[0052] For the example of the above mixed type rule, when traversing function type nodes, it is necessary to record the function name and all its parameter information, use the isInstance method to determine the type of the traversed node ast.Call type, then use node.id to obtain the function name, and traverse node.args to obtain all parameters.

[0053] When determining the processing logic during traversal, to obtain the conclusion of a rule, the condition preceding the inference operator "<=" is required. However, since "<=" is recognized as the comparison operator "LessOrEqual," it is necessary to filter out conditions that may contain the "<=" comparison operator. For example, for the rule with the attribute type mentioned above, the "<="" comparison operator is broken down into: "Still in stock (Goods) <= Out of stock (Goods) & A)," where A is (Goods == 'Transformer') & (Issuance status [Goods] == 'Unissued']). Since the right-hand side of a condition containing the comparison operator "<=" must be a constant type, ast.Num, or the left-hand side must be a constant type, ast.Num (Goods == 'Transformer')), determining whether "<=" is a comparison operator or an inference operator is determined by determining the left-hand and right-hand side types of "<="." The memory module automatically completes these terms during parsing if they appear in the rule set.

[0054] 1.4) Semantically associate the function and parameters or term information of the parsed rule. If the rule to be parsed exists in the rule set, the field completion is performed using the memory module described above, and this step is skipped. Otherwise, the function name is matched with the attribute fields of the ontology by searching the corresponding knowledge graph. If a match is successful, the ontology information is added to the function, associating the function with the ontology. If a match fails, the association information between the function or term and the ontology can be manually filled in later to achieve the ontology association of the function and term.

[0055] (2) When adding or modifying rules in the rule set, the rule set is tested for terminology semantic inconsistency conflicts. If there is no conflict, the rule set is successfully added or modified. Otherwise, an error message is displayed and the rule set is not added or modified. Figure 2 shown.

[0056] Define the term semantic inconsistency conflict:

[0057] A data structure that binds function parameters to knowledge graph ontology. Function parameter names are bound to ontology concepts, such as function(A,B), where A is bound to ontoClassA and B is bound to ontoClassB. Functions with the same semantics: For two functions, if their function names and number of parameters are the same, we define them as functions with the same semantics. For example, function(A,B) and function(C,D) have the same semantics. Inconsistent terminology conflicts: For functions with the same semantics, such as function(A,B) and function(C,D), where A is bound to ontoClassA, B is bound to ontoClassB, C is bound to ontoClassC, and D is bound to ontoClassD, since A and C, and B and D are bound to different ontology concepts, these two functions with the same semantics have a terminology conflict. The generation of a terminology conflict will affect the recognition of rules, and it will be impossible to determine the ontology concept corresponding to the parameter. If function(A,B) and function(C,D) produce a terminology conflict, then for function(M,N), it is impossible to identify whether M corresponds to ontoClassA or ontoClassB, and whether N corresponds to ontoClassC or ontoClassD.

[0058] 2.1) Use a hash table to record the position and information of the parameters of all rules in the rule set, forming a HashMap1 of <function name, <parameter position, term information>>.

[0059] 2.2) The same process is performed on the rules to be added / modified to form a HashMap2 of <function name, <parameter position, term information>>.

[0060] 2.3) For the conclusion and precondition of the rule to be added / modified, determine whether there is a key value with the same function name as the rule to be added / modified in the HashMap1 generated in the first step. If not, it means that there is no function with the same semantics in the rule set. Add / modify it directly. Otherwise, go to the next step (4).

[0061] 2.4) If there are functions with the same semantics in the to-be-added / modified rules and the rule set, and if they have ontology information, it is necessary to detect whether there are term conflicts; when the to-be-added / modified rules and the functions with the same semantics in the rule set carry ontology information, then detect term conflicts. Detect whether the ontology information of the corresponding position parameters is consistent. Here, two cases need to be processed: one of the functions with the same semantics has incomplete ontology information; the ontology information of the functions with the same semantics is complete. Taking function(A,B) and function(C,D) as an example, the above HashMap1 records a piece of information: <function, <1, the term information of A>> and <function, <2, the term information of B>>, and the above HashMap2 records a piece of information: <function, <1, the term information of C>> and <function, <2, the term information of D>>. At this time, compare whether the ontology information corresponding to the same parameter positions is the same to determine whether there is a term conflict.

[0062] 2.5) If the to-be-added / modified rules do not have ontology information, it is impossible to have a term conflict situation. At this time, according to the transitivity of functions, we can consider that the ontology of the terms of the to-be-added / modified rules and the functions with the same semantics is completely consistent. Then, complete the term information of the to-be-added / modified rules according to the term information of the functions with the same semantics in the rule set.

[0063]

[0064] (3) When a rule dependency loop appears, the reasoning will fall into deadlock. To prevent dependency loop conflicts, the present invention uses a topological sorting method to detect whether there is a dependency loop conflict in the rule set to prevent the rule reasoning from falling into deadlock, as Figure 3 shown.

[0065] A rule dependency loop occurs when the conclusion of one rule in a rule set is a prerequisite for another rule, and the conclusion of the other rule is a prerequisite for the first rule. This creates a dependency loop between the two rules, leading to reasoning errors. Dependency loops are not limited to two rules and can be defined for multiple rules. For example, the following three rules: A <= B, B <= C, and C <= A. The conclusions and prerequisites of these three rules are prerequisites and conclusions of the other two rules. This is a dependency loop. For example, in the "Digital Logistics System" rule example, this manifests as: Need to Purchase (Goods) <= Not in Warehouse (Goods); Not in Warehouse (Goods) <= System Prompt to Purchase (Goods); System Prompt to Purchase (Goods) <= Recheck Warehouse (Goods) & ~ Need to Purchase (Goods). Need to Purchase, Not in Warehouse, and System Prompt to Purchase form a logical loop, each with an in-degree edge.

[0066] 3.1) Pre-add the rules to be added to the rule set, or pre-modify the rules to be modified to obtain a rule set to be tested.

[0067] 3.2) Traverse the rule set to build a directed graph, where the nodes are all the conditions in the rules and the edges point from the conclusion to the precondition.

[0068] 3.3) Perform topological sorting on the formed graph, continuously deleting nodes with in-degree 0. If there are still nodes left that cannot be deleted, it can be determined that there is a cycle in the graph and the remaining nodes constitute this cycle. Return the node information where the cycle occurs. Otherwise, there is no cycle in the graph and the rule is successfully added or modified.

[0069]

[0070]

[0071] (4) When mutually exclusive rules exist in a rule set, if the preconditions are met, the conclusions drawn each time may be different, thus causing reasoning errors. Therefore, the present invention introduces the idea of ​​constraint solving to detect whether there are mutually exclusive rules in the rule set, so as to avoid errors in the rule reasoning process, such as Figure 4 shown.

[0072] Define mutually exclusive rule conflicts: When two or more rules cannot be simultaneously true, they are considered mutually exclusive. For example, consider the following two rules: D <= A&B, ~D <= C. "~" represents a negation operation. Since D and ~D cannot exist at the same time, these two rules are mutually exclusive. In the "Digital Logistics System" rule example, this means Need to Purchase (Goods) <= Still in Warehouse (Goods).

[0073] 4.1) Create conditional variables. In this example, we use the Java choco-solver library to build a constraint solver. We pre-add the rule to be added to the rule set, traverse the rule set, and create conditional variables for each rule's precondition and conclusion. This creates a list of conditional variables and adds them to the constraint model.

[0074] 4.2) Use a hash table to record identical copies of functions with the same semantics. Processing the list obtained in step 1, since the conditions in the rule contain functions with the same semantics, these identical functions or conditions with the same semantics need to be processed so that they only point to the same condition variable. Otherwise, the constraint solver will fail. This is achieved using a hash table with the structure <condition function name, corresponding condition variable>.

[0075] 4.3) Adding Mutual Exclusion Constraints. Traverse the hash table obtained in step 3. If there are mutually exclusive conditions such as A and ~A, add a mutual exclusion constraint to it and add it to the constraint model. For example, if the constraint expression of the above condition is (A + ~A == 1), it means that A and ~A cannot be true at the same time.

[0076] 4.4) Create rule reasoning constraints. Traverse the rule set and create constraints where preconditions => conclusions. Use if (preconditions) then (conclusions) to represent the constraints and add them to the constraint model.

[0077] 4.5) Solve the constraint model and output a feasible solution, where each conditional variable is either true or false. If a feasible solution is output, it indicates that there are no mutually exclusive rules and the rule set is successfully updated. Otherwise, the process fails and a mutual exclusion conflict message is returned.

[0078]

[0079]

[0080] Although the preferred embodiments of the present invention have been described, those skilled in the art may make additional changes and modifications to these embodiments once they have learned the basic creative concept. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments and all changes and modifications that fall within the scope of the present invention.

[0081] Obviously, those skilled in the art may make various changes and modifications to the embodiments of the present invention without departing from the spirit and scope of the embodiments of the present invention. Thus, if such changes and modifications of the embodiments of the present invention fall within the scope of the claims and their equivalents, the present invention is intended to include such changes and modifications.

Claims

1. A supply chain supervision rule conflict detection method based on topological sorting and constraint solving, characterized by: It includes preprocessing, term conflict detection, dependency loop conflict detection and mutually exclusive rule conflict detection, specifically Preprocessing: Based on the abstract syntax tree (AST) rule parsing method, the enterprise supply chain management rule string written in Datalog syntax is parsed into JSON format, semantically associated with the rule set, and the rule information can be automatically completed; Term conflict detection: When adding or modifying rules in a rule set, the rule set is checked for terminology semantic inconsistencies. If no terminology conflicts are detected, information completion is performed based on functions with the same semantics in the terms. Otherwise, an error message will appear and the rule will not be added or modified. The rule error message will be returned to the user for modification and re-entry into pre-processing; Dependency loop conflict detection uses a topological sorting method to detect whether dependency loop conflicts occur in the rule set to prevent rule reasoning from falling into deadlock. If no dependency loop conflict is detected, the rule proceeds to the next step. Otherwise, the rule error information is returned to the user for modification and re-entry into preprocessing; Mutually exclusive rule conflict detection uses constraint solving to detect whether there are mutually exclusive rules in the rule set, avoiding errors in the rule reasoning process. If no mutually exclusive rule conflict is detected, the new rule will be successfully added or modified in the rule set. Otherwise, the rule error information will be returned to the user for modification and re-entry into preprocessing; The semantic association between AST-based rule parsing and rule sets in the preprocessing includes: (1) Define different forms of data parsing logic for rule strings of different types of rules, mainly including function type rules, attribute type rules, constant equation type rules, and mixed type rules; (2) Using abstract syntax tree technology, write a node traversal method to find the first node you need, then use it as the root node and traverse recursively downward until all nodes are found; (3) Determine the processing logic during traversal based on different types of nodes, separate the rule preconditions and conclusions when converting them into JSON, and record the required information; add a memory function so that if the newly added rule terms or functions have appeared in the rule set, the information will be automatically completed during parsing; (4) Perform functional semantic association between the function and parameter or term information of the parsed rule; if there is a rule to be parsed in the rule set, the field is completed through the above-mentioned memory function and this step is skipped; otherwise, the function name is matched with the attribute field of the ontology by searching the ontology of the corresponding rule set. If the match is successful, the ontology information is added to the function to associate the function with the ontology. If the match fails, the association information between the function or term and the ontology can be manually filled in later to realize the ontology association of the function and the term.

2. The supply chain supervision rule conflict detection method based on topological sorting and constraint solving as claimed in claim 1, characterized in that: The terminology conflict detection includes: (1) Use a hash table to record the location and information of the parameters of all rules in the rule set to form a hash table 1; (2) The same process is performed on the rules to be added / modified to form a hash table 2; (3) Compare the conclusions and preconditions of the rule information to be added / modified in hash table 2 with those in hash table 1 generated in the first step to determine whether there is a key value in hash table 1 that is the same as the function name of the rule to be added / modified, and to detect whether there is a term conflict; (4) When there is a function in the rule set to be added / modified in hash table 2 that has the same semantics as that in hash table 1 and carries ontology information, a term conflict is detected and the ontology information corresponding to the same parameter position is compared to determine whether a term conflict occurs; (5) If there is no ontology information for the rule to be added / modified, there will be no term conflict. At this time, based on the transitivity of functions, we can assume that the function of the rule to be added / modified is completely consistent with the ontology of the terminology of the function with the same semantics. Then, the terminology information of the rule to be added / modified is completed based on the terminology information of the same semantic function in the rule set.

3. The supply chain supervision rule conflict detection method based on topological sorting and constraint solving as claimed in claim 1, characterized in that: The dependency loop conflict detection uses a topological sorting method to detect whether a dependency loop occurs in the rule set: (1) Pre-add the rules to be added to the rule set, or pre-modify the rules to be modified to obtain a rule set to be tested; (2) Traverse the rule set to build a directed graph, where the nodes are all the conditions in the rule and the edges go from the conclusion to the precondition; (3) Perform topological sorting on the formed graph and continuously delete nodes with in-degree 0. If there are nodes left that cannot be deleted, it can be determined that there is a loop in the graph and the remaining nodes constitute this loop. Return the node information where the loop appears. Otherwise, there is no loop in the graph and the rule is successfully added or modified.

4. The supply chain supervision rule conflict detection method based on topological sorting and constraint solving as claimed in claim 1, characterized in that: The mutually exclusive rule conflict detection introduces the constraint solving idea to detect whether there are mutually exclusive rules in the rule set: (1) Create conditional variables; pre-add the rules to be added to the rule set and traverse the rule set; create conditional variables for the preconditions and conclusions of each rule to form a conditional variable list; build a constraint solver, compile the conditions in the above conditional variable list into constraints, add them to the constraint solver, and form a constraint model; (2) Use a hash table to record the same copy of the same semantic function; since there are functions with the same semantics in the conditions of the rule, it is necessary to process these same functions or conditions of the same semantic function so that they only point to the same condition variable, otherwise the constraint solution will fail; (3) Traverse the above hash table and add mutual exclusion constraints; if there are mutual exclusion conditions, add mutual exclusion constraints to them and add them to the constraint model; (4) Create rule reasoning constraints; traverse the rule set, create precondition => conclusion constraints, and add them to the constraint model; (5) Solve the constraint model and output a feasible solution, where a feasible solution means that each condition variable takes true or false. If a feasible solution is output, it indicates that there are no mutually exclusive rules and the rule set is successfully updated. Otherwise, the processing fails and the mutually exclusive conflict information is returned.

5. A supply chain supervision rule conflict detection system based on topological sorting and constraint solving, characterized by: include The preprocessing module is configured as an abstract syntax tree (AST)-based rule parsing method. It parses enterprise supply chain management rule strings written in Datalog syntax into JSON format, associates semantics with the rule set, and can automatically complete the rule information. A terminology conflict detection module is configured to perform terminology semantic inconsistency detection on the rule set when adding or modifying a rule in the rule set. If no terminology conflict is detected, information completion is performed based on functions with the same semantics in the terminology. Otherwise, an error message will appear and the rule will not be added or modified. The rule error message will be returned to the user for modification and re-entry into pre-processing; The dependency loop conflict detection module is configured to use a topological sorting method to detect dependency loop conflicts in the rule set to prevent rule reasoning from deadlocking. If no dependency loop conflict is detected, the rule will proceed to the next step. Otherwise, the rule error information will be returned to the user for modification and re-entry into preprocessing; The mutually exclusive rule conflict detection module is configured to detect whether there are mutually exclusive rules in the rule set based on constraint solving, so as to avoid errors in the rule reasoning process. If no mutually exclusive rule conflict is detected, the new rule will be successfully added or modified in the rule set. Otherwise, the rule error information will be returned to the user for modification and re-entry into preprocessing; The semantic association between AST-based rule parsing and rule sets in the preprocessing module includes: (1) Define different forms of data parsing logic for rule strings of different types of rules, mainly including function type rules, attribute type rules, constant equation type rules, and mixed type rules; (2) Using abstract syntax tree technology, write a node traversal method to find the first node you need, then use it as the root node and traverse recursively downward until all nodes are found; (3) Determine the processing logic during traversal based on different types of nodes, separate the rule preconditions and conclusions when converting them into JSON, and record the required information; add a memory function so that if the newly added rule terms or functions have appeared in the rule set, the information will be automatically completed during parsing; (4) Perform functional semantic association between the function and parameter or term information of the parsed rule; if there is a rule to be parsed in the rule set, the field is completed through the above-mentioned memory function and this step is skipped; otherwise, the function name is matched with the attribute field of the ontology by searching the ontology of the corresponding rule set. If the match is successful, the ontology information is added to the function to associate the function with the ontology. If the match fails, the association information between the function or term and the ontology can be manually filled in later to realize the ontology association of the function and the term.

6. The supply chain supervision rule conflict detection system based on topological sorting and constraint solving as claimed in claim 5, characterized in that: The semantic inconsistency detection of rule set terms in the terminology conflict detection module includes: (1) Use a hash table to record the location and information of the parameters of all rules in the rule set to form a hash table 1; (2) The same process is performed on the rules to be added / modified to form a hash table 2; (3) Compare the conclusions and preconditions of the rule information to be added / modified in hash table 2 with those in hash table 1 generated in the first step to determine whether there is a key value in hash table 1 that is the same as the function name of the rule to be added / modified, and to detect whether there is a term conflict; (4) When the rule to be added / modified in hash table 2 has the same semantics as the function in hash table 1 and carries ontology information, terminology conflict is detected and the ontology information corresponding to the same parameter position is compared to determine whether a terminology conflict occurs; (5) If there is no ontology information for the rule to be added / modified, there will be no term conflict. At this time, based on the transitivity of functions, we can assume that the function of the rule to be added / modified is completely consistent with the ontology of the terminology of the function with the same semantics. Then, the terminology information of the rule to be added / modified is completed based on the terminology information of the same semantic function in the rule set.

7. The supply chain supervision rule conflict detection system based on topological sorting and constraint solving as claimed in claim 5, characterized in that: The dependency loop conflict detection module uses a topological sorting method to detect whether a dependency loop occurs in the rule set: (1) Pre-add the rules to be added to the rule set, or pre-modify the rules to be modified to obtain a rule set to be tested; (2) Traverse the rule set to build a directed graph, where the nodes are all the conditions in the rule and the edges go from the conclusion to the precondition; (3) Perform topological sorting on the formed graph and continuously delete nodes with in-degree 0. If there are nodes left that cannot be deleted, it can be determined that there is a loop in the graph and the remaining nodes constitute this loop. Return the node information where the loop appears. Otherwise, there is no loop in the graph and the rule is successfully added or modified.

8. The supply chain supervision rule conflict detection system based on topological sorting and constraint solving as claimed in claim 5, characterized in that: The mutually exclusive rule conflict detection module detects whether there are mutually exclusive rules in the rule set based on constraint solving, specifically including: (1) Create conditional variables; pre-add the rules to be added to the rule set, traverse the rule set, create conditional variables for the preconditions and conclusions of each rule, and form a conditional variable list; build a constraint solver, compile the conditions in the above conditional variable list into constraints, and add them to the constraint solver to form a constraint model; (2) Use a hash table to record the same copy of the same semantic function; since there are functions with the same semantics in the conditions of the rule, it is necessary to process these same functions or conditions of the same semantic function so that they only point to the same condition variable, otherwise the constraint solution will fail; (3) Traverse the above hash table and add mutual exclusion constraints; if there are mutual exclusion conditions, add mutual exclusion constraints to them and add them to the constraint model; (4) Create rule reasoning constraints; traverse the rule set, create precondition => conclusion constraints, and add them to the constraint model; (5) Solve the constraint model and output a feasible solution, where a feasible solution means that each condition variable takes true or false. If a feasible solution is output, it indicates that there are no mutually exclusive rules and the rule set is successfully updated. Otherwise, the processing fails and the mutually exclusive conflict information is returned.

Images