A dynamic knowledge graph driven cross-department government data collaboration method and system

Abstract

Embodiments of the present disclosure provide a dynamic knowledge graph driven cross-department government data collaboration method and system. The method is applied to the technical field of computer science and technology, and comprises: acquiring cross-department government business data and corresponding policy rule data, constructing data knowledge graph and strategy knowledge graph, and based on preset event information, incrementally updating and consistency checking the knowledge graph, extracting the latest business status and the latest policy rules. Through joint reasoning, the minimum necessary data view and the authorized range are generated, and on this basis, efficient and safe collaboration of cross-department government data is realized, and accurate authorization and compliance management of data access are realized. The scheme only provides necessary data and strictly controls access rights in cross-department government data collaboration, significantly improves data sharing efficiency, security and compliance, and at the same time reduces the risk of unauthorized access and redundant data transmission.

Description

Technical Field

[0001] This disclosure relates to the technical field of computer science and technology, and in particular to a dynamic knowledge graph-driven method and system for cross-departmental government data collaboration. Background Technology

[0002] With the deepening of e-government digitalization reform, cross-departmental business collaboration has become a key link in improving government governance efficiency. Government data is scattered across different departmental systems, and policies and rules are subject to dynamic adjustments, making traditional data sharing models insufficient to meet the requirements of real-time performance, accuracy, and compliance. Existing technologies lack the ability to model the relationship between business data and policy rules, leading to problems such as information lag, rule conflicts, and ambiguous permissions during cross-departmental data collaboration, thus hindering the integration of e-government services and the scientific nature of decision-making.

[0003] Existing cross-departmental government data collaboration technologies mainly rely on traditional technical architectures: ETL tools are used to periodically extract business data from various departments to a central database for centralized storage; static data catalogs are built based on keyword matching technology to describe data assets; policy documents are manually sorted to form rule documents; and authorization management is carried out in the data sharing process through pre-set permission templates.

[0004] However, the existing data update mechanism relies on periodic batch processing, which makes it impossible to synchronize changes in business status and policy and rule adjustments in real time, resulting in a lag in decision-making. The permission management uses a fixed template, which cannot dynamically adjust the authorization boundaries according to specific scenarios, posing a risk of data abuse. Policy and rule updates rely on offline manual processes, which are inefficient and prone to inconsistencies in execution due to differences in human interpretation. At the same time, a large amount of human resources need to be continuously invested in maintenance, making it difficult to meet the core needs of "minimum necessary" sharing and accurate authorization of government data. Summary of the Invention

[0005] To address the shortcomings of existing technologies, this disclosure provides a dynamic knowledge graph-driven method and system for cross-departmental government data collaboration. This disclosure resolves the problems of existing technologies, which rely on periodic batch processing for data updates, resulting in a lack of real-time synchronization between changes in business status and policy adjustments, leading to delayed decision-making; the use of fixed templates for access control, which cannot dynamically adjust authorization boundaries according to specific scenarios, posing a risk of data misuse; and the reliance on offline manual processes for policy updates, which are inefficient and prone to inconsistencies due to differences in human interpretation, while requiring continuous and substantial human resources for maintenance. Overall, these technologies fail to meet the core needs of "minimum necessary" sharing and precise authorization of government data.

[0006] According to a first aspect of this disclosure, a dynamic knowledge graph-driven method for cross-departmental government data collaboration is provided, comprising: acquiring cross-departmental government business data and corresponding policy rule data, constructing a data knowledge graph based on the cross-departmental government business data, and constructing a strategy knowledge graph based on the policy rule data;

[0007] Obtain preset event information, and perform incremental updates and consistency checks on the data knowledge graph and the strategy knowledge graph based on the preset event information to obtain the updated data knowledge graph and the updated strategy knowledge graph.

[0008] Extract the latest business status from the updated data knowledge graph, and extract the latest policy rules from the updated strategy knowledge graph;

[0009] Based on the latest business status and the latest policy rules, joint reasoning is performed to obtain the minimum necessary data view and the scope of authorization. Based on the minimum necessary data view and the scope of authorization, cross-departmental government data collaboration is carried out.

[0010] According to a second aspect of this disclosure, a dynamic knowledge graph-driven cross-departmental government data collaboration system is provided for performing the method described in the first aspect, comprising: a graph construction module for acquiring cross-departmental government business data and corresponding policy rule data, constructing a data knowledge graph based on the cross-departmental government business data, and constructing a strategy knowledge graph based on the policy rule data;

[0011] The dynamic update module is used to acquire preset event information, and perform incremental updates and consistency checks on the data knowledge graph and the strategy knowledge graph based on the preset event information to obtain the updated data knowledge graph and the updated strategy knowledge graph.

[0012] The extraction module is used to extract the latest business status from the updated data knowledge graph and the latest policy rules from the updated strategy knowledge graph.

[0013] The cross-departmental collaboration module is used to perform joint reasoning based on the latest business status and the latest policy rules to obtain the minimum necessary data view and the scope of authorization, and to carry out cross-departmental government data collaboration based on the minimum necessary data view and the scope of authorization.

[0014] According to a third aspect of this disclosure, an electronic device is provided, comprising: a memory and a processor, wherein the memory stores a computer program, and the processor executes the program to implement the method described above.

[0015] In the dynamic knowledge graph-driven cross-departmental government data collaboration method and system provided above, the embodiments of this disclosure provide only necessary data and strictly control access permissions in cross-departmental government data collaboration, which significantly improves data sharing efficiency, security and compliance, while reducing the risk of unauthorized access and redundant data transmission. Attached Figure Description

[0016] To more clearly illustrate the technical solutions in the embodiments of this disclosure or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of this disclosure. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0017] Figure 1 A schematic diagram of a dynamic knowledge graph-driven cross-departmental government data collaboration method according to an embodiment of the present disclosure is shown.

[0018] Figure 2 A schematic diagram of a dynamic knowledge graph-driven cross-departmental government data collaboration method according to an embodiment of the present disclosure is shown.

[0019] Figure 3 A schematic block diagram of a dynamic knowledge graph-driven cross-departmental government data collaboration system according to an embodiment of the present disclosure is shown.

[0020] Figure 4 A schematic diagram of the structure of an electronic device according to an embodiment of the present disclosure is shown. Detailed Implementation

[0021] Various exemplary embodiments of the present disclosure will now be described in detail with reference to the accompanying drawings. It should be noted that, unless otherwise specifically stated, the relative arrangement, numerical expressions, and values ​​of the components and steps set forth in these embodiments do not limit the scope of the present disclosure.

[0022] Those skilled in the art will understand that the terms "first," "second," etc., in the embodiments of this disclosure are only used to distinguish different steps, devices, or modules, and do not represent any specific technical meaning, nor do they indicate a necessary logical order between them. It should also be understood that in the embodiments of this disclosure, "multiple" can refer to two or more, and "at least one" can refer to one, two, or more. It should also be understood that any component, data, or structure mentioned in the embodiments of this disclosure can generally be understood as one or more unless explicitly limited or given a contrary indication in the context. Furthermore, the term "and / or" in this disclosure is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. Additionally, the character " / " in this disclosure generally indicates that the related objects before and after are in an "or" relationship. It should also be understood that the descriptions of the various embodiments in this disclosure emphasize the differences between the various embodiments; their similarities or commonalities can be referred to mutually, and for the sake of brevity, they will not be elaborated upon one by one.

[0023] Furthermore, it should be understood that, for ease of description, the dimensions of the various parts shown in the accompanying drawings are not drawn to actual scale. The following description of at least one exemplary embodiment is merely illustrative and is in no way intended to limit this disclosure or its application or use. Techniques, methods, and apparatus known to those skilled in the art will not be discussed in detail, but where appropriate, such techniques, methods, and apparatus should be considered part of the specification. It should be noted that similar reference numerals and letters in the following drawings denote similar items; therefore, once an item is defined in one drawing, it need not be further discussed in subsequent drawings.

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

[0025] Figure 1 This is a schematic flowchart illustrating a dynamic knowledge graph-driven cross-departmental government data collaboration method provided in an embodiment of this disclosure. The method in this embodiment aims to achieve accurate detection of both large and small targets in images.

[0026] S101, acquire cross-departmental government affairs data and corresponding policy rule data, construct a data knowledge graph based on the cross-departmental government affairs data, and construct a strategy knowledge graph based on the policy rule data.

[0027] Cross-departmental government business data can refer to business-related data generated, collected, or stored by different government departments in the process of performing public management and social service functions. The data includes population information, enterprise registration information, social security data, real estate registration data, financial and tax data, medical insurance data, etc. This type of data is usually stored in different departmental systems and has the characteristics of inconsistent formats and standards.

[0028] Policy and rule data can refer to laws, regulations, administrative rules, departmental rules, policy documents and business rules formulated and issued by national or local governments to regulate the handling of government affairs and service processes, including handling conditions, time limits, material lists, scope of application, approval constraints, etc., and are used to guide the collaborative processing of cross-departmental government affairs.

[0029] A data knowledge graph can refer to a graph-based knowledge model built on cross-departmental government business data. It is used to represent the semantic relationships and business associations between data from different departments. These relationships include the associations between objects such as people, enterprises, assets, and events, thereby enabling semantic fusion of heterogeneous data, unified modeling, and intelligent retrieval of cross-departmental data.

[0030] A strategy knowledge graph can refer to a graph-based knowledge model constructed based on policy and rule data. It is used to represent the relationships between policy clauses, rule constraints, and conditional logic. These relationships include the mapping between policies and applicable objects, conditions, restrictions, and processing procedures, thereby enabling the structured expression, automatic reasoning, and compliance verification of policy rules.

[0031] First, cross-departmental government business data is acquired. This data can be obtained by establishing a secure interface with the government data exchange platform and extracting data scattered across departmental databases such as population information databases, business registration databases, social security databases, and real estate registration databases. After data extraction, data cleaning and standardization techniques are employed, including missing value imputation, format unification, entity deduplication, and synonym merging, to ensure data structure and consistency. Following cleaning, entity recognition and relation extraction are performed. Named Entity Recognition (NER) algorithms based on natural language processing and relation extraction methods based on dependency parsing are used to identify entities such as people, enterprises, assets, and events, as well as their semantic relationships. Subsequently, graph database modeling techniques (such as Neo4j) are used to perform graph-based modeling of the extracted entities and relationships, resulting in a data knowledge graph to achieve semantic fusion and structured storage of cross-departmental data.

[0032] In acquiring policy and rule data, text data can be extracted or parsed from legal databases, government gazettes, and policy document management systems. First, Optical Character Recognition (OCR) technology is used to recognize the text in scanned documents. Then, text segmentation and syntactic analysis techniques are employed to perform structured parsing of the policy text. Based on rule extraction and machine learning methods, rule elements such as conditional constraints, scope of application, and processing procedures are extracted from policy clauses. For example, a method based on regular expressions and conditional logic modeling is used to parse the constraint statement "the processing time limit shall not exceed 15 working days," transforming it into a formalized conditional expression. On this basis, knowledge representation technologies (such as RDF / OWL ontology modeling) are used to construct multidimensional semantic relationships between policy clauses, processing conditions, objects, and rules, and these relationships are stored and retrieved through a graph database, forming a policy knowledge graph.

[0033] S102, obtain preset event information, and perform incremental update and consistency check on the data knowledge graph and the strategy knowledge graph according to the preset event information to obtain the updated data knowledge graph and the updated strategy knowledge graph.

[0034] Preset event information can refer to a set of key events that may trigger knowledge graph updates during cross-departmental government business collaboration. These key events include, but are not limited to: data record events where data is added, modified, or deleted in government data sources; events where the structure or field rules of departmental databases change; and events where relevant policies, regulations, departmental rules, or work guidelines are updated, repealed, or added.

[0035] An updated data knowledge graph can refer to a knowledge graph instance formed after incremental updates and consistency checks are performed on the original data knowledge graph based on newly added or modified cross-departmental government business data following the detection of preset event information.

[0036] An updated policy knowledge graph can refer to a knowledge graph instance formed after incremental updates and consistency checks are performed on the original policy knowledge graph based on newly added or modified policy rule data following the detection of preset event information.

[0037] The preset event information can be captured by multi-source data change detection technology. Specifically, for data updates in cross-departmental government business databases, database triggers and change data capture mechanisms can be used to record addition, modification, and deletion operations. For changes in departmental database structure or field rules, metadata comparison algorithms can be used to periodically scan the data table structure and compare historical version differences. For changes in policy and rule data, Natural Language Processing (NLP) technology can be used to automatically parse newly released policy and regulatory documents, extract rule clauses, applicable conditions, and scope of effect, and compare them with existing rule sets. The above-mentioned multiple detection results are aggregated by an event monitoring engine to form the preset event information.

[0038] Then, based on the preset event information, incremental updates are performed on the data knowledge graph. Specifically, when the addition or modification of cross-departmental government business data is detected, entity recognition and relation extraction algorithms (such as BERT-based named entity recognition and relation extraction based on dependency parsing) are used to semantically model the changed data, generating new entity nodes and relation edges; under data deletion events, the corresponding entities and their edge relationships are located and logical deletion is performed. The updated nodes and edges need to be verified through a consistency check mechanism, including structural constraint checks based on graph databases (such as mandatory primary key uniqueness and essential attribute integrity), and logical consistency checks based on knowledge reasoning (such as OWL ontology rule reasoning and SPARQL query constraint detection), thereby ensuring that the data semantics are correct and conflict-free.

[0039] Based on the preset event information, incremental updates are performed on the strategy knowledge graph. When a change in policy rule data is detected, rule extraction and logical modeling techniques (such as regularized text parsing combined with semantic role labeling-based logical transformation) are first used to transform the new clauses into formal rule nodes, establishing the association between the clauses and applicable departments and business scenarios. For expired or repealed policy clauses, they are marked as "expired" in the knowledge graph. After the update is completed, rule consistency verification is performed, including ontology-based logical reasoning to determine whether there are conflicts between rules, and time-series logic calculation to determine whether the applicable time periods of the new and old clauses overlap or contradict each other. Finally, after the above incremental update and consistency verification processes, the updated data knowledge graph and the updated strategy knowledge graph are obtained respectively.

[0040] Based on the above technical solution, optionally, after obtaining the updated data knowledge graph and the updated policy knowledge graph, the method further includes:

[0041] If the updated data knowledge graph and the updated strategy knowledge graph do not conform to the preset consistency rules, perform graph structure analysis on the updated data knowledge graph to obtain isolated node data and circular dependency data.

[0042] Logical constraint analysis is performed on the updated strategy knowledge graph to obtain cross-graph conflict relationship data;

[0043] Perform node reconstruction processing on the isolated node data to obtain reconstructed node data;

[0044] Perform edge redirection processing on the circular dependency data to obtain redirected edge data;

[0045] Redundant data removal is performed on the cross-graph conflict relationship data to obtain simplified data;

[0046] Based on the reconstructed node data, redirected edge data, and simplified data, the updated data knowledge graph and strategy knowledge graph are repaired to obtain the repaired updated data knowledge graph and strategy knowledge graph.

[0047] Accordingly, the latest business status is extracted from the updated data knowledge graph, and the latest policy rules are extracted from the updated strategy knowledge graph, including:

[0048] Extract the latest business status from the repaired and updated data knowledge graph, and extract the latest policy rules from the repaired and updated strategy knowledge graph.

[0049] In this solution, the pre-defined consistency rules refer to a set of rules predefined during the construction and updating of the data knowledge graph and the policy knowledge graph to ensure that they maintain coordination at the semantic, logical, and structural levels. These consistency rules include, but are not limited to: node uniqueness rules (preventing duplicate definitions of the same entity), edge relationship non-conflict rules (avoiding contradictory definitions of the same relationship), semantic matching rules (ensuring semantic alignment between policy constraints and data entities), hierarchical integrity rules (avoiding missing upper or lower layer dependencies), and cross-graph logical consistency rules (ensuring no conflict in the mapping relationship between business data and policy constraints).

[0050] Isolated node data refers to independent data entity nodes in the updated knowledge graph that have not established effective connections with other nodes. These nodes are often formed due to missing data, broken relationships, or rule conflicts. If not handled, they will lead to an incomplete knowledge graph structure, thereby affecting the correctness of the reasoning results.

[0051] Circular dependencies refer to circular dependencies that appear in a data knowledge graph, where a data entity directly or indirectly depends on itself, resulting in a logical loop that cannot be resolved. For example, task A depends on task B, and task B depends on task A.

[0052] Cross-graph conflicting relationships refer to mutually exclusive or contradictory relationships that exist between a data knowledge graph and a policy knowledge graph. For example, the data knowledge graph may show that a data node can be shared, while the policy knowledge graph may stipulate that the same data node is not accessible to external parties.

[0053] Reconstructed node data can refer to the set of repaired nodes generated during the repair process of isolated nodes by introducing new semantic relationships, supplementing missing upstream and downstream connections, or merging redundant nodes based on similarity matching.

[0054] Redirected edge data can refer to the new set of edges generated when repairing circular dependencies by reallocating edge pointers, adjusting dependency paths, or introducing virtual intermediate nodes.

[0055] Simplified data can refer to the refined data set obtained by deleting redundant fields, removing conflicting edge relationships, and eliminating invalid strategy constraints in the process of resolving cross-graph conflicts.

[0056] The repaired and updated data knowledge graph and policy knowledge graph refer to the version of the knowledge graph that meets the consistency rule requirements after node reconstruction, edge redirection, and data simplification. This version of the graph maintains connectivity and order in structure, eliminates ambiguity and contradictions in semantics, and can serve as a reliable data support and policy constraint basis for subsequent business state extraction and policy rule extraction.

[0057] When the updated data knowledge graph and the updated strategy knowledge graph fail to meet the preset consistency rules, graph structure analysis is first performed on the updated data knowledge graph. In the specific implementation, a combination of depth-first traversal and breadth-first traversal is used to detect nodes that do not form valid edge relationships with other nodes and extract them as isolated node data. Simultaneously, a strongly connected component decomposition algorithm is used to analyze the dependencies between nodes in the graph. If self-loops or multi-node cycles are found, the corresponding dependency sets are marked as circular dependency data.

[0058] Subsequently, logical constraint analysis is performed on the updated policy knowledge graph. In the specific implementation, the policy constraint expressions are parsed based on predicate logic, and the SAT / SMT (Satisfiability Solver / Modal Theory Solver) algorithm is used to determine whether there are mutually exclusive or contradictory relationships between the policy rules. When it is detected that a certain business data node is marked as shareable in the data knowledge graph, but simultaneously marked as prohibited from sharing in the policy knowledge graph, the contradictory constraint is extracted as cross-graph conflict relationship data.

[0059] For the isolated node data, node reconstruction processing is performed. Specifically, this includes: performing semantic similarity matching between isolated nodes and existing nodes based on cosine similarity calculation and embedding representation learning (such as Node2Vec or TransE). If the similarity exceeds a preset threshold, the isolated node is merged into the group of nodes with the closest semantics; if no match is found, the missing relation edges are inferred based on knowledge completion algorithms (such as ComplEx or DistMult) to supplement the upstream and downstream connections for the isolated node, thus obtaining the reconstructed node data.

[0060] For the circular dependency data, edge redirection processing is performed. In the specific implementation, a topological sorting algorithm is used to identify the key edges in the circular chain, and a dependency rewriting strategy (such as adjusting the order of task execution or introducing virtual intermediate nodes to break the loop) is used to make the dependency path unidirectional, ultimately obtaining the redirected edge data.

[0061] For the cross-graph conflict relationship data, redundant data removal is performed. In the implementation, a priority constraint rule set is used, where security has a higher priority than sharing, and compliance has a higher priority than business convenience. Conflicting edge relationships or attributes are judged according to priority, and low-priority redundant constraints or contradictory edge relationships will be removed to obtain simplified data.

[0062] Based on the reconstructed node data, redirected edge data, and simplified data, a repair operation is performed on the updated data knowledge graph and policy knowledge graph. Specifically, this includes: re-inserting the reconstructed nodes into the main graph structure, replacing the original isolated nodes; updating the redirected edge relationships in the dependency chains, replacing circular dependency edges; and writing the simplified data, after removing redundant constraints, into the policy knowledge graph, forming a repaired and updated data knowledge graph and policy knowledge graph whose structure, logic, and semantics all satisfy the consistency rules.

[0063] Accordingly, in the data extraction stage, instead of directly extracting from the unrepaired knowledge graph, the latest business status is extracted based on the repaired and updated data knowledge graph to ensure that the business entities and their relationships are semantically complete and logically correct. Furthermore, the latest policy rules are extracted based on the repaired and updated policy knowledge graph to ensure that the extracted policy constraints are logically conflict-free and meet compliance priorities, thereby providing a reliable foundation for subsequent joint reasoning and cross-departmental government data collaboration.

[0064] This solution analyzes and repairs defects in the data map to ensure data and policy consistency, extracts the latest business status and policy rules, and ensures both data accuracy and compliance while efficiently supporting task processing, thereby achieving precise linkage between data governance and business decision-making.

[0065] S103, extract the latest business status from the updated data knowledge graph, and extract the latest policy rules from the updated strategy knowledge graph.

[0066] The latest business status refers to the real-time and valid status of business data entities and their relationships extracted from the updated data knowledge graph after incremental updates and consistency checks of cross-departmental government business data. The latest business status includes, but is not limited to, the latest values ​​of cross-departmental business data, updates to structured fields, business process execution progress, task node status, and data relationships.

[0067] The latest policy rules refer to policy provisions and their logical constraints that are currently applicable and extracted from the updated strategy knowledge graph after parsing, modeling, incrementally updating, and verifying the policy rule data. These latest policy rules include, but are not limited to: policy and regulatory provisions, scope of application, timeliness conditions, execution constraint logic, priority order, and semantic relationships with relevant departments and business data.

[0068] For the updated data knowledge graph, queries are constructed using the graph database query language SPARQL, retrieving business data entities from the graph based on timestamps, version numbers, and data source identifiers. By comparing the timestamp fields of different version nodes, the data entity corresponding to the latest timestamp and its semantic relationships are selected. Relational reasoning techniques are then used to logically infer the upstream and downstream dependencies, thereby extracting the latest business status of each business process node, including business execution progress, task completion status, pending task nodes, and their dependency constraints.

[0069] Secondly, for the updated strategy knowledge graph, a rule engine combined with ontology reasoning technology is used to parse the policy clause entities. Specifically, an OWL-based inference engine is used to verify the logical consistency of policy clauses, conditions, and applicable objects in the strategy knowledge graph. Using the latest effective date, expiration date, and scope of application as search criteria, expired policy rules are filtered out, and currently valid policy clauses are extracted. By calculating the priority ranking field among the rules, the latest policy rules with actual binding force are obtained, including the applicable department, timeliness conditions, execution order, and related business data constraints.

[0070] S104. Perform joint reasoning based on the latest business status and the latest policy rules to obtain the minimum necessary data view and the scope of authorization, and conduct cross-departmental government data collaboration based on the minimum necessary data view and the scope of authorization.

[0071] A minimum necessary data view refers to the minimum set of data necessary to meet specific government service processing requirements, derived from joint reasoning based on the latest business status and policy rules when performing cross-departmental government service collaboration. This data view is presented in a structured or semi-structured manner, containing key data fields and their logical relationships required to complete the business processing, while excluding redundant data irrelevant to the current business.

[0072] The scope of authorization refers to the data access permission boundaries determined according to the latest policies and rules, which are used to constrain the access permissions of participating departments in cross-departmental government data collaboration. This scope of authorization typically includes the following dimensions: the access subject (i.e., department or user identity), the data objects that can be accessed, the data types that can be manipulated (query, write, update), time limits, and data usage restrictions.

[0073] A semantic reasoning engine (such as the OWL inference engine or an RDF schema-based inference tool) is used to semantically associate the latest business state with the latest policy rules, establishing a logical constraint mapping relationship between business entity nodes and policy rule condition nodes. By performing rule matching on RDF triples through the inference engine, it is possible to identify which business entities fall within the scope of necessary data supply in the current scenario. Constraint solving methods are used to calculate the conditional restrictions in the policy rules, such as the legality of data access subjects, access frequency limits, and data anonymization requirements. Specifically, first-order logic expressions are used to transform the policy rules into computable constraints, and combined with the data attribute values ​​in the business state, Boolean logic is performed to obtain a candidate data set that satisfies all constraints.

[0074] Graph traversal and subgraph extraction algorithms are used to select subgraphs that meet candidate conditions from the data knowledge graph, forming the minimum necessary data view. A combination of breadth-first search (BFS) and depth-first search (DFS) is employed to ensure that the extracted data set covers all necessary nodes while eliminating irrelevant nodes and redundant edges. Based on the access subject permission clauses in the latest policy rules, and combined with the candidate data set, Role-Based Access Control (RBAC) and Attribute-Enhanced Access Control (ABAC) mechanisms are used to determine the data scope and operational permissions that each access subject can access in the current business collaboration, thus forming the authorization scope. RBAC is used to determine department-level role permissions, while ABAC is used to impose attribute constraints on specific data objects at a fine-grained level, such as "only access to the last three months of business transaction data is allowed."

[0075] Based on the minimum necessary data view generated by joint inference, core data fields relevant only to current cross-departmental government collaboration matters are filtered from the business databases of each department, such as the legal representative's name and unified social credit code in enterprise registration information, rather than complete data tables. This method eliminates redundant data and reduces unnecessary data exposure at the source.

[0076] Secondly, the system strictly limits data access permissions using authorization scopes. These authorization scopes are derived from policy rules parsed from the policy knowledge graph, specifically including the accessing entity (department, role), accessible data types, access methods (query, download, verification), and access timeliness. The system employs attribute-based access control technology, combining the accessing user's identity attributes, task context, and authorization scope for multi-dimensional matching to ensure that data access strictly complies with policy and business requirements.

[0077] Then, during cross-departmental data transmission, the system employs homomorphic encryption and secure multi-party computation techniques to encrypt the transmitted data, enabling participants to complete joint computations without decryption and ensuring data privacy is not compromised. Simultaneously, by combining blockchain notarization and hash verification technologies, immutable log records are generated for each cross-departmental access operation, ensuring full traceability and auditability throughout the entire process.

[0078] Finally, during the collaborative execution phase, the system provides data interface call services to the target department based on the aforementioned minimum necessary data view, and dynamically adjusts the access frequency and validity period of the interface according to the authorized scope. When the collaborative task is completed or the authorization expires, the system automatically revokes access permissions and clears temporary caches to ensure a closed-loop data security system.

[0079] The embodiments of this application provide only the necessary data and strictly control access permissions in cross-departmental government data collaboration, which significantly improves the efficiency, security and compliance of data sharing, while reducing the risk of unauthorized access and redundant data transmission.

[0080] Based on the above technical solution, optionally, joint reasoning can be performed based on the latest business status and the latest policy rules to obtain the minimum necessary data view and authorization scope, including:

[0081] Obtain the target task, generate a task subgraph related to the target task in the updated data knowledge graph, and generate a compliance constraint subgraph related to the target task in the updated strategy knowledge graph;

[0082] Perform intersection pruning on the task subgraph and the compliance constraint subgraph to obtain the candidate data subgraph;

[0083] The candidate data subgraph is optimized based on preset constraint priority rules to generate the minimum necessary data view;

[0084] Obtain the department role mapping relationship, determine the field access permissions based on the data sensitivity level in the minimum necessary data view, and determine the authorization scope based on the field access permissions and the department role mapping relationship.

[0085] In this solution, the target task can refer to specific government collaboration matters triggered by business processes or driven by user requests in cross-departmental government affairs scenarios, such as cross-regional enterprise establishment approval, social security information comparison, or cross-departmental joint law enforcement. The target task typically includes a clearly defined task type, processing flow, and related data requirements.

[0086] A task subgraph can refer to a partial graph structure extracted from the updated data knowledge graph based on the data requirements of the target task. It includes entity nodes, attribute nodes, and their relationship edges that are directly related to the target task. For example, when the target task is enterprise approval, the task subgraph may include enterprise nodes, legal person nodes, and their association with data from departments such as industry and commerce and taxation.

[0087] A compliance constraint subgraph refers to a subgraph of restrictive knowledge extracted from the updated strategy knowledge graph, based on the policies, regulations, privacy protection requirements, and inter-departmental collaboration rules involved in the target task. This subgraph includes data usage constraints, access restrictions, timeliness rules, and compliance verification logic.

[0088] A candidate data subgraph can refer to the graph structure obtained by performing an intersection pruning operation on the task subgraph and the compliance constraint subgraph. The candidate data subgraph retains only the entities and relationships that both meet the data requirements of the target task and comply with the compliance constraints, and is the preliminary candidate result generated from the minimum necessary data view.

[0089] Preset constraint priority rules refer to the pre-defined order of constraint execution when multiple policy rules conflict or different constraints are applied concurrently. These rules typically include priorities based on legal and regulatory levels (e.g., national laws take precedence over departmental regulations) and priorities based on data sensitivity levels (e.g., privacy protection rules take precedence over general business rules), and are used to ensure that the results are compliant and reasonable when optimizing candidate data subgraphs.

[0090] Departmental role mapping refers to the correspondence between government departments and their internal roles or positions, used to define the scope of permissions for different roles in cross-departmental collaboration processes. For example, a regular clerk in a department may only be able to query some basic information, while an auditor may be able to view more sensitive data fields.

[0091] Data sensitivity levels refer to a classification system that categorizes data fields based on their importance, privacy, and potential risks. Common sensitivity levels include public data, internal data, sensitive data, and highly sensitive data, used to determine the strictness of field access permissions.

[0092] Field access permissions refer to the access operation permissions granted to specific data fields based on data sensitivity levels and departmental role mapping relationships. These permissions may include querying, modifying, downloading, or prohibiting access, in order to ensure that data use complies with the principle of minimum necessity and compliance requirements.

[0093] The target task can be defined by government approval events triggered by the business process engine, cross-departmental comparison requests, or user-submitted service applications. The system utilizes Natural Language Processing (NLP) technology to identify the intent of the task description and, based on task semantic parsing and entity extraction methods, maps the task content to specific entities and relationships in the updated data knowledge graph, thereby identifying the data scope required for the task. Subsequently, in the updated data knowledge graph, subgraph matching and graph traversal algorithms are used to generate a task subgraph related to the target task. This task subgraph contains the core business entities corresponding to the target task and their upstream and downstream relationship chains.

[0094] Meanwhile, in the updated policy knowledge graph, policy constraint nodes and edges related to the target task are extracted using rule matching, logical reasoning, and OWL-based semantic constraint reasoning techniques to generate corresponding compliance constraint subgraphs, including access restrictions, sensitive field markings, timeliness rules, and cross-departmental collaboration requirements.

[0095] Subsequently, the task subgraph and the compliance constraint subgraph are intersected and pruned. Specifically, the graph isomorphism detection and constraint consistency comparison algorithm is used to retain only entity nodes and relation edges that appear in both task requirements and compliance constraints, thereby obtaining the data range that meets business requirements and is compliant, forming a candidate data subgraph.

[0096] The system has a pre-defined set of constraint priority rules, which are sorted in multiple dimensions according to the level of regulations, privacy level, business urgency and data sharing security. For example, legal and regulatory constraints have the highest priority, which is higher than internal departmental rules; privacy protection and sensitive field constraints have a higher priority than general business convenience constraints; cross-departmental urgent business task constraints have a higher priority than daily non-urgent tasks; and security risk control rules have a higher priority than access efficiency rules.

[0097] During the optimization process, the system first attaches constraint labels to each node and edge in the candidate data subgraph. These labels include the source of the constraint (law, policy, departmental rule), the strength of the constraint (mandatory, recommended, optional), and the sensitivity level. Subsequently, the system uses a multi-level priority ranking algorithm to globally sort the constraint labels, such as using the weighted analytic hierarchy process (AHP) or a weighted directed graph topology sorting algorithm, to obtain the priority order of each constraint.

[0098] In the candidate data subgraph, when there are constraint conflicts, such as a task requirement that requires access to field A, while compliance constraints require that field A is prohibited from being shared, the system adopts the following optimization strategy: If the conflicting constraints belong to different levels, the constraint with higher priority is retained, and the constraint node or edge with lower priority is deleted or hidden; if the conflicting constraints are at the same level but have different priority weights, the optimal solution is retained according to the weight value; if the conflicting constraints are completely opposed and have the same priority, a manual review or intelligent arbitration mechanism is triggered, and an alternative solution (such as desensitization or partial field sharing) is recommended by manual approval or intelligent agent.

[0099] After optimization, the system performs pruning and reconstruction operations on the candidate data subgraph: deleting nodes and edges that do not meet the constraints, retaining valid data paths, and generating a structured, minimal-scale data subgraph that can still support the target task through graph rewriting technology. The result of this pruning and reconstruction is the minimum necessary data view, characterized by containing only the minimum set of data required for the execution of the target task, and all data accesses satisfying the requirements of constraint priority rules.

[0100] After obtaining the minimum necessary data view, the system acquires the departmental role mapping relationship, which can be constructed using the organizational structure directory and role permission system. Subsequently, for each data field in the minimum necessary data view, its sensitivity level is determined. A sensitivity classification algorithm (such as a hybrid method based on rule labeling and risk models) is used to divide the fields into four levels: public, internal, sensitive, and highly sensitive. Based on the sensitivity level, the system automatically determines the field access permissions for each field using access control policy generation technology (a combination of RBAC / ABAC models). For example, highly sensitive data is only authorized to specific roles with legitimate approval permissions, while ordinary roles can only access low-sensitivity or de-identified data. Finally, combining the field access permissions with the departmental role mapping relationship, the corresponding authorization scope is generated to ensure strict adherence to the minimum necessary principle and security compliance requirements during cross-departmental collaborative data sharing.

[0101] In this solution, by constructing a relationship graph between tasks and compliance constraints and performing intelligent pruning and optimization, the minimum necessary data range can be accurately identified to avoid data redundancy. Combined with sensitivity classification and role-based permission mapping, dynamic permission control is achieved, which not only ensures data compliance but also improves access efficiency, ultimately forming a secure, controllable, and efficient data authorization system that adapts to business needs.

[0102] Based on the above technical solution, optionally, after conducting cross-departmental government data collaboration based on the minimum necessary data view and authorized scope, the method further includes:

[0103] Obtain cross-departmental data access records, and determine the access time, accessing user, and accessing department information based on the cross-departmental data access records;

[0104] Based on the minimum necessary data view, the access time, accessing user, and accessing department information are encrypted and logged in an unalterable manner to obtain traceable access credentials.

[0105] In this solution, cross-departmental data access records refer to access behavior logs generated by the system during cross-departmental government data interaction. Specifically, this includes a complete record of interface call requests, data read requests, or data transmission operations. These records reflect the data interaction between different departments, covering information such as the initiator, target, duration, request summary, and processing result. Cross-departmental data access records serve as the foundational data source for generating access credentials, ensuring the completeness and accuracy of subsequent traceability.

[0106] Access time can refer to the specific point in time or time interval in which cross-departmental data access occurs, including the timestamp of the request initiation, the response return time, and the processing completion time.

[0107] The user who can access the data can be a specific user entity that initiates the data request during the cross-departmental data access process. This can be a natural person, a legal representative, or an authorized system account.

[0108] Accessing department information can refer to the identifier of the administrative agency or business department to which the user belongs, used to characterize the organizational relationship for cross-departmental data interaction.

[0109] Traceable access credentials refer to access credentials generated based on cross-departmental data access records, combined with access time, accessing user, and accessing department information, and processed through encryption and tamper-proof log processing. These credentials are unique, complete, and non-repudiable, enabling verification and traceability of access behavior afterward, ensuring the compliance and security of cross-departmental data access.

[0110] First, cross-departmental data access records are obtained. These records consist of network request logs and application call logs generated during cross-departmental data interaction. A unified log collection mechanism is typically used for collection, such as real-time capture of interface call data based on a distributed log collection protocol (e.g., Fluentd or Apache Kafka log collection framework), and storage of this data in a distributed log database. These cross-departmental data access records contain original access request information, including the caller identifier, target data identifier, request initiation time, and response status.

[0111] Subsequently, the system parses the cross-departmental data access records, extracting access time, accessing user, and accessing department information. Access time can be obtained by reading the timestamp field from the logs and converting it to a standard time format (such as ISO8601 time format); accessing user information can be obtained by parsing user tokens or digital certificate identifiers generated by the identity authentication system; and accessing department information is matched against a pre-set user-department mapping table, thereby binding the accessing entity to the department it belongs to.

[0112] After extracting the aforementioned information, the system performs security processing on the access time, accessing user, and accessing department information based on the minimum necessary data view. Specifically, firstly, a symmetric encryption algorithm (such as AES-256) is used to encrypt the information to ensure confidentiality during transmission and storage. Simultaneously, to ensure subsequent non-repudiation, the system further employs asymmetric encryption technology (such as RSA or the Chinese national standard SM2) to generate a digital signature on the encryption result, thereby preventing the accessing entity from denying its access behavior.

[0113] At the log recording level, to ensure tamper-proof log recording, the system writes encrypted and signed access data into a blockchain-style log storage structure, such as a chained hash storage method built on MerkleTree. Specifically, each record generates a unique hash value and links it to the hash value of the previous record, thus forming a chain structure; if any record is tampered with, all subsequent hash value verifications will fail, enabling immediate detection of tampering. Furthermore, the system can also employ a WORM (WriteOnceReadMany) storage medium to guarantee the physical immutability of the logs.

[0114] Finally, based on the encrypted and tamper-proof log processing results, the system generates a traceable access credential. This credential consists of encrypted access information, a digital signature, and a blockchain-style log index. It enables the confirmation and traceability of access behavior through decryption and signature verification operations afterward, thereby achieving security auditing and accountability throughout the entire process of cross-departmental data access.

[0115] This solution ensures the confidentiality and authenticity of accessed information through encryption and digital signatures, preventing unauthorized access and data leakage; and achieves complete tracking and auditing of access behavior through tamper-proof log recording and blockchain-based storage, thereby providing high reliability, security and compliance guarantees for cross-departmental government data collaboration.

[0116] Figure 2 This is a flowchart illustrating a dynamic knowledge graph-driven cross-departmental government data collaboration method provided in an embodiment of this disclosure. The method may include the following steps:

[0117] S201, acquire cross-departmental government affairs data and corresponding policy rule data, construct a data knowledge graph based on the cross-departmental government affairs data, and construct a strategy knowledge graph based on the policy rule data.

[0118] S202, obtain preset event information, and perform incremental update and consistency check on the data knowledge graph and the strategy knowledge graph according to the preset event information to obtain the updated data knowledge graph and the updated strategy knowledge graph.

[0119] S203, extract the latest business status from the updated data knowledge graph, and extract the latest policy rules from the updated strategy knowledge graph.

[0120] S204. Based on the latest business status and the latest policy rules, perform joint reasoning to obtain the minimum necessary data view and the scope of authorization, and conduct cross-departmental government data collaboration based on the minimum necessary data view and the scope of authorization.

[0121] S205, obtain the interface status information of each interface, determine the interface response time and availability data of each interface based on the interface status information, calculate the average response time and analyze the number of failures based on the interface response time and availability data, and obtain the interface delay weight table.

[0122] An interface can refer to a unified access point for data exchange and invocation between different business systems, application services, or databases in a cross-departmental government data collaboration system. It typically includes request parameter definitions, invocation protocols (such as HTTP, gRPC, RESTful API), and return data formats, and is used to realize cross-system data interaction and business linkage.

[0123] Interface status information refers to the operational status information of the interface during real-time monitoring or periodic collection, including the number of interface call requests, the number of successful returns, the number of failed returns, the number of timeouts, the distribution of exception codes, the current load level, and timestamps, which are used to reflect the interface's performance within a certain period of time.

[0124] Interface response time refers to the time interval from when the client sends a request to the interface to when the interface returns a result. It is usually measured in milliseconds (ms) and is used to measure the efficiency of the interface in processing requests.

[0125] Availability data refers to the proportion of time during which an interface remains operational and correctly returns business results within a monitoring period. It is usually expressed as a percentage and is a key indicator for measuring the reliability and stability of an interface.

[0126] Average response time calculation can refer to the weighted or arithmetic average of response time data from multiple interface calls within a monitoring time window to obtain the overall response latency level of the interface.

[0127] Fault frequency analysis refers to the statistical analysis of the number of times an interface experiences timeouts, abnormal return codes, or unreachability within the same monitoring window, which is used to characterize the interface's stability performance.

[0128] An interface latency weight table refers to a weight mapping table that is formed by comprehensively calculating the latency weight of each interface in the data access scheduling process based on the average response time and failure count analysis results of each interface, combined with the set latency evaluation index system.

[0129] First, the system acquires the interface status information for each interface, including the timestamp of the interface call, return status code, request response time, error type, and number of request failures. Based on this interface status information, the system determines the interface response time and availability data for each interface. Interface response time refers to the average time taken for an interface to complete a request response within a unit time window, while availability data refers to the success rate or failure rate of the interface in responding to requests normally within that time window. Subsequently, the system calculates the average response time by taking the arithmetic mean of the interface response times over multiple time windows to obtain the overall interface response performance index. Simultaneously, the system performs a failure count analysis on the availability data, counting the number of request failures, the frequency of abnormal error codes, and the duration of interface unavailability within a preset time period. The system then comprehensively evaluates the calculated average response time, failure count, and interface availability data. Specifically, the system first normalizes the average response time of each interface to map its value to a unified performance quantification scale, and standardizes the failure count to eliminate the impact of differences in the frequency of different interface calls on the evaluation results. Subsequently, the normalized average response time, standardized number of failures, and interface availability data are weighted and combined according to preset weight coefficients. The weight coefficient for availability data is typically higher than that for failure counts and response time, prioritizing the reflection of interface stability. The system categorizes interfaces into different latency weight levels based on their overall scores. For example, interfaces can be divided into five levels: high, relatively high, medium, relatively low, and low. The boundary values ​​for these levels are determined by historical performance statistics and business response requirements. Interfaces with high overall scores, short response times, and high availability are assigned a lower latency weight level, prioritizing their data access. Interfaces with low overall scores, slow responses, or frequent failures are assigned a higher latency weight level, thus reducing their access priority in subsequent cross-departmental data calls. Finally, the system records each interface and its corresponding latency weight level in a complete interface latency weight table, which associates each interface with its corresponding latency weight level.

[0130] S206, obtain the access task priority and historical access frequency data of each department, and perform weighted combination sorting on the access task priority and historical access frequency data to obtain a preliminary task access list.

[0131] Access task priority can refer to the urgency or importance of tasks assigned by various departments during cross-departmental government data access, and is used to reflect the priority order of different tasks during scheduling.

[0132] Historical access frequency data refers to the statistical information on the number of times each department accesses cross-departmental interfaces or data resources within a certain time window in the past. It is used to measure the activity level and dependence of departments on specific interfaces or data calls.

[0133] The preliminary task access list refers to the sorted set of data access tasks for each department, generated after weighting and sorting the access tasks based on their priority and historical access frequency data. This list reflects the initial execution order of tasks in each department during cross-departmental data collaboration, providing a basic reference for subsequent optimization of sorting and access scheduling.

[0134] The system first obtains the access task priority and historical access frequency data for each department. The access task priority includes the importance level and urgency information of each department's tasks, which is used to reflect the processing priority of tasks in cross-departmental data access; the historical access frequency data records the number of times each task has been accessed and the access pattern in the past time period, which is used to reflect the actual access needs of the tasks.

[0135] After obtaining the above data, the system standardizes the priority of access tasks, unifying the priority indicators of different departments and tasks to the same evaluation scale to eliminate differences in units and data ranges; at the same time, it normalizes the historical access frequency data to ensure that tasks with more access frequency will not have unreasonable ranking biases due to differences in quantity.

[0136] After standardization and normalization, the system performs a comprehensive evaluation of each department's tasks to determine their priority in cross-departmental data access. The specific steps are as follows:

[0137] The system first assigns two independent evaluation metrics to each task: one based on standardized task priority, reflecting the task's importance and urgency; and the other based on normalized historical access frequency data, reflecting the task's activity level in past accesses. Then, the system comprehensively considers these two metrics according to a preset optimization strategy: tasks belonging to critical business or high-importance levels are given higher weights to ensure core tasks receive priority access to data resources; tasks with high historical access frequency are given additional weights to ensure frequently accessed tasks are not delayed due to low priority; by adjusting the ratio of core task weight to access frequency weight, a balance between importance and access demand is achieved, allowing tasks that are both important and active to receive the highest comprehensive score; during the evaluation process, the comprehensive score of each task can be fine-tuned appropriately based on departmental resource capacity, network load, and current task backlog to ensure the system can still schedule tasks reasonably under high load. After completing the comprehensive evaluation, the system sorts the tasks from highest to lowest comprehensive score, generating a preliminary task access list.

[0138] S207, Obtain the department priority of each department, and generate an optimized task access list based on the department priority and the preliminary task access list.

[0139] Departmental priority refers to the access priority level that each department has in cross-departmental government data collaboration, which is used to reflect the importance, urgency or resource allocation priority of the department in the overall business process.

[0140] An optimized task access list refers to a task scheduling order list obtained by readjusting the task order based on the initial task access list and considering the departmental priorities of each department. The optimized task access list comprehensively considers the importance of tasks, historical access frequency, and the priority of their respective departments, aiming to achieve efficiency, rationality, and fairness in cross-departmental data access, and providing foundational data for determining subsequent interface access frequencies and batch transmission strategies.

[0141] Obtaining departmental priorities first involves quantitatively assessing the importance of each department's access to cross-departmental government data collaboration and its resource allocation needs. Based on each department's business functions, historical access records, task urgency, and policy regulations, the system uses the Analytic Hierarchy Process (AHP), weighted scoring, or multi-dimensional ranking techniques to determine departmental priorities in numerical or hierarchical form, generating a departmental priority dataset. During this process, for each department, the system statistically analyzes its completion efficiency, request frequency, and proportion of critical tasks in historical task access, and standardizes these indicators to eliminate the impact of differences in metrics on the overall assessment.

[0142] Subsequently, the system performs an optimization sorting operation based on the department priorities and the preliminary task access list. Specifically, for each task item in the preliminary task access list, the system first associates it with the department priority data of its respective department, and then uses a sorting and weighted merging strategy to place task items with higher department priorities at the front, while also considering the original order of tasks in the preliminary list and historical access frequency, to ensure that both department weights and task execution urgency and frequency patterns are respected. The optimization sorting process can be implemented using priority queues, tree structures, or graph sorting algorithms to ensure that the task order can be dynamically adjusted and the weight evaluation updated in real time during list generation. The final optimized task access list ensures cross-departmental access efficiency and fairness, while providing data basis for subsequent interface access frequency determination and batch transmission strategies.

[0143] S208: Obtain current network load information; based on the current network load information, interface latency weight table, and optimization task access list, determine the data access frequency and batch transmission strategy for each interface; and control the data access order and access frequency of each interface based on the data access frequency and batch transmission strategy for each interface.

[0144] Current network load information refers to the real-time status information of the network environment of each interface during cross-departmental government data collaboration, including parameters such as network bandwidth utilization, packet queue length, latency fluctuation and throughput, which are used to reflect the tension and availability of network resources.

[0145] Data access frequency can refer to the number of interface requests or access cycles per unit time set by the system for each interface under specific network load conditions and departmental task priorities.

[0146] Batch transmission strategy can refer to the size of the data block to be processed at one time and the transmission method set for each interface, including the data packaging method, sending interval and transmission order.

[0147] Data access order can refer to the order in which each interface performs access operations according to the optimized task access list and access strategy during cross-departmental data access.

[0148] Access frequency refers to the number of times an interface is accessed per unit of time during actual execution, reflecting the call rhythm and access intensity of the interface.

[0149] Based on the latency levels defined in the interface latency weight table, the system initially groups all interfaces according to their response speed and stability. For interfaces with lower latency weights (i.e., fast response speed and high stability), the system reserves a higher allocable access frequency space for them; for interfaces with higher latency weights, the upper limit of their access frequency is reduced to avoid dragging down the overall task execution efficiency.

[0150] Secondly, the system optimizes the task order in the task access list, increasing the access frequency of interfaces called by high-priority tasks within their respective latency groups. For example, if a task is high in the optimized task access list and its associated interface belongs to the medium latency group, the access frequency of that interface will be prioritized and increased to near the level of high-priority interfaces within the group. The system implements this process using a priority queue scheduling algorithm, dynamically calculating the combined value of task priority weight and interface latency weight during scheduling to obtain the target access frequency range for each interface.

[0151] Next, the system dynamically adjusts the target access frequency based on current network load information. Specifically, when low network bandwidth utilization and unobstructed links are detected, the system allows the interface access frequency to be increased within the target range; conversely, when network load approaches saturation, the system automatically reduces the interface access frequency to prevent link congestion. This dynamic adjustment process is achieved through sliding time window statistics and exponential weighted adjustment techniques, ensuring that frequency allocation matches the real-time network status. Thus, the data access frequency for each interface is ultimately determined.

[0152] To determine the batch transmission strategy, the system first refers to the delay grouping information in the interface delay weight table, allocating larger single-transmission data blocks for low-latency interfaces to reduce the additional overhead caused by frequent requests; for high-latency interfaces, smaller data blocks are allocated to reduce losses caused by transmission failures or retransmissions. Subsequently, the system adaptively adjusts the data block size based on the bandwidth margin in the current network load information: when bandwidth is idle, the single transmission block size is increased to improve throughput efficiency; when the risk of congestion intensifies, the system automatically reduces the block size and increases the number of batches to alleviate network pressure.

[0153] Finally, the system combines the execution order and priority of tasks in the optimized task access list to customize the batch transmission method. For interfaces corresponding to high-priority tasks, the system prioritizes more reliable TCP parameter tuning strategies (such as window expansion and rate adaptive control) to ensure stable transmission of critical data; for low-priority but large-volume task interfaces, it tends to use a high-throughput UDP batch sending strategy to reduce overall latency. Thus, based on current network load information, the interface latency weight table, and the optimized task access list, the system ultimately determines the data access frequency and batch transmission strategy for each interface.

[0154] The system uses data access frequency as a rate constraint and employs a dynamic rate limiting mechanism to control interface access. During execution, the scheduler monitors the actual number of interface calls in real time and compares it to the target frequency. When the number of accesses to an interface approaches or exceeds the target value, the system automatically postpones subsequent calls to that interface, thereby avoiding network congestion or interface blocking due to excessive access.

[0155] Secondly, the system uses batch transmission strategy as the basis for scheduling transmission scale. For interfaces allocated larger transmission blocks, the scheduler prioritizes reserving a longer transmission time window in the access order to ensure that a single batch of data can be transmitted completely; for interfaces using small block transmission strategy, the scheduler allows them to be frequently interleaved in multiple transmission cycles, thereby improving transmission flexibility and overall link utilization.

[0156] The order of data access is determined by both the frequency of the interface and the batch requirements. During scheduling, the system determines the call interval based on the target access frequency of the interface, and adjusts the order of calls in conjunction with the batch transmission strategy. For example, interfaces with high frequency but small batch size will be evenly distributed across multiple time slots; interfaces with low frequency but large batch size will be scheduled for concentrated execution during periods of low network load.

[0157] In this embodiment, by integrating dynamic data on interface performance, departmental task priorities, and network load, a latency weight table and an optimized access list are intelligently generated. This accurately balances resource allocation and network load, prioritizes access to high-priority tasks, and achieves dynamic adaptation of data access frequency and transmission strategies, ultimately improving system response efficiency and stability.

[0158] Based on the above technical solution, optionally, based on the current network load information, interface latency weight table, and optimized task access list, the data access frequency and batch transmission strategy for each interface are determined, including:

[0159] Obtain the bandwidth utilization and queue length data from the current network load information, normalize the bandwidth utilization, queue length data, interface response time and availability data, and calculate the load adaptability score of each interface based on the normalized bandwidth utilization, queue length data, interface response time, availability data and the preset load adaptability score calculation formula.

[0160] Based on the load adaptability score of each interface, each interface is divided into the corresponding access frequency range to obtain the access frequency level of each interface.

[0161] Based on the access frequency level and the task priority in the optimized task access list, the task access order of each interface is adjusted by weighting to obtain the target task access order.

[0162] Based on the bandwidth utilization rate, queue length data, and delay weight values ​​in the interface delay weight table, determine the batch transmission parameters for each interface;

[0163] Based on the access frequency level and batch transmission parameters, the data access frequency and batch transmission strategy for each interface are determined.

[0164] In this scheme, bandwidth utilization rate refers to the ratio between the actual usage of network bandwidth and the total available bandwidth, reflecting the real-time occupancy of network resources. A higher bandwidth utilization rate indicates that less bandwidth is available for transmitting new tasks, and the system needs to implement flow limiting or batch transmission measures during scheduling.

[0165] Queue length data can refer to the number of data packets waiting to be transmitted or processed in network devices (such as switches, routers, or interface buffers).

[0166] Load adaptability score refers to the interface performance adaptability index generated by the system based on a preset scoring formula, after comprehensively considering factors such as bandwidth utilization, queue length data, interface response time, and availability data. This score reflects the stability and schedulability of the interface under the current network load conditions, providing a basis for subsequent access frequency allocation and transmission strategy generation.

[0167] Access frequency ranges can refer to multiple access frequency ranges divided by the system based on load adaptability scores, with each range corresponding to a different data access rate. For example, high-frequency ranges correspond to frequent calls, medium-frequency ranges correspond to moderate calls, and low-frequency ranges correspond to sparse calls.

[0168] Access frequency level refers to the specific access range level into which an interface is classified based on its load adaptability score. It is usually divided into high frequency, medium frequency and low frequency levels, representing the access frequency of the interface per unit time.

[0169] Task priority refers to the importance level of a task within the overall data collaboration, as determined by the optimized task access list. Task priorities are set based on factors such as departmental urgency, business sensitivity, and historical access frequency, and are used to guide the task scheduling order.

[0170] Task access order refers to the initial execution order generated by the system during cross-departmental data access, based on task priority and related scheduling strategies, reflecting the sequential relationship of different tasks in the time dimension.

[0171] The target task access order can refer to the final task access execution order generated after adjusting the access frequency level and task priority weight.

[0172] The latency weight value refers to the interface performance metric recorded in the interface latency weight table, which reflects the overall performance of the interface in terms of response time and stability.

[0173] Batch transmission parameters refer to the parameters related to batch data transmission set by the system for the interface, including the size of a single transmission block, the number of batches, and the transmission method.

[0174] First, the system acquires current network load information, including bandwidth utilization and queue length data. Bandwidth utilization can be obtained using real-time traffic acquisition techniques at the network link layer, such as SNMP or sFlow traffic sampling technology, to extract current bandwidth usage from routers and switches, and then calculate the ratio by combining this with the maximum available bandwidth of the link. Queue length data can be obtained in real time through queue monitoring commands or device port buffer statistics, reflecting the number of data packets currently waiting to be transmitted. Subsequently, the system normalizes the acquired bandwidth utilization, queue length, interface response time, and availability data. Normalization can employ min-max scaling or Z-score standardization methods to convert data of different dimensions into a unified numerical range for subsequent comprehensive calculations.

[0175] After normalization, the system evaluates each interface based on a preset load adaptability score calculation formula. Specifically, the score calculation combines normalized bandwidth utilization, queue length data, interface response time, and availability data, and calculates a comprehensive score according to predefined weight ratios to obtain the load adaptability score for each interface. This score reflects the interface's adaptability and scheduling priority under the current network conditions. Based on the load adaptability score, the system divides each interface into different access frequency ranges and generates corresponding access frequency levels for each interface. For example, interfaces with high scores are classified as high-frequency levels, and interfaces with low scores are classified as low-frequency levels, thereby determining the call rate range of each interface per unit time.

[0176] Next, the system combines the access frequency levels mentioned above with the task priorities in the optimized task access list to perform a weighted adjustment of the task access order for each interface. Specifically, the system uses a priority queue scheduling algorithm, assigning higher access weights to interfaces corresponding to high-priority tasks during the scheduling process, while also considering the access frequency levels of the interfaces to avoid excessive calls to low-adaptability interfaces under high load conditions, thereby generating a comprehensive and balanced target task access order.

[0177] After determining the access order, the system further determines the batch transmission parameters for each interface based on bandwidth utilization, queue length data, and latency weight values ​​in the interface latency weight table. The batch transmission parameter setting process employs an adaptive chunking transmission method. When low bandwidth utilization and short queue lengths are detected, the system appropriately increases the size of data blocks transmitted in a single batch to improve overall throughput efficiency. Conversely, when network congestion risk increases and queue lengths are long, the system automatically reduces the size of data blocks transmitted in a single batch and increases the number of transmission batches to reduce congestion risk. The latency weight value serves as an adjustment factor, ensuring that high-latency interfaces adopt a more conservative chunking strategy, while low-latency interfaces can handle larger data block transmissions.

[0178] The system determines the range of API call counts per unit time based on access frequency levels. For example, for high-level APIs, the system allocates call counts to a higher range to ensure critical tasks can be completed in a shorter time; for low-level APIs, they are allocated to a lower range to reduce resource consumption. This allocation process can employ a dynamic rate limiting mechanism, which monitors the cumulative number of API calls. When the threshold set for that level is reached, the system delays or queues subsequent requests, thereby achieving frequency control.

[0179] Subsequently, the system determines the data transmission method for a single access by combining the batch transmission parameters corresponding to each interface. Specifically, this includes dynamically setting the data block size based on bandwidth utilization and queue length data, and further adjusting it according to the interface's latency weight value. For example, when the interface is at a high access frequency level but the latency weight value is large, the system will reduce the transmission size of a single data block and increase the number of transmission batches to balance latency and throughput; while when the interface is at a high access frequency level and the latency weight value is small, and the network condition is good, the system will increase the data block transmission size, thereby improving the overall bandwidth utilization.

[0180] Ultimately, the system combines the call rate determined by the access frequency level with the data block size and number of transmission batches defined by the batch transmission parameters to obtain the data access frequency and batch transmission strategy for each interface. This strategy not only clarifies the call rhythm of the interface within a unit of time but also specifies the data transmission method in a single call, ensuring that interface scheduling can be dynamically optimized based on the current network status and interface characteristics, thereby reducing latency and improving the overall system throughput efficiency.

[0181] This solution integrates network load (bandwidth utilization, queue length) and interface performance (response time, availability) data to dynamically calculate interface load adaptability and classify access frequency levels. It adjusts the access order based on task priority and determines batch transmission parameters to achieve precise dynamic adaptation of data access strategies, prioritize the execution of critical tasks, optimize resource allocation, and improve system efficiency and stability.

[0182] Based on the above technical solution, the optional, preset formula for calculating the load adaptability score is as follows:

[0183]

[0184] in, Score the load adaptability. This represents the bandwidth utilization rate after normalization. This is the queue length data after normalization. This is the interface response time after normalization. This is the normalized availability data; The preset bandwidth factor weights; The preset queue factor weights; The preset response time factor weights; These are the preset availability factor weights.

[0185] In this plan, This refers to the pre-set weighting coefficients for different metrics (bandwidth utilization, queue length, interface response time, availability data) during the calculation of load adaptability scores. These coefficients are determined through performance testing and simulation evaluation before system deployment and can be set by expert experience or data-driven methods. For example, when the system goal is to reduce latency, the weight of interface response time corresponding to γ ​​can be increased; when the goal is to improve stability, the weight of availability corresponding to δ can be increased. This pre-setting method is usually calibrated based on multi-objective optimization experiments (such as weighted scoring methods and AHP analysis hierarchy methods) to ensure that the final score can objectively reflect the actual adaptability of the interface under complex loads.

[0186] This indicates the availability of remaining bandwidth resources. When Close to 0 (low occupancy rate) A value close to 1 indicates that the interface has good availability; when Approaching 1 (high occupancy rate). A value close to 0 indicates that the interface has almost no available bandwidth.

[0187] For the correction of the queue length item, when Smaller A value close to 1 indicates low processing pressure on the interface; when Larger A value close to 0 indicates severe interface queuing and decreased adaptability.

[0188] To correct for the response time term, an exponential decay form is used, meaning that the longer the response time, the faster the fitness score decays. When Close to 0 (fast response) Approaching 1; when Increase (slow response), e Approaching 0. This design highlights the advantages of the "fast interface" and suppresses the weight of the "slow interface".

[0189] Normalization refers to mapping raw metrics such as bandwidth utilization, queue length, interface response time, and availability data to a unified range (e.g., [0,1]). Its benefits include: eliminating dimensional differences: Bandwidth (Mbps), queue length (number of queues), and response time (milliseconds) have different dimensions, and direct comparisons can lead to bias. Ensuring fairness: After normalization, all metrics are calculated in combination within the same order of magnitude, preventing any single metric from dominating the score due to an excessively large numerical range. Improving sensitivity: Small changes after normalization are reflected in the score, allowing the system to promptly reflect load fluctuations.

[0190] Figure 3This is a schematic block diagram of a dynamic knowledge graph-driven cross-departmental government data collaboration system provided in an embodiment of this disclosure. The system is characterized by comprising:

[0191] The graph construction module 301 is used to acquire cross-departmental government business data and corresponding policy rule data, construct a data knowledge graph based on the cross-departmental government business data, and construct a strategy knowledge graph based on the policy rule data.

[0192] The dynamic update module 302 is used to obtain preset event information, and perform incremental updates and consistency checks on the data knowledge graph and the strategy knowledge graph according to the preset event information to obtain the updated data knowledge graph and the updated strategy knowledge graph.

[0193] Extraction module 303 is used to extract the latest business status from the updated data knowledge graph and the latest policy rules from the updated strategy knowledge graph.

[0194] The cross-departmental collaboration module 304 is used to perform joint reasoning based on the latest business status and the latest policy rules to obtain the minimum necessary data view and the scope of authorization, and to carry out cross-departmental government data collaboration based on the minimum necessary data view and the scope of authorization.

[0195] Figure 4 An electronic device 400 provided in this application embodiment is shown, including a processor 401, a memory 402, and a program or instructions stored in the memory 402 and executable on the processor 401. When the program or instructions are executed by the processor 401, they implement the various processes of the above-described embodiment of the dynamic knowledge graph-driven cross-departmental government data collaboration method and achieve the same technical effect. To avoid repetition, they will not be described again here.

[0196] It should be noted that the electronic devices in the embodiments of this application include the mobile electronic devices and non-mobile electronic devices described above.

[0197] This application provides a readable storage medium storing a program or instructions. When the program or instructions are executed by a processor, they implement the various processes of the above-described dynamic knowledge graph-driven cross-departmental government data collaboration system embodiment and achieve the same technical effect. To avoid repetition, further details are omitted here.

[0198] The processor is the processor in the electronic device described in the above embodiments. The readable storage medium includes computer-readable storage media, such as computer read-only memory (ROM), random access memory (RAM), magnetic disk, or optical disk.

[0199] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or system that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or system. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or system that includes that element. Furthermore, it should be noted that the scope of the methods and systems in the embodiments of this application is not limited to performing functions in the order shown or discussed, but may also include performing functions substantially simultaneously or in the reverse order, depending on the functions involved. For example, the described methods may be performed in a different order than described, and various steps may be added, omitted, or combined. Additionally, features described with reference to certain examples may be combined in other examples.

[0200] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a computer software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) and includes several instructions to cause a terminal (which may be a mobile phone, computer, server, or network device, etc.) to execute the methods described in the various embodiments of this application.

[0201] The embodiments of this application have been described above with reference to the accompanying drawings. However, this application is not limited to the specific embodiments described above. The specific embodiments described above are merely illustrative and not restrictive. Those skilled in the art can make many other forms under the guidance of this application without departing from the spirit and scope of the claims, and all of these forms are within the protection scope of this application.

[0202] The above description is merely a preferred embodiment and the technical principles employed in this application. This application is not limited to the specific embodiments described herein, and various obvious changes, readjustments, and substitutions that can be made by those skilled in the art will not depart from the scope of protection of this application. Therefore, although this application has been described in detail through the above embodiments, this application is not limited to the above embodiments, and may include more other equivalent embodiments without departing from the concept of this application, the scope of which is determined by the scope of the claims.

Claims

1. A dynamic knowledge graph-driven method for cross-departmental government data collaboration, characterized in that, The method includes: Acquire cross-departmental government affairs data and corresponding policy and rule data; construct a data knowledge graph based on the cross-departmental government affairs data; and construct a strategy knowledge graph based on the policy and rule data. Obtain preset event information, and perform incremental updates and consistency checks on the data knowledge graph and the strategy knowledge graph based on the preset event information to obtain the updated data knowledge graph and the updated strategy knowledge graph. Extract the latest business status from the updated data knowledge graph, and extract the latest policy rules from the updated strategy knowledge graph; Based on the latest business status and the latest policy rules, joint reasoning is performed to obtain the minimum necessary data view and the scope of authorization. Based on the minimum necessary data view and the scope of authorization, cross-departmental government data collaboration is carried out. This includes obtaining the target task, generating a task subgraph related to the target task in the updated data knowledge graph, and generating a compliance constraint subgraph related to the target task in the updated policy knowledge graph. Perform intersection pruning on the task subgraph and the compliance constraint subgraph to obtain the candidate data subgraph; The candidate data subgraph is optimized based on preset constraint priority rules to generate the minimum necessary data view; Obtain the department role mapping relationship, determine the field access permissions based on the data sensitivity level in the minimum necessary data view, and determine the authorization scope based on the field access permissions and the department role mapping relationship.

2. The method according to claim 1, characterized in that, in, After obtaining the updated data knowledge graph and the updated policy knowledge graph, the method further includes: If the updated data knowledge graph and the updated strategy knowledge graph do not conform to the preset consistency rules, perform graph structure analysis on the updated data knowledge graph to obtain isolated node data and circular dependency data. Logical constraint analysis is performed on the updated strategy knowledge graph to obtain cross-graph conflict relationship data; Perform node reconstruction processing on the isolated node data to obtain reconstructed node data; Perform edge redirection processing on the circular dependency data to obtain redirected edge data; Redundant data removal is performed on the cross-graph conflict relationship data to obtain simplified data; Based on the reconstructed node data, redirected edge data, and simplified data, the updated data knowledge graph and strategy knowledge graph are repaired to obtain the repaired updated data knowledge graph and strategy knowledge graph. Accordingly, the latest business status is extracted from the updated data knowledge graph, and the latest policy rules are extracted from the updated strategy knowledge graph, including: Extract the latest business status from the repaired and updated data knowledge graph, and extract the latest policy rules from the repaired and updated strategy knowledge graph.

3. The method according to claim 1, characterized in that, in, After conducting cross-departmental government data collaboration based on the minimum necessary data view and authorized scope, the method further includes: Obtain the interface status information of each interface, determine the interface response time and availability data of each interface based on the interface status information, calculate the average response time and analyze the number of failures based on the interface response time and availability data, and obtain the interface latency weight table. Obtain the access task priority and historical access frequency data of each department, and sort the access task priority and historical access frequency data by weighted combination to obtain a preliminary task access list. Obtain the department priority of each department, and generate an optimized task access list based on the department priority and the preliminary task access list; Obtain current network load information. Based on the current network load information, the interface latency weight table, and the optimization task access list, determine the data access frequency and batch transmission strategy for each interface. Control the data access order and access frequency of each interface based on the data access frequency and batch transmission strategy for each interface.

4. The method according to claim 3, characterized in that, in, Based on the current network load information, interface latency weight table, and optimization task access list, determine the data access frequency and batch transmission strategy for each interface, including: Obtain the bandwidth utilization and queue length data from the current network load information, normalize the bandwidth utilization, queue length data, interface response time and availability data, and calculate the load adaptability score of each interface based on the normalized bandwidth utilization, queue length data, interface response time, availability data and the preset load adaptability score calculation formula. Based on the load adaptability score of each interface, each interface is divided into the corresponding access frequency range to obtain the access frequency level of each interface. Based on the access frequency level and the task priority in the optimized task access list, the task access order of each interface is adjusted by weighting to obtain the target task access order. Based on the bandwidth utilization rate, queue length data, and delay weight values ​​in the interface delay weight table, determine the batch transmission parameters for each interface; Based on the access frequency level and batch transmission parameters, the data access frequency and batch transmission strategy for each interface are determined.

5. The method according to claim 4, characterized in that, in, The preset formula for calculating the load adaptability score is: ,in, Score the load adaptability. This represents the bandwidth utilization rate after normalization. This is the queue length data after normalization. This is the interface response time after normalization. This is the normalized availability data; The preset bandwidth factor weights; The preset queue factor weights; The preset response time factor weights; These are the preset availability factor weights.

6. The method according to claim 1, characterized in that, in, After conducting cross-departmental government data collaboration based on the minimum necessary data view and authorized scope, the method further includes: Obtain cross-departmental data access records, and determine the access time, accessing user, and accessing department information based on the cross-departmental data access records; Based on the minimum necessary data view, the access time, accessing user, and accessing department information are encrypted and logged in an unalterable manner to obtain traceable access credentials.

7. A dynamic knowledge graph-driven cross-departmental government data collaboration system, characterized in that, The system includes: The graph construction module is used to acquire cross-departmental government business data and corresponding policy rule data, construct a data knowledge graph based on the cross-departmental government business data, and construct a strategy knowledge graph based on the policy rule data. The dynamic update module is used to acquire preset event information, and perform incremental updates and consistency checks on the data knowledge graph and the strategy knowledge graph based on the preset event information to obtain the updated data knowledge graph and the updated strategy knowledge graph. The extraction module is used to extract the latest business status from the updated data knowledge graph and the latest policy rules from the updated strategy knowledge graph. The cross-departmental collaboration module is used to perform joint reasoning based on the latest business status and the latest policy rules to obtain the minimum necessary data view and authorization scope, and to conduct cross-departmental government data collaboration based on the minimum necessary data view and authorization scope; wherein, it includes obtaining the target task, generating a task subgraph related to the target task in the updated data knowledge graph, and generating a compliance constraint subgraph related to the target task in the updated strategy knowledge graph; Perform intersection pruning on the task subgraph and the compliance constraint subgraph to obtain the candidate data subgraph; The candidate data subgraph is optimized based on preset constraint priority rules to generate the minimum necessary data view; Obtain the department role mapping relationship, determine the field access permissions based on the data sensitivity level in the minimum necessary data view, and determine the authorization scope based on the field access permissions and the department role mapping relationship.

8. An electronic device, characterized in that, It includes a processor, a memory, and a program or instructions stored in the memory and executable on the processor, wherein the program or instructions, when executed by the processor, implement the steps of the dynamic knowledge graph-driven cross-departmental government data collaboration method as described in any one of claims 1-6.

9. A readable storage medium, characterized in that, The program or instructions are stored on the readable storage medium, and when the program or instructions are executed by a processor, they implement the steps of the dynamic knowledge graph-driven cross-departmental government data collaboration method as described in any one of claims 1-6.

Images