A governance-aware compilation method and system for ontology graph queries

Abstract

The application relates to the technical field of graph database query, and particularly discloses a governance-aware compiling method and system for ontology graph query, which comprises the following steps: receiving and analyzing a graph query request, and constructing a graph traversal abstract syntax tree; obtaining a governance strategy associated with a current query session, expressing tenant isolation constraints, access level constraints, use limitation constraints, soft deletion filtering constraints and result set size constraints in the governance strategy as governance predicate nodes, and injecting the governance predicate nodes into node scanning nodes and edge traversal nodes of the graph traversal abstract syntax tree; selecting a graph query dialect compiler corresponding to a target graph database engine, compiling the graph traversal abstract syntax tree with the injected governance predicate nodes into a target graph query language statement, and expanding the governance predicate nodes into corresponding filtering clauses during the compiling. The application realizes governance injection during graph query compiling, guarantees that the governance injection maintains semantic contractility on the graph query, and enables the same governance strategy to produce consistent governance effects on the graph query and the relational query.

Description

Technical Field

[0001] This invention relates to the field of graph database query technology, specifically to a governance-aware compilation method and system for ontology graph query. Background Technology

[0002] The application of graph databases and knowledge graphs in enterprise data management continues to grow. Systems such as Neo4j, TigerGraph, Amazon Neptune, NebulaGraph, and HugeGraph provide rich graph query capabilities, and the release of the ISO / IEC 39075 (GQL) standard has further promoted the unification of graph query languages. With the widespread adoption of multi-tenant architectures in enterprise-level graph database systems, the need for data governance, such as data isolation between tenants, access-level data protection, and data usage restrictions, is becoming increasingly urgent.

[0003] Existing graph database systems have significant shortcomings in data governance. Current mainstream graph database access control mechanisms typically rely on database-level user permission management, i.e., authenticating users and granting them global read and write permissions at the database level. However, this coarse-grained access control approach cannot meet the fine-grained governance needs of multi-tenant scenarios. Specifically, when an enterprise stores data from multiple tenants in the same graph database using a graph structure, each graph traversal query requires manually writing governance logic at the application layer—developers need to filter the result set row by row through application-layer code after the query results are returned to remove data that the current tenant does not have permission to access. This application-layer post-filtering method not only increases the complexity of application development but also poses a security risk of developers overlooking governance logic.

[0004] Existing governance-aware relational algebra frameworks have solved the governance injection problem in relational database queries. They achieve compile-time governance of relational queries by injecting governance strategies as selection conditions in relational algebra during the relational query compilation phase. However, the semantic model of graph queries differs fundamentally from that of relational queries—graph queries rely on node and edge traversal as their core operation, while relational queries rely on table joins and projections. Because the traversal semantics of graph queries differ from the join semantics of relational queries, governance injection methods for relational queries cannot be directly applied to graph query scenarios, resulting in a long-standing lack of compile-time governance injection mechanisms in the graph database domain. Summary of the Invention

[0005] To address the above problems, this invention proposes a governance-aware compilation method and system for ontology graph querying, the specific technical solution of which is as follows: In a first aspect, the present invention provides a governance-aware compilation method for ontology graph querying, comprising the following steps: S1. Receive a graph query request expressed in an ontology object set query language, wherein the graph query request specifies at least the starting node type, edge path, traversal direction, and ending node type of the graph traversal.

[0006] S2. Parse the graph query request and construct a graph traversal abstract syntax tree, which includes node scanning nodes, edge traversal nodes, and attribute filtering nodes.

[0007] S3. Obtain the governance strategy associated with the current query session, and express the tenant isolation constraint, access level constraint, usage restriction constraint, soft deletion filter constraint and result set size constraint in the governance strategy as governance predicate nodes, and inject the governance predicate nodes into the corresponding node scan node and edge traversal node in the graph traversal abstract syntax tree.

[0008] S4. Select the corresponding graph query dialect compiler according to the target graph database engine, and compile the graph traversal abstract syntax tree with the governance predicate node injected into the target graph query language statement through the graph query dialect compiler. During compilation, the governance predicate node is expanded into the filter clause corresponding to the target graph query language.

[0009] Based on the above embodiments, before injecting the governance predicate node, it is verified whether the current query session carries a valid tenant identifier; if the tenant identifier is missing or invalid, compilation is refused and an error message is returned, and graph queries are not allowed to be executed without tenant isolation constraints.

[0010] Based on the above embodiments, step S1 includes: The system receives graph query requests through an ontology query application programming interface; performs lexical and syntactic analysis on the graph query requests through a compiler; performs node type matching and edge type matching in a preset ontology schema registry; if the matching is successful, it constructs a query semantic tuple and passes it to step S2; if the matching fails, it returns an error message to the query client.

[0011] Based on the above embodiments, step S2 includes: A graph traversal abstract syntax tree is constructed based on the query semantic tuple. The graph traversal abstract syntax tree has a path pattern node as the root node and includes node scanning nodes, edge traversal nodes, and attribute filtering nodes that are connected in traversal order.

[0012] Based on the above embodiments, the method for obtaining the governance policy associated with the current query session in step S3 includes: Extract the context information of the current query session, which includes at least the tenant identifier, access level label, and purpose label of the query initiator.

[0013] Determine whether the node and edge types involved in the graph query request belong to multiple ontology spaces.

[0014] If only a single ontology space is involved, the corresponding governance policy is obtained from the governance policy repository using the ontology space's identifier, the tenant identifier, the access level label, and the purpose label as indexes.

[0015] If multiple ontology spaces are involved, the corresponding governance strategies are obtained from each participating ontology space, and the multiple governance strategies are merged into a unified set of governance predicate nodes according to a preset merging strategy.

[0016] The merger strategy includes any of the following: Take the intersection of the governance strategies of each participating ontology space to ensure that the combined governance constraints are no weaker than the governance constraints of any single participant.

[0017] Take the union of the governance strategies of each participating ontology space, so that the merged governance constraints cover the governance constraints of each participant.

[0018] The governance strategy of the ontology space where the data source is located shall prevail.

[0019] The governance strategy of the ontology space where the query originates shall prevail.

[0020] Based on the above embodiments, the default selection of the merging strategy is to take the intersection of the governance strategies of each participating ontology space to ensure that the governance constraints after merging are not weaker than the governance constraints of any one participant, and the selection result of the merging strategy is recorded in the audit metadata included in the compilation result.

[0021] Based on the above embodiments, the method for expressing the governance strategy as a governance predicate node in step S3 includes: Parse the governance strategy to obtain constraint rule entries; generate corresponding governance predicate nodes according to constraint type identifiers; and attach strategy source information to each governance predicate node.

[0022] Based on the above embodiments, the method of injecting the governance predicate node into the graph traversal abstract syntax tree in step S3 includes: The graph traversal abstract syntax tree is traversed; when a node is identified and the node is scanned, row filtering rules and column masking rules are matched and the matching results are converted into node-level governance predicate nodes and governance annotations for injection; when an edge is identified and the node is traversed, edge-level filtering rules are matched and the matching results are converted into edge-level governance predicate nodes for injection; during the injection process, the traversal path structure of the graph traversal abstract syntax tree remains unchanged.

[0023] Based on the above embodiments, the graph query result set obtained after the injection of the governance predicate node is a subset of the original result set before injection, so that the injection operation of the governance predicate node in the graph traversal abstract syntax tree maintains semantic contractility. The semantic contractility is achieved in the following way: The injection operation of the governance predicate node only adds conjunctive predicates to the filtering conditions of the node scanning node and the edge traversal node, and does not modify the traversal path structure of the graph traversal abstract syntax tree. The addition of the conjunctive predicate only reduces the set of nodes and edges that meet the conditions.

[0024] Based on the above embodiments, step S4 includes: Select the corresponding graph query dialect compiler according to the type of the target graph database engine; compile the graph traversal abstract syntax tree with governance predicate nodes injected into the target graph query language statement through the graph query dialect compiler. During compilation, the governance predicate nodes are expanded into the filter clauses corresponding to the target graph query language.

[0025] Based on the above embodiments, the target graph query language includes at least one of the following: a graph query language based on Open Cypher syntax, the SPARQL protocol, and the RDF query language.

[0026] Based on the above embodiments, the graph traversal abstract syntax tree and the relational query abstract syntax tree share the same governance strategy descriptor during the governance injection phase, so that the same governance strategy produces consistent governance effects in graph queries and relational queries; the governance strategy descriptor is extended with an edge-level filtering rule field in the graph query scenario, and this edge-level filtering rule field is parallel to the row filtering rule field and column desensitization rule field of relational queries.

[0027] Secondly, the present invention also provides a governance-aware compilation system for ontology graph queries, including a graph query parsing module for parsing graph query requests of ontology object set query language into a graph traversal abstract syntax tree; a graph governance injection module for expressing constraints in governance strategies as governance predicate nodes and injecting them into node scanning and edge traversal positions in the graph traversal abstract syntax tree; and a graph dialect compilation module for compiling the graph traversal abstract syntax tree with injected governance predicates into a target graph query language statement.

[0028] Compared with existing technologies, the governance-aware compilation method for ontology graph query described in this invention has the following advantages: 1. This invention expresses the tenant isolation constraints, access level constraints, and usage restrictions in the governance strategy as governance predicate nodes during the graph query compilation phase, and injects them into the corresponding node scan nodes and edge traversal nodes in the graph traversal abstract syntax tree. Finally, these nodes are expanded into filter clauses of the target graph query language at compile time. Therefore, the governance logic does not need to be manually implemented at the application layer; instead, it is automatically injected by the compiler during query generation, reducing application development workload and avoiding the risk of overlooking governance logic due to human error.

[0029] 2. This invention restricts the injection method of governance predicate nodes: conjunctive predicates are added only to the filtering conditions of node scanning nodes and edge traversal nodes, without modifying the traversal path structure of the graph traversal abstract syntax tree. This ensures that the addition of conjunctive predicates can only reduce the set of nodes and edges that meet the conditions. The graph query result set obtained after governance predicate node injection is a subset of the original result set before injection. From the compiler principle level, this ensures that governance constraints are not bypassed due to query rewriting, thus ensuring the security of data access.

[0030] 3. The graph traversal abstract syntax tree and the relational query abstract syntax tree of this invention share the same governance strategy descriptor during the governance injection phase. This descriptor, in the graph query scenario, is extended with an edge-level filtering rule field, which is parallel to the row filtering rule field and column desensitization rule field of the relational query. After the same governance strategy is parsed by the same strategy engine, consistent governance semantics are generated in both SQLJOIN operations in relational queries and graph traversal edge operations in graph queries. Enterprises do not need to define new governance strategies separately for graph queries, reducing the complexity of governance strategy management in multi-data-model scenarios.

[0031] 4. When a graph query request involves nodes and edges from multiple ontology spaces, the compiler obtains governance strategies from each participating ontology space and merges these strategies into a unified set of governance predicate nodes according to a preset merging strategy. The merging strategy includes various methods such as intersection, union, using the ontology space where the data source is located, and using the ontology space where the query initiator is located. The default strategy is the intersection strategy to ensure that the merged governance constraints are not weaker than the governance constraints of any single participant, thus meeting the multi-party compliance requirements in cross-ontology query scenarios. Attached Figure Description

[0032] To more clearly illustrate the technical solutions of the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0033] Figure 1 This is a schematic diagram of the method flow of the present invention.

[0034] Figure 2 This is a schematic diagram of the predicate node injection process for graph traversal abstract syntax tree governance according to the present invention.

[0035] Figure 3 This is a schematic diagram illustrating the process of compiling a graph traversal abstract syntax tree with injected governance predicate nodes into a target Cypher query statement according to the present invention.

[0036] Figure 4 This is a system module connection diagram of the present invention. Detailed Implementation

[0037] To further illustrate the technical means and effects adopted by the present invention to achieve its intended purpose, the following, in conjunction with the accompanying drawings and preferred embodiments, details the specific implementation, structure, features, and effects of a governance-aware compilation method and system for ontology graph querying proposed according to the present invention. In the following description, different "one embodiment" or "another embodiment" do not necessarily refer to the same embodiment. Furthermore, specific features, structures, or characteristics in one or more embodiments can be combined in any suitable form.

[0038] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this invention pertains.

[0039] The following description, in conjunction with the accompanying drawings, details the specific scheme of the governance-aware compilation method and system for ontology graph query provided by this invention.

[0040] Please see Figure 1 As shown, the governance-aware compilation method for ontology graph querying provided by this invention includes the following four steps S1 to S4. Specific implementation details of each step will be described below in conjunction with the accompanying drawings.

[0041] Step S1: Receive a graph query request expressed in the ontology object set query language. The graph query request specifies at least the starting node type, edge path, traversal direction, and ending node type of the graph traversal.

[0042] In a preferred embodiment of the present invention, step S1 includes: The system receives graph query requests through an ontology query application programming interface; performs lexical and syntactic analysis on the graph query requests through a compiler; performs node type matching and edge type matching in a preset ontology schema registry; if the matching is successful, it constructs a query semantic tuple and passes it to step S2; if the matching fails, it returns an error message to the query client.

[0043] It should be noted that, in a specific embodiment of the present invention, the specific steps for receiving a graph query request and obtaining the starting node type, edge path, traversal direction, and ending node type of the graph traversal are as follows:

[0044] S101, Receive image query request: The query client submits graph query requests written in the Ontology Object Set Query Language to the graph query compiler by calling a predefined Ontology Query Application Programming Interface (API). The API provides a unified query entry point, supporting RESTful requests based on the Hypertext Transfer Protocol (HTTP) or Remote Procedure Calls (RPCs) for inter-process communication within the application. The Ontology Object Set Query Language is a declarative query language designed for ontology graph data models, and its syntax supports declarative descriptions of node types, edge types, and associated path patterns in the ontology graph.

[0045] The syntax structure of the graph query request must include at least the following fields: The starting node type field is used to declare the type of the starting node for graph traversal operations.

[0046] The edge path field is used to declare the type of edges traversed from the starting node and the path depth constraints.

[0047] The traversal direction field is used to declare the orientation of traversal along the edge path, including forward traversal, reverse traversal, or bidirectional traversal.

[0048] The endpoint node type field is used to declare the type of the target node reached when the graph traversal ends.

[0049] S102. Parse the graph query request: After receiving the graph query request, the compiler calls the built-in ontology schema parser to parse the graph query request in order to construct the original query syntax tree.

[0050] S103. Extract query parameters based on the field identifiers in the graph query request: After parsing, the compiler traverses the original query syntax tree to extract query semantic parameters. Specifically, this includes: (1) Obtaining the starting node type: The compiler performs a node type matching operation in the ontology schema registry based on the identifier of the starting node type field to verify whether the starting node type exists in the ontology schema definition. If it exists, the compiler obtains the complete metadata definition of the node type, including its attribute set, attribute data type, and primary key identifier; if it does not exist, the compiler returns an error message that the node type is not defined to the query client.

[0051] (2) Obtaining the edge path: The compiler performs an edge type matching operation in the ontology schema registry based on the descriptor of the edge path field, verifies whether the edge type exists in the ontology schema definition, and obtains the metadata definition of the edge type, including the edge type name, starting node type constraint, ending node type constraint, and edge attribute set. If the edge path also contains a path depth constraint (e.g., shortest path or variable length path), the compiler parses and records the constraint.

[0052] (3) Obtaining the traversal direction: The compiler parses the forward traversal identifier, reverse traversal identifier or bidirectional traversal identifier according to the value of the traversal direction field, and converts it into internal direction enumeration values ​​(TRAVERSE_OUTGOING, TRAVERSE_INCOMING or TRAVERSE_BOTH).

[0053] (4) Obtaining the Endpoint Node Type: Based on the identifier of the endpoint node type field, the compiler performs a node type matching operation in the ontology schema registry to verify whether the endpoint node type exists in the ontology schema definition and obtain its metadata definition. Further, the compiler performs a compatibility check between the endpoint node type and the termination node type constraint of the edge path: if the endpoint node type does not satisfy the termination node type constraint of the edge path, an error message indicating a path type mismatch is returned to the query client.

[0054] S104. Construct the query semantic tuple: If all the above matching and verification operations are successful, the compiler will encapsulate the extracted starting node type, edge path, traversal direction and ending node type into a query semantic tuple and pass it to step S2 for constructing the graph traversal abstract syntax tree.

[0055] Step S2: Parse the graph query request and construct a graph traversal abstract syntax tree, which includes node scanning nodes, edge traversal nodes, and attribute filtering nodes.

[0056] In a preferred embodiment of the present invention, step S2 includes: A graph traversal abstract syntax tree is constructed based on the query semantic tuple. The graph traversal abstract syntax tree has a path pattern node as the root node and includes node scanning nodes, edge traversal nodes, and attribute filtering nodes that are connected in traversal order.

[0057] It should be noted that, in a specific embodiment of the present invention, the specific steps for parsing the graph query request and constructing the graph traversal abstract syntax tree are as follows: S201. Obtain the query semantic tuple and initialize the root node of the abstract syntax tree.

[0058] After obtaining the query semantic tuple from step S1, the compiler creates the root node of the graph traversal abstract syntax tree. The type of the root node is set to a path pattern node (PATH_PATTERN), which is used to represent the structure of the entire graph traversal path.

[0059] S202. Recursively construct syntax tree nodes based on the query semantic tuples: The compiler traverses the path descriptions in the query semantic tuples and constructs syntax tree nodes of the following types in the topological order of graph traversal: (1) Constructing Node Scan Nodes: For the start node type and end node type in the query semantic tuple, the compiler creates node scan nodes (NODE_SCAN) respectively. Each node scan node contains the following fields: The node type label (nodeLabel) records the ontology type name corresponding to the node.

[0060] The filter condition linked list (filters) is initially empty and reserved for injecting governance predicate nodes and attribute filtering conditions in subsequent step S3.

[0061] The governance annotation is initially empty and is reserved for recording metadata information about governance strategies.

[0062] The child node count (childCount) and the child node pointer array (children) are used to mount subsequent edge traversal nodes.

[0063] (2) Constructing edge traversal nodes: For the edge paths in the query semantic tuple, the compiler creates edge traversal nodes (EDGE_TRAVERSE). Each edge traversal node contains the following fields: The edge type label (edgeLabel) records the name of the ontology relation type corresponding to the edge.

[0064] The traversal direction is set to forward traversal (TRAVERSE_OUTGOING), reverse traversal (TRAVERSE_INCOMING), or bidirectional traversal (TRAVERSE_BOTH) based on the traversal direction field in the query semantic tuple.

[0065] The filter condition linked list (filters) is initially empty and is reserved for injecting governance predicate nodes and edge attribute filtering conditions in subsequent step S3.

[0066] The governance annotation is initially empty and is reserved for recording metadata information about governance strategies.

[0067] (3) Constructing attribute filtering nodes: If the graph query request also contains constraints on node attributes or edge attributes, the compiler creates attribute filtering nodes (NODE_FILTER or EDGE_FILTER) for the corresponding node scanning node or edge traversal node, and fills the attribute constraints into the corresponding node's filter condition list (filters) in the form of predicate expressions.

[0068] (4) Establish topological connections between nodes: The compiler connects the node scanning nodes and edge traversal nodes according to the path order of graph traversal in the following way: Each edge traversal node is a child node of the previous node's scan node and is attached to the children array of that node's scan node.

[0069] Each node scan node serves as the successor node of its preceding filter condition node, connected via the next pointer.

[0070] For intermediate nodes (if any) in the path pattern, the compiler creates additional node scanning nodes accordingly, and points the next pointer of the previous node scanning node to the intermediate node, the children array of the intermediate node to the subsequent edge traversal nodes, and so on, until the end node scanning node.

[0071] S203. Constructing the chained traversal relationships between nodes: The compiler will scan and traverse all nodes created in step S202, following the traversal order defined in the graph query request, and chain them together using the next pointers of each node to form a complete traversal path linked list. Each node's next pointer points to the next syntax tree node in the path, and its children pointer points to the sub-path branches extended by that node.

[0072] S204, Output graph traversal of the abstract syntax tree: The compiler passes the graph traversal abstract syntax tree constructed in step S203 to step S3 for the injection operation of predicate nodes. The root node of the graph traversal abstract syntax tree is a path pattern node (PATH_PATTERN), and its children array contains pointers to the starting node and scanning nodes. These pointers are linked together through the next pointer to form a complete traversal path until the ending node and scanning node.

[0073] Step S3: Obtain the governance strategy associated with the current query session, express the tenant isolation constraint, access level constraint, usage restriction constraint, soft deletion filter constraint and result set size constraint in the governance strategy as governance predicate nodes, and inject the governance predicate nodes into the corresponding node scan node and edge traversal node in the graph traversal abstract syntax tree.

[0074] Before injecting the governance predicate node, verify whether the current query session carries a valid tenant identifier; if the tenant identifier is missing or invalid, refuse to compile and return an error message, and do not allow graph queries to be executed without tenant isolation constraints.

[0075] In a preferred embodiment of the present invention, the method for obtaining the governance policy associated with the current query session in step S3 includes: Extract the context information of the current query session, which includes at least the tenant identifier, access level label, and purpose label of the query initiator.

[0076] Determine whether the node and edge types involved in the graph query request belong to multiple ontology spaces.

[0077] If only a single ontology space is involved, the corresponding governance policy is obtained from the governance policy repository using the ontology space's identifier, the tenant identifier, the access level label, and the purpose label as indexes.

[0078] If multiple ontology spaces are involved, the corresponding governance strategies are obtained from each participating ontology space, and the multiple governance strategies are merged into a unified set of governance predicate nodes according to a preset merging strategy.

[0079] The merger strategy includes any of the following: Take the intersection of the governance strategies of each participating ontology space to ensure that the combined governance constraints are no weaker than the governance constraints of any single participant.

[0080] Take the union of the governance strategies of each participating ontology space, so that the merged governance constraints cover the governance constraints of each participant.

[0081] The governance strategy of the ontology space where the data source is located shall prevail.

[0082] The governance strategy of the ontology space where the query originates shall prevail.

[0083] It should be noted that, in one specific embodiment of the present invention, obtaining the governance policy associated with the current query session includes the following steps: S311. Extract the context information of the current query session: When the compiler receives the graph query request, it simultaneously obtains the session context information associated with the current query session. The session context information includes at least: the query initiator's identity identifier, the tenant identifier to which the query initiator belongs, the access level label granted to the query initiator, and the purpose label of the current query operation. This session context information is obtained by the compiler from the identity authentication and authorization management module when the query session is established and cached in the context of the current session.

[0084] S312. Determine whether the graph query request involves multiple ontology spaces: The compiler queries the ontology schema registry for the attribution information of each node type and edge type based on the starting node type, edge path, and ending node type specified in the graph query request. If all the involved node types and edge types belong to the same governance domain, it is determined to be a single ontology space scenario; if multiple governance domains are involved, it is determined to be a multi-ontology space scenario.

[0085] S313. Governance strategies for single ontology space scenarios: If the graph query request involves only a single ontology space, the compiler initiates a governance policy query request to the governance policy repository, using the identifier of that ontology space and the tenant identifier, access level label, and purpose label from the session context information as indexes. The governance policy repository returns a governance policy that matches the ontology space and the current session context based on the indexes. The governance policy includes at least one of the following: tenant isolation constraints, access level constraints, purpose restriction constraints, soft deletion filtering constraints, and result set size constraints.

[0086] S314. Obtain governance strategies for multiple ontology space scenarios and merge them: If the graph query request involves multiple ontology spaces, the compiler performs the following operations: (1) Obtain the governance strategy of each participating ontology space: The compiler uses the identifier of each participating ontology space and the tenant identifier, access level label and purpose label in the session context information as indexes to initiate governance strategy query requests to the governance strategy repository to obtain the governance strategy corresponding to each participating ontology space.

[0087] (2) Merging multiple governance strategies into a unified set of governance predicate nodes according to a preset merging strategy: The compiler calls the strategy merging engine to merge the obtained multiple governance strategies according to the preset merging strategy. The merging strategy is pre-configured by the system administrator and stored in the system configuration parameters. The merging strategy includes any of the following: Intersection Strategy: Take the intersection of the governance strategies of each participating ontology space, that is, retain only the governance constraints common to all participating ontology spaces, so that the merged governance constraints are not weaker than the governance constraints of any single participant.

[0088] Union Strategy: Take the union of the governance strategies of each participating ontology space, that is, retain the governance constraints of any participating ontology space so that the merged governance constraints cover the governance requirements of all participants.

[0089] Data source priority strategy: The governance strategy of the ontology space where the starting node in the graph query request is located shall prevail, and the governance strategies of other participating ontology spaces shall be ignored.

[0090] Initiator-priority strategy: The governance strategy of the ontology space where the initiator resides is used as the standard, ignoring the governance strategies of other participating ontologies.

[0091] (3) Record the merge strategy selection result: The compiler records the merge strategy type used in this merge in the audit metadata of the compilation result for subsequent audit traceability.

[0092] In a preferred embodiment of the present invention, the default selection of the merging strategy is to take the intersection of the governance strategies of each participating ontology space, so as to ensure that the governance constraints after merging are not weaker than the governance constraints of any participant, and the selection result of the merging strategy is recorded in the audit metadata included in the compilation result.

[0093] In a preferred embodiment of the present invention, the method of expressing the governance strategy as a governance predicate node in step S3 includes: Parse the governance strategy to obtain constraint rule entries; generate corresponding governance predicate nodes according to constraint type identifiers; and attach strategy source information to each governance predicate node.

[0094] It should be noted that, in a specific embodiment of the present invention, the tenant isolation constraints, access level constraints, usage restriction constraints, soft deletion filtering constraints, and result set size constraints in the governance strategy are expressed as governance predicate nodes, and the specific steps include: S321. Parse the constraint rule entries in the governance strategy: After obtaining the governance policy associated with the current query session, the compiler invokes the governance policy parser to perform structured parsing of the governance policy. The governance policy contains one or more constraint rule entries, and each constraint rule entry includes at least: a constraint type identifier, a constraint target object descriptor, and a constraint condition expression.

[0095] The constraint type identifier is used to indicate the governance dimension to which the constraint belongs, including at least one of the following: Tenant isolation constraints are used to limit query results to include only data belonging to a specific tenant.

[0096] Access level constraints are used to limit query results to include only data that does not exceed the current user's access level.

[0097] Usage restriction constraints are used to limit the scope of use of query results.

[0098] Soft deletion filter constraints are used to limit query results to include only data that has not been marked as deleted.

[0099] Result set size constraint is used to limit the maximum number of entries in the result set returned by a query.

[0100] The constraint target object descriptor is used to indicate the type of ontology graph object to which the constraint applies, including node type or edge type.

[0101] S322. Convert each constraint type into the corresponding governance predicate node: The compiler performs the following conversion operations based on the constraint type identifier of each constraint rule entry: (1) Conversion of tenant isolation constraints: If the constraint type identifier indicates a tenant isolation constraint, the compiler determines whether the constraint applies to a node or an edge based on the constraint target object descriptor, and generates the corresponding tenant isolation governance predicate node. The tenant isolation governance predicate node includes: a constraint type marked as tenant isolation, a target object type marked as the corresponding node type or edge type, and a constraint condition expression (in the form of target object.tenant field = current session tenant identifier).

[0102] (2) Conversion of access level constraints: If the constraint type identifier indicates an access level constraint, the compiler generates the corresponding access level governance predicate node. The access level governance predicate node includes: a constraint type marked as access level, a target object type marked as the corresponding node type or edge type, and a constraint condition expression (in the form of target object.level field ≤ current session access level label).

[0103] (3) Conversion of usage restriction constraints: If the constraint type identifier indicates a usage restriction constraint, the compiler generates a corresponding usage restriction governance predicate node. The usage restriction governance predicate node includes: a constraint type marked as usage restriction, a target object type marked as the corresponding node type or edge type, and usage restriction metadata (containing a list of allowed uses or a list of prohibited uses).

[0104] (4) Conversion of soft deletion filter constraints: If the constraint type identifier indicates a soft deletion filter constraint, the compiler generates the corresponding soft deletion filter governance predicate node. The soft deletion filter governance predicate node includes: a constraint type marker indicating soft deletion filter, a target object type marker indicating the corresponding node type or edge type, and a constraint condition expression (in the form of target object.deletion marker field=false).

[0105] (5) Conversion of result set size constraint: If the constraint type identifier indicates a result set size constraint, the compiler generates a corresponding result set size governance predicate node. The result set size governance predicate node includes: constraint type marked as result set size limit, and result set size threshold parameter.

[0106] S323. Attach policy source metadata to each governance predicate node: When generating each governance predicate node, the compiler appends the corresponding governance policy source information to that node. This policy source information includes at least the policy identifier and policy version number of the governance policy to which the constraint belongs. This policy source information is used for subsequent auditing and tracing to identify the specific source of the constraint affecting the query results.

[0107] S324. Group the governance predicate nodes according to the target object type: The compiler divides all generated governance predicate nodes into node-level governance predicate node groups and edge-level governance predicate node groups based on the target object type label of each governance predicate node. Each governance predicate node in the node-level governance predicate node group corresponds to a node scan node in the graph traversal abstract syntax tree constructed in step S2; each governance predicate node in the edge-level governance predicate node group corresponds to an edge traversal node in the graph traversal abstract syntax tree constructed in step S2.

[0108] In a preferred embodiment of the present invention, the method of injecting the governance predicate node into the graph traversal abstract syntax tree in step S3 includes: The graph traversal abstract syntax tree is traversed; when a node is identified and the node is scanned, row filtering rules and column masking rules are matched and the matching results are converted into node-level governance predicate nodes and governance annotations for injection; when an edge is identified and the node is traversed, edge-level filtering rules are matched and the matching results are converted into edge-level governance predicate nodes for injection; during the injection process, the traversal path structure of the graph traversal abstract syntax tree remains unchanged.

[0109] It should be noted that, for reference Figure 2 As shown, in a specific embodiment of the present invention, the governance predicate node is injected into the corresponding node scan node and edge traversal node in the graph traversal abstract syntax tree. The specific steps include: S331. Traversing the graph: Traversing each node in the abstract syntax tree: The compiler traverses the graph traversal abstract syntax tree constructed in step S2 using either a depth-first or breadth-first approach, sequentially visiting each node in the graph traversal abstract syntax tree. The compiler identifies the node type of each node to distinguish whether the node is a node scan node (NODE_SCAN) or an edge traversal node (EDGE_TRAVERSE).

[0110] S332. Inject the node-level governance predicate node into the node scanning node: When the compiler identifies the currently accessed node as a node scanning node, the compiler performs the following operations:

[0111] (1) Matching row-level filtering rules: The compiler traverses the set of row filtering rules in the governance strategy based on the node type label (nodeLabel) contained in the node scanning node. For each row filtering rule, the compiler calls the node matching function (matchesNode) to determine whether the target table identifier (targetTable) of the row filtering rule matches the current node type label. If the match is successful, the compiler calls the predicate construction function (buildPredicate) to convert the condition expression in the row filtering rule into a governance predicate node, and sets the governance injection flag of the governance predicate node to true (setGovernanceInjected(true)), while setting the policy source identifier (setPolicySource) of the governance predicate node to the policy identifier of the row filtering rule. The compiler adds the governance predicate node to the filter condition list (filters) of the current node scanning node through the append function (appendFilter).

[0112] (2) Matching column mask rules: The compiler iterates through the set of column mask rules (columnMasks) in the governance strategy based on the node type tags contained in the node scanning node. For each column mask rule, the compiler calls the node attribute matching function (matchesNodeProp) to determine whether the target column identifier (targetColumn) of the column mask rule matches the attributes contained in the current node type. If the match is successful, the compiler calls the governance annotation creation function (createAnnotation) to generate a governance annotation containing the mask type tag (GOV_COLUMN_MASK), the policy identifier, the policy version number, and the mask expression, and stores the governance annotation in the governance annotation field (governance) of the current node scanning node.

[0113] S333, Inject the edge-level governance predicate node into the edge traversal node: When the compiler identifies the currently visited node as an edge traversal node, the compiler performs the following operations: The compiler iterates through the set of edge-level filtering rules (edgeFilters) in the governance strategy based on the edge type label (edgeLabel) contained in the edge traversal node. For each edge-level filtering rule, the compiler calls the edge matching function (matchesEdge) to determine whether the target table identifier (targetTable) of the edge-level filtering rule matches the current edge type label. If a match is successful, the compiler calls the predicate construction function to convert the conditional expression in the edge-level filtering rule into a governance predicate node, sets the governance injection flag of the governance predicate node to true, and sets the policy source identifier of the governance predicate node to the policy identifier of the edge-level filtering rule. The compiler then appends the governance predicate node to the filter condition linked list (filters) of the current edge traversal node using an append function.

[0114] S334. Maintain the path structure of the graph traversal abstract syntax tree unchanged: During the injection of the governance predicate node, the compiler only adds the governance predicate node to the filter condition linked list of the node scanning node and the edge traversal node, without modifying the next pointer and children pointer between nodes, and without adding or deleting any node scanning node or edge traversal node, ensuring that the traversal path structure of the graph traversal abstract syntax tree remains consistent with that before injection.

[0115] S335. Output the graph traversal abstract syntax tree after injection is complete: After the compiler completes the traversal and injection operations of all node scanning nodes and edge traversal nodes in the graph traversal abstract syntax tree, it outputs the graph traversal abstract syntax tree with the injected governance predicate node to step S4.

[0116] In a preferred embodiment of the present invention, the graph query result set obtained after injection by the governance predicate node is a subset of the original result set before injection, so that the injection operation of the governance predicate node in the graph traversal abstract syntax tree maintains semantic contractility. The semantic contractility is achieved in the following way: The injection operation of the governance predicate node only adds conjunctive predicates to the filtering conditions of the node scanning node and the edge traversal node, and does not modify the traversal path structure of the graph traversal abstract syntax tree. The addition of the conjunctive predicate only reduces the set of nodes and edges that meet the conditions.

[0117] Step S4: Select the corresponding graph query dialect compiler according to the target graph database engine, and compile the graph traversal abstract syntax tree with the governance predicate node injected into the target graph query language statement through the graph query dialect compiler. During compilation, the governance predicate node is expanded into the filter clause corresponding to the target graph query language.

[0118] In a preferred embodiment of the present invention, step S4 includes: selecting a corresponding graph query dialect compiler according to the type of the target graph database engine; compiling the graph traversal abstract syntax tree with governance predicate nodes injected into the target graph query language statement through the graph query dialect compiler, wherein the governance predicate nodes are expanded into filter clauses corresponding to the target graph query language during compilation.

[0119] In a preferred embodiment of the present invention, the target graph query language includes at least one of a graph query language based on Open Cypher syntax and the SPARQL protocol and RDF query language.

[0120] It should be noted that, for reference Figure 3 As shown, in a specific embodiment of the present invention, a graph traversal abstract syntax tree with injected governance predicate nodes is compiled into a target graph query language statement by a graph query dialect compiler. Specific steps include: S401. Identify the type of the target graph database engine and select the corresponding graph query dialect compiler: The compiler obtains the type identifier of the target graph database engine to which the current graph query session is connected. This type identifier is specified by the query client when establishing the graph query session, or is automatically identified by the compiler based on database connection configuration parameters. Based on the type identifier, the compiler selects a graph query dialect compiler corresponding to the target graph database engine from a pre-configured compiler registry. The graph query dialect compiler is used to convert a unified graph traversal abstract syntax tree into specific graph query language statements executable by the target graph database engine.

[0121] S402. Determine the target graph query language type based on the target graph database engine: The graph query dialect compiler supports at least one of the following target graph query languages: a graph query language based on the open Cypher syntax, for compatibility with graph database engines that support Cypher dialects, such as Neo4j and NebulaGraph; and a SPARQL protocol and RDF query language, for compatibility with graph database engines that support RDF triple storage. The graph query dialect compiler automatically determines the type of target graph query language to be generated based on the type of the target graph database engine.

[0122] S403. Compile the path structure in the graph traversal abstract syntax tree into the path pattern of the target graph query language: The graph query dialect compiler traverses the graph traversal abstract syntax tree injected with the governance predicate nodes, calls the path pattern construction function (buildPathPattern), and starts from the root node, according to the topological order of the next pointers and children pointers of each node in the graph traversal abstract syntax tree, sequentially converts the node scanning nodes and edge traversal nodes into path pattern clauses of the target graph query language.

[0123] Specifically: (1) For a node scan node (NODE_SCAN), the graph query dialect compiler converts it into a node pattern in the target graph query language. If the target graph query language is Cypher, the compiler generates a node pattern fragment in the format (n: node type label); if the target graph query language is SPARQL, the compiler generates the corresponding triple pattern fragment.

[0124] (2) For edge traversal nodes (EDGE_TRAVERSE), the graph query dialect compiler converts them into edge patterns in the target graph query language based on the traversal direction field in the edge traversal node. If the target graph query language is Cypher, when the traversal direction is forward (TRAVERSE_OUTGOING), the compiler generates an edge pattern fragment in the format -[:edge type label]->; when the traversal direction is reverse (TRAVERSE_INCOMING), it generates an edge pattern fragment in the format <-[:edge type label]-; when the traversal direction is bidirectional (TRAVERSE_BOTH), it generates an undirected edge pattern fragment in the format -[:edge type label]-.

[0125] The compiler concatenates the generated node pattern and edge pattern fragments into a complete path pattern clause.

[0126] S404. Expand the governance predicate nodes in the filter condition chain into filter clauses of the target graph query language: The graph query dialect compiler calls the filter condition construction function (buildWhereFromGraph), traverses the filter condition linked list (filters) of all nodes in the abstract syntax tree of the graph, and performs the following operations: (1) The compiler sequentially reads each governance predicate node in the filtering condition linked list of each node scan node and each edge traversal node. Each governance predicate node contains a constraint expression expressed in predicate logic form.

[0127] (2) For each governance predicate node, the compiler directly converts its constraint expression into a filter condition fragment in the target graph query language. If the target graph query language is Cypher, the filter condition fragment is the predicate expression in the WHERE clause; if the target graph query language is SPARQL, the filter condition fragment is the constraint expression in the FILTER clause.

[0128] (3) The compiler uses the conjunction operator (AND) to connect each filter condition fragment, ensuring that all governance predicate nodes are combined in a conjunction manner and does not introduce the disjunction operator (OR) to maintain semantic contractility.

[0129] (4) For a governance predicate node with the governance injection flag (isGovernanceInjected) being true, the compiler appends a comment to the corresponding filter condition fragment. The comment contains the policy source identifier of the governance predicate node to indicate that the filter condition is generated by governance policy injection.

[0130] S405. Compile the masking rules in the governance annotation fields into return clauses of the target graph query language: The graph query dialect compiler calls the return clause construction function (buildReturnWithMasks) to traverse each node in the graph traversal abstract syntax tree and scan the governance annotation fields of the nodes. For governance annotations containing column mask type markers (GOV_COLUMN_MASK), the compiler generates mask function call fragments for the corresponding columns in the return clause of the target graph query language based on the mask expression in the governance annotation, thereby achieving desensitization processing of sensitive columns in the returned results.

[0131] S406. Concatenate and generate a complete target graph query language statement: The graph query dialect compiler concatenates the path pattern clause generated in step S403, the filter condition clause generated in step S404, and the return clause generated in step S405 into a complete graph query language statement according to the syntax rules of the target graph query language. The complete graph query language statement includes a path pattern part, a filter condition part, and a return result part, wherein the filter condition part includes all expanded governance predicate nodes.

[0132] S407, Verify the semantic contractility of governance: After generating the target graph query language statement, the compiler calls the semantic contraction verification function (verifyGraphContraction) to compare and verify the graph traversal abstract syntax tree before and after the injection of governance predicate nodes. The verification function traverses the original graph traversal abstract syntax tree before injection and the graph traversal abstract syntax tree after injection, checking whether the filter condition list after injection contains all the original predicates (containsPredicate) from before injection. If any original predicate from before injection is missing from the filter condition list after injection, the verification fails, the compiler returns an error message and stops compilation; if all original predicates are retained, the verification passes, confirming that the query result set after governance injection is a subset of the original result set.

[0133] S408. Output the target graph query language statement: The compiler outputs the complete target graph query language statement generated in step S406 to the query execution engine for the target graph database engine to perform graph query operations.

[0134] In a preferred embodiment of the present invention, the graph traversal abstract syntax tree and the relational query abstract syntax tree share the same governance strategy descriptor during the governance injection phase, so that the same governance strategy produces consistent governance effects on graph queries and relational queries; the governance strategy descriptor is extended with an edge-level filtering rule field in the graph query scenario, and the edge-level filtering rule field is parallel to the row filtering rule field and column desensitization rule field of the relational query.

[0135] It should be noted that the ontology graph query governance-aware compilation method provided by this invention has governance compatibility with the relation query governance scheme. Specifically, the graph traversal abstract syntax tree of this invention and the relation query abstract syntax tree in the governance-aware relational algebra framework share the same set of governance strategy descriptor data structures during the governance injection phase.

[0136] The governance strategy descriptor is a unified data structure definition, independent of specific query types, and contains all constraint rules defined in the governance strategy. In relational query scenarios, the governance strategy descriptor includes a row filtering rule field and a column masking rule field. The row filtering rule field stores row-level access control rules for the relational table, and the column masking rule field stores column-level masking rules for the relational table. In the graph query scenario of this invention, the governance strategy descriptor extends the above-mentioned row filtering rule field and column masking rule field with an edge-level filtering rule field. The edge-level filtering rule field is parallel to the row filtering rule field and the column masking rule field in the governance strategy descriptor and is used to store edge-level access control rules during graph traversal.

[0137] The tenant isolation rules and row-level access control rules defined in the governance strategy are parsed and injected by a unified strategy engine. The strategy engine does not distinguish between query types; regardless of whether the constraint rules in the governance strategy apply to a SQL JOIN operation in a relational query or a graph traversal edge operation in a graph query, the strategy engine converts the constraint rules into corresponding governance predicate nodes according to the same parsing logic and adds the governance predicate nodes to the corresponding abstract syntax tree nodes according to the same injection logic.

[0138] Because graph queries and relational queries share the same governance strategy descriptor data structure and are parsed and injected by the same strategy engine, the same governance strategy exhibits consistency in governance effects across query types. Specifically, when a row filtering rule field in a relational query restricts a user to accessing only data from a specific tenant, an edge filtering rule field in a graph query similarly ensures that the user can only traverse data from the same specific tenant. This achieves unified governance semantics across graph queries and relational queries.

[0139] This compatibility design allows enterprises to reuse existing relational query governance strategy configurations instead of defining a new governance strategy for graph queries. This reduces the complexity of governance strategy management in multi-data-model scenarios and avoids the security risk of inconsistent governance effects due to different query types.

[0140] This invention can be implemented in conjunction with the "A Governance-Aware Query Compilation Method and System" filed by the applicant on the same day: the governance injection method of the graph traversal abstract syntax tree in this invention and the governance injection method of the relation query abstract syntax tree in the patent share the same governance strategy descriptor data structure, forming a unified governance injection system across query types.

[0141] This invention can also be implemented in conjunction with the "A Governance-Aware Query Intermediate Representation and Cross-Engine Compilation Method" filed by the applicant on the same day: the graph traversal abstract syntax tree in this invention and the ontology query intermediate representation in the patent share the same governance annotation field definition (GovernanceAnnotation), and metadata such as governance policy identifiers, policy version numbers and mask expressions can be directly transferred between the intermediate representations of the two patents.

[0142] This invention can be further implemented in conjunction with the applicant's "A Semantic Caching Method and System for Multi-tenant Query Compilation" filed on the same day: the hash value of the graph query statement of the injected governance predicate generated by this invention can be used as a component of the semantic cache key in that patent, so that the consistency of governance effect can still be guaranteed when the cache hits.

[0143] This embodiment uses a knowledge graph scenario as an example to illustrate the specific implementation process of the ontology graph query governance perception compilation method provided by the present invention.

[0144] (1) Query scenario and ontology mode settings Suppose that the knowledge graph ontology defines entity type nodes (Entity) and relation type edges (RELATES_TO). The entity type nodes contain entity identifier attributes (id) and tenant identifier attributes (tenant_ref), and the relation type edges (RELATES_TO) are used to represent the association between two entities. The tenant identifier of the current query session is "T001".

[0145] (2) Query the original map before treatment The query client submits the following graph query request: "Find all entities directly related to entity E001". This graph query request is expressed in the ontology object set query language as follows: MATCH (e:Entity)-[:RELATES_TO]->(related:Entity) WHERE e.id = 'E001' RETURN related The MATCH clause specifies the starting node type as Entity, the edge type as RELATES_TO, the traversal direction as forward, and the ending node type as Entity in the path pattern for graph traversal; the e.id='E001' in the WHERE clause is an attribute filtering condition that limits the entity identifier of the starting node to E001; the RETURN clause specifies that the ending node related is returned.

[0146] (3) Governance strategy configuration The system's pre-configured governance policy includes tenant isolation constraints. These constraints are defined as follows: any graph query is only allowed to return data belonging to the tenant of the current query session; specifically, the target node's `.tenant_ref` must equal the current session's tenant identifier. This governance policy is stored in the governance policy repository as a governance policy descriptor data structure, which the compiler retrieves at compile time.

[0147] (4) Compilation results after governance injection The compiler, following the methods described in steps S1 to S3, obtains the governance policy associated with the current query session, expresses the tenant isolation constraint as a governance predicate node, and performs governance injection during the compilation process of the graph traversal abstract syntax tree. Specifically, the compiler injects the governance predicate node corresponding to the tenant isolation constraint into the filter condition linked lists of the start node scan node and the end node scan node, respectively.

[0148] After governance injection, the compiler finally generates the following target Cypher query statement: MATCH (e:Entity)-[:RELATES_TO]->(related:Entity) WHERE e.id = 'E001' AND e.tenant_ref = 'T001' AND related.tenant_ref = 'T001' RETURN related Here, e.tenant_ref='T001' is a filter clause injected by the compiler into the starting node scanning node (e) after the expansion of the node-level governance predicate node, used to limit the tenant to which the starting node belongs to the current session tenant T001; related.tenant_ref='T001' is a filter clause injected by the compiler into the ending node scanning node (related) after the expansion of the node-level governance predicate node, used to limit the tenant to which the ending node belongs to the current session tenant T001.

[0149] (5) Explanation of the treatment effect After governance injection, the graph query above will first perform tenant isolation filtering on the starting node set and the ending node set based on the two filtering conditions e.tenant_ref='T001' and related.tenant_ref='T001', ensuring that all related entities returned ultimately come from the current tenant T001. Since both filtering conditions are added to the original query using conjunction (AND), without modifying the path structure of the graph traversal, the query result set after governance injection is a proper subset of the original result set before governance, guaranteeing semantic contractility.

[0150] Furthermore, the governance effect is completely consistent with the tenant isolation effect in relational query scenarios—if the above graph structure data is stored in the form of a relational table, when executing the corresponding SQL query, the governance strategy will also inject the row-level filtering condition tenant_ref='T001' into the relational query abstract syntax tree. This proves that the same tenant isolation governance strategy produces completely consistent governance semantics in graph queries and relational queries.

[0151] See Figure 4As shown, this invention provides a governance-aware compilation system for ontology graph queries, including a graph query parsing module for parsing graph query requests of ontology object set query language into a graph traversal abstract syntax tree; a graph governance injection module for expressing constraints in governance strategies as governance predicate nodes and injecting them into the node scanning and edge traversal positions in the graph traversal abstract syntax tree; and a graph dialect compilation module for compiling the graph traversal abstract syntax tree with injected governance predicates into a target graph query language statement.

[0152] The graph query parsing module, graph governance injection module, and graph dialect compilation module work sequentially to form a "parsing-injection-compilation" processing chain. The graph query parsing module parses the graph query request from the ontology object set query language into a graph traversal abstract syntax tree (bpd), and then passes it to the graph governance injection module. Upon receiving the bpd, the bpd module obtains the governance strategy for the current session, expresses each governance constraint as a governance predicate node, and injects it into the corresponding filtering condition chains of the node scan nodes and edge traversal nodes in the bpd. After injection, the bpd is passed to the graph dialect compilation module. The graph dialect compilation module receives the injected bpd, selects the appropriate graph query dialect compiler based on the target graph database engine type, compiles the path structure into a path pattern for the target graph query language, expands the governance predicate nodes into corresponding filtering clauses, compiles the mask rules in the governance annotations into return clauses, and finally generates a complete graph query language statement, which is then output to the query execution engine.

[0153] It should be noted that the order of the above embodiments of the present invention is merely for descriptive purposes and does not represent the superiority or inferiority of the embodiments. The processes depicted in the accompanying drawings do not necessarily require a specific or sequential order to achieve the desired result. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0154] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to interchangeably. The focus of each embodiment is on its differences from other embodiments. In particular, the apparatus embodiments are described simply because they are fundamentally based on the method embodiments; relevant details can be found in the descriptions of the method embodiments.

[0155] For ease of description, the above devices are described separately by function as various units. Of course, in implementing this application, the functions of each unit can be implemented in one or more software and / or hardware.

[0156] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, systems, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0157] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0158] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0159] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0160] Secondly: The accompanying drawings of the embodiments disclosed in this invention only involve the structures involved in the embodiments disclosed in this invention. Other structures can refer to the general design. In the absence of conflict, the same embodiment and different embodiments of this invention can be combined with each other.

[0161] In conclusion, the above description is only a preferred embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any equivalent substitutions or modifications made by those skilled in the art within the scope of the technology disclosed in the present invention, based on the technical solution and inventive concept of the present invention, should be covered within the scope of protection of the present invention.

Claims

1. A governance-aware compilation method for ontology graph querying, characterized in that, Includes the following steps: S1. Receive a graph query request expressed in an ontology object set query language, wherein the graph query request specifies at least the starting node type, edge path, traversal direction, and ending node type of the graph traversal. S2. Parse the graph query request and construct a graph traversal abstract syntax tree, which includes node scanning nodes, edge traversal nodes, and attribute filtering nodes. S3. Obtain the governance strategy associated with the current query session, express the tenant isolation constraint, access level constraint, usage restriction constraint, soft deletion filter constraint and result set size constraint in the governance strategy as governance predicate nodes, and inject the governance predicate nodes into the corresponding node scan node and edge traversal node in the graph traversal abstract syntax tree; S4. Select the corresponding graph query dialect compiler according to the target graph database engine, and compile the graph traversal abstract syntax tree with the governance predicate node injected into the target graph query language statement through the graph query dialect compiler. During compilation, the governance predicate node is expanded into the filter clause corresponding to the target graph query language.

2. The governance-aware compilation method for ontology graph query according to claim 1, characterized in that, Before injecting the governance predicate node, verify whether the current query session carries a valid tenant identifier; if the tenant identifier is missing or invalid, refuse to compile and return an error message, and do not allow graph queries to be executed without tenant isolation constraints.

3. The governance-aware compilation method for ontology graph query according to claim 1, characterized in that, Step S1 includes: The system receives graph query requests through an ontology query application programming interface; performs lexical and syntactic analysis on the graph query requests through a compiler; performs node type matching and edge type matching in a preset ontology schema registry; if the matching is successful, it constructs a query semantic tuple and passes it to step S2; if the matching fails, it returns an error message to the query client.

4. The governance-aware compilation method for ontology graph query according to claim 3, characterized in that, Step S2 includes: A graph traversal abstract syntax tree is constructed based on the query semantic tuple. The graph traversal abstract syntax tree has a path pattern node as the root node and includes node scanning nodes, edge traversal nodes, and attribute filtering nodes that are connected in traversal order.

5. The governance-aware compilation method for ontology graph query according to claim 1, characterized in that, The method for obtaining the governance policy associated with the current query session in step S3 includes: Extract the context information of the current query session, which includes at least the tenant identifier, access level label, and purpose label of the query initiator; Determine whether the node and edge types involved in the graph query request belong to multiple ontology spaces; If only a single ontology space is involved, the corresponding governance policy is obtained from the governance policy repository using the identifier of that ontology space, the tenant identifier, the access level label, and the purpose label as indexes; If multiple ontology spaces are involved, the corresponding governance strategies are obtained from each participating ontology space, and the multiple governance strategies are merged into a unified set of governance predicate nodes according to a preset merging strategy. The merger strategy includes any of the following: Take the intersection of the governance strategies of each participating ontology space to ensure that the combined governance constraints are no weaker than the governance constraints of any single participant. Take the union of the governance strategies of each participating ontology space, so that the merged governance constraints cover the governance constraints of each participating party; The governance strategy of the ontology space where the data source is located shall prevail; The governance strategy of the ontology space where the query originates shall prevail.

6. The governance-aware compilation method for ontology graph query according to claim 5, characterized in that, The default choice of the merging strategy is to take the intersection of the governance strategies of each participating ontology space to ensure that the governance constraints after merging are not weaker than the governance constraints of any one participant, and the selection result of the merging strategy is recorded in the audit metadata included in the compilation result.

7. The governance-aware compilation method for ontology graph query according to claim 1, characterized in that, The method for expressing the governance strategy as a governance predicate node in step S3 includes: Parse the governance strategy to obtain constraint rule entries; generate corresponding governance predicate nodes according to constraint type identifiers; and attach strategy source information to each governance predicate node.

8. The governance-aware compilation method for ontology graph query according to claim 1, characterized in that, The method for injecting the governance predicate node into the graph traversal abstract syntax tree in step S3 includes: The graph traversal abstract syntax tree is traversed; when a node is identified and the node is scanned, row filtering rules and column masking rules are matched and the matching results are converted into node-level governance predicate nodes and governance annotations for injection; when an edge is identified and the node is traversed, edge-level filtering rules are matched and the matching results are converted into edge-level governance predicate nodes for injection; during the injection process, the traversal path structure of the graph traversal abstract syntax tree remains unchanged.

9. The governance-aware compilation method for ontology graph query according to claim 1, characterized in that, The graph query result set obtained after the injection of the governance predicate node is a subset of the original result set before injection, so that the injection operation of the governance predicate node in the graph traversal abstract syntax tree maintains semantic contractility. The semantic contractility is achieved in the following ways: The injection operation of the governance predicate node only adds conjunctive predicates to the filtering conditions of the node scanning node and the edge traversal node, and does not modify the traversal path structure of the graph traversal abstract syntax tree. The addition of the conjunctive predicate only reduces the set of nodes and edges that meet the conditions.

10. The governance-aware compilation method for ontology graph query according to claim 1, characterized in that, Step S4 includes: Select the corresponding graph query dialect compiler according to the type of the target graph database engine; compile the graph traversal abstract syntax tree with governance predicate nodes injected into the target graph query language statement through the graph query dialect compiler. During compilation, the governance predicate nodes are expanded into the filter clauses corresponding to the target graph query language.

11. The governance-aware compilation method for ontology graph query according to claim 1, characterized in that, The target graph query language includes at least one of the following: a graph query language based on Open Cypher syntax, the SPARQL protocol, and the RDF query language.

12. The governance-aware compilation method for ontology graph query according to claim 1, characterized in that, The graph traversal abstract syntax tree and the relational query abstract syntax tree share the same governance strategy descriptor during the governance injection phase, so that the same governance strategy produces consistent governance effects in graph queries and relational queries; the governance strategy descriptor is extended with an edge-level filtering rule field in the graph query scenario, and this edge-level filtering rule field is parallel to the row filtering rule field and column desensitization rule field of relational queries.

13. A governance-aware compilation system for ontology graph querying, characterized in that, It includes a graph query parsing module, which parses graph query requests from ontology object set query language into a graph traversal abstract syntax tree; and a graph governance injection module, which expresses constraints in governance strategies as governance predicate nodes and injects them into the node scanning and edge traversal positions in the graph traversal abstract syntax tree. The graph dialect compilation module is used to compile the graph traversal abstract syntax tree with injected governance predicates into the target graph query language statement.

Images