Method and system for maintaining consistency of cross-version knowledge graph based on ontology semantic difference driving

Abstract

The application discloses a cross-version knowledge graph consistency maintenance method and system based on ontology semantic differential driving, and belongs to the technical field of knowledge graph and semantic Web. The method takes a change transaction graph (CTG) as a core data structure, identifies 12 types of ontology atomic operations through two-stage calculation of syntax difference and semantic inference, constructs a change transaction graph containing a dependent directed acyclic graph and an executable compensation mapping, executes change operations and failure rollback in a deterministic topological order, adopts a multi-dimensional version identification system, realizes unique reconstruction of a merged version through a nearest common ancestor and complete merging of an increment, sets static and runtime two-level equivalence judgment standards, realizes provable SPARQL query rewriting, and guarantees data consistency in combination with closed world SHACL constraint checking. The application can effectively eliminate batch change execution errors, query rewriting silent errors and historical reconstruction uncertainty, and realizes cross-version strong consistency maintenance of ontology modes and instance data.

Description

Technical Field

[0001] This invention relates to the fields of knowledge graph and semantic web technologies, specifically to a method and system for dynamic updating of knowledge graphs and maintenance of cross-version consistency based on ontology semantic differential calculation, ordered execution of change transaction graphs, provable equivalent query rewriting, and multi-dimensional version routing. Background Technology

[0002] The core carriers of knowledge graphs are the Resource Description Framework (RDF) triples and the ontology schema defined by the Web Ontology Language (OWL). During business iterations, the ontology schema and instance data continuously evolve. Ensuring the correctness of change execution, the reproducibility of historical versions, and the consistency of cross-version queries are core issues in the fields of ontology evolution and knowledge graph version management.

[0003] The existing technology has three core flaws: 1. Lack of Dependency Control in Ontology Change Classification: Existing research classifies ontology changes into basic operations and composite operations, but only models individual operations without establishing cross-operation dependency representations. During batch changes, data corruption can easily occur due to incorrect execution order; for example, deleting a parent class before migrating a child class can create isolated instances. Furthermore, the instance allocation rules for composite operations such as class splitting lack standardization, making it impossible to automatically verify the coverage integrity and mutual exclusion of old instances after splitting.

[0004] 2. Insufficient determinism in RDF version management reconstruction: The storage overhead of the named graph snapshot method increases linearly with the number of versions and lacks a deterministic merge replay mechanism based on the Lowest Common Ancestor (LCA); the triple timestamp method cannot distinguish between version deletion and data expiration, and the timeline semantics are ambiguous in multi-branch scenarios; the reconstruction cost of the incremental differential chain method increases linearly with the chain length, and the association rules between the merge increment and the common ancestor are not defined, the reconstruction path of the merged version is not unique, and the result of historical state reproduction is uncertain.

[0005] 3. Lack of provable semantic equivalence in query rewriting: Existing SPARQL protocol and RDF query language (SPARQL) rewriting methods only support simple replacements such as class / attribute renaming, and cannot handle complex scenarios such as attribute splitting and aggregation, inference path queries, and constraint narrowing. More importantly, existing methods lack formal conditions for determining "provable semantic equivalence," posing a silent error risk—the syntax may be correct after rewriting, but the semantics may have changed, and downstream applications will not issue alerts. Some solutions equate migration strategy selection with equivalence proofs, leading to false equivalence claims. Summary of the Invention

[0006] This invention addresses the shortcomings of existing technologies by solving the following three core technical problems: 1. Execution correctness issues: In batch ontology changes, multiple operations have data dependencies. The lack of dependency representation and mandatory sequential execution mechanism can easily lead to data corruption or constraint violations if the execution order is incorrect.

[0007] 2. Query consistency issues: Query rewriting cannot determine whether the result is semantically equivalent to the original query, and downstream applications obtain semantically incorrect query results without alerts; migration strategy selection is confused with equivalence proof, resulting in false equivalence claims.

[0008] 3. Reproducibility issues in historical reconstruction: The merged version lacks unique playback rules, and the time positioning is not unique in multi-branch scenarios, resulting in uncertain historical state reconstruction results, which cannot meet the audit and backtracking requirements.

[0009] According to a first aspect of the present invention, a method for maintaining cross-version knowledge graph consistency based on ontology semantic difference is provided, comprising the following steps: S1. Input the old ontology and the new ontology, and perform syntactic difference and semantic inference in sequence to generate a set of difference results with semantic labels containing multiple types of atomic operations; S2. Construct a change transaction graph based on the differential result set. The change transaction graph includes a dependent directed acyclic graph, an executable compensation mapping, and a set of mutual exclusions. Perform deterministic topological sorting on the dependent directed acyclic graph to obtain an execution sequence. In the temporary storage environment, execute the mode change, data migration, query rewriting, and constraint verification nodes in sequence according to the execution sequence. If the execution fails, trigger the compensation operation in reverse order to block version submission. S3. Generate a version record for each committed version that includes a pattern hash, a data hash, a version routing hash, and an association with the parent version; for merged versions, calculate the nearest common ancestor and generate a complete merge increment from the nearest common ancestor to the merged version, ensuring that the reconstruction path of the merged version is unique; S4. Rewrite and adapt the registered SPARQL queries, and divide the query equivalence into two levels: static proof equivalence and runtime proof equivalence. Only when the corresponding equivalence judgment conditions are met will the query rewriting and route switching be completed automatically. If the conditions are not met, the structured minimum manual confirmation items will be output to block automatic submission. S5. Adopting the closed-world assumption, constraint verification is performed on the specified data snapshot based on the shape constraint language; the verification node is divided into the blocking submission level and the recording alarm level. When the blocking submission level verification fails, the compensation process is triggered.

[0010] Furthermore, the syntax difference mentioned in step S1 is specifically as follows: take the set difference of the resource description framework triples set of the old ontology and the new ontology to obtain the added set and the deleted set; The semantic inference specifically involves: for the candidate old classes in the deletion set, searching for the candidate new class set in the addition set, and making a joint judgment using three indicators: label edit distance, neighbor structure Jaccard similarity, and instance coverage, to distinguish between renaming, splitting, merging, and independent deletion / addition operation types.

[0011] Furthermore, the tag edit distance is a normalized edit distance, calculated using the following formula: in, Two strings and Lewinstein distance, , These are the character lengths of the two strings, respectively. The formula for calculating the neighbor structure Jaccard similarity is as follows: in, As a candidate old class, As a candidate new class, For class The set of Uniform Resource Identifiers for the objects of directly related relation type triples; The instance coverage rate is the percentage of the intersection of the old class instance set and the union of all new class instance sets in the class splitting scenario, and the percentage of the intersection of the old attribute subject set and the union of all new attribute subject sets in the attribute splitting scenario.

[0012] Furthermore, the deterministic topological sorting in step S2 specifically involves: performing a topological sorting on the dependent directed acyclic graph, and in each step selecting the node with the smallest lexicographical order from the nodes with an in-degree of 0, thereby generating a unique execution sequence; The compensation operation is specifically as follows: establish a compensation mapping for each strictly reversible node; when execution fails, perform idempotent compensation operation in reverse order of completed nodes to restore the temporary state to the state before execution; nodes that do not meet the strictly reversible condition are marked as having no compensation guarantee and the automatic submission path is blocked.

[0013] Furthermore, step S2 also includes an audit freeze mechanism: before the data migration node is executed, the original data before migration is written into the audit naming graph that is uniquely bound to the current change transaction graph; after all data nodes are executed, the audit naming graph is frozen and the normalized hash value is calculated; all verification nodes that reference the audit graph have the audit freeze event as a prerequisite.

[0014] Furthermore, the version record mentioned in step S3 is divided into four groups of fields: Group A consists of required fields for all committed versions, including version identifier, schema version hash, data version hash, route version hash, commit sequence number, branch identifier, parent version identifier list, effective time, and expiration time. Group B consists of fields that are not required for the initial version, including the change transaction graph identifier, mapping rule version hash, logical deletion triple set, recent snapshot reference, incremental reference, and replay mode. C is a required field for merging versions, including the most recent common ancestor version identifier and the merging increment reference; Group D contains all audit fields that are required for non-initial versions, including audit graph references and audit graph hashes.

[0015] Furthermore, the reconstruction process for the merged version in step S3 is as follows: S31. Based on the nearest common ancestor version identifier in the merged version record, load the complete knowledge graph snapshot of the corresponding version; S32. Apply the merged increment to the nearest common ancestor snapshot to obtain the merged knowledge graph state; S33. Calculate the normalized hash values ​​of the merged ontology schema and instance data respectively, and compare them with the schema version hash and data version hash in the version record; if they match, the reconstruction is confirmed to be valid, otherwise the reconstruction is rejected and an alarm is issued.

[0016] Furthermore, the static proof of equivalence in step S4 refers to proving the semantic equivalence of queries before and after rewriting based solely on the ontology schema structure; the runtime proof of equivalence refers to confirming the equivalence of query result sets before and after rewriting under variable mapping through runtime data verification. The runtime proof of equivalence in the attribute splitting scenario must satisfy the following: all old attribute values ​​are successfully split, the value level coverage is 1.0, the merged value after splitting is conserved from the original value, and all query operations are within the preset whitelist range.

[0017] Furthermore, the closed-world assumption mentioned in step S5 specifically means: attributes or instances that do not appear explicitly in the target data graph are treated as not satisfying constraints; open-world reasoning is not used by default to complete missing values. The severity levels of the verification nodes are divided into errors and warnings. When an error-level verification fails, the submission is blocked and compensation is triggered. When a warning-level verification fails, diagnostic information is recorded and subsequent execution continues.

[0018] According to a second aspect of the present invention, a cross-version knowledge graph consistency maintenance system based on ontology semantic differential is provided, comprising: The ontology semantic difference calculation engine module is used to take the old ontology and the new ontology as input, perform syntax difference and semantic inference in sequence, and generate a set of difference results with semantic labels containing multiple types of atomic operations; The change transaction graph construction and execution module is used to construct a change transaction graph from the differential result set. The change transaction graph includes a dependent directed acyclic graph, an executable compensation mapping, and a mutual exclusion set. A deterministic topological sort is performed on the dependent directed acyclic graph to obtain an execution sequence. In the temporary storage environment, the mode change, data migration, query rewriting, and constraint verification nodes are executed sequentially according to the execution sequence. If the execution fails, a compensation operation is triggered in reverse order to block version submission. The multidimensional version identification and storage model module is used to generate a version record for each committed version, which includes a pattern hash, a data hash, a version routing hash, and an association with the parent version. For merged versions, the least common ancestor is calculated and a complete merge increment from the least common ancestor to the merged version is generated, ensuring that the reconstruction path of the merged version is unique. The query rewriting module is used to rewrite and adapt registered SPARQL queries, classifying query equivalence into two levels: static proof equivalence and runtime proof equivalence. It automatically completes query rewriting and route switching only when the corresponding equivalence judgment conditions are met; otherwise, it outputs a minimal structured manual confirmation item and blocks automatic submission. The SHACL verification module is used to perform constraint verification on a specified data snapshot based on the closed-world assumption and shape constraint language. The verification nodes are divided into blocking submission level and recording alarm level. When the blocking submission level verification fails, the compensation process is triggered.

[0019] The technical solutions provided by the embodiments of the present invention may include the following beneficial effects: 1. By changing the dependency constraints and deterministic topology sorting of the transaction graph, the schema change, data migration, verification, and compatibility processing are executed in the correct order within the same temporary context; automatic compensation is provided in case of failure, without switching version routes, and dirty data is prevented from being visible to the outside, thereby eliminating errors in the execution order of batch changes.

[0020] 2. Restrict query rewriting to a strict algebraic whitelist, set two levels of equivalence judgment criteria, output structured minimum confirmation items for queries that cannot be proven to be equivalent, and do not silently rewrite them, thus ensuring semantic consistency of downstream queries and eliminating silent query rewriting errors.

[0021] 3. The merged version achieves unique reconstruction through LCA + full mergeDelta, combined with dual hash verification of schema and data, to ensure that the reconstruction results of historical states are certain and verifiable, meeting the needs of auditing and backtracking.

[0022] 4. A hybrid storage model of checkpoints and incremental updates is adopted to balance storage overhead and reconstruction efficiency. The checkpoint interval can be flexibly configured according to business scenarios.

[0023] 5. Limit the scope of manual intervention. Set strict conditions for full coverage, conservation and whitelist for automatic operation. For objects that do not meet the conditions, accurately output the minimum confirmation items such as uncovered instances and conflict reasons. The boundaries of manual processing are clear and traceable.

[0024] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and are not intended to limit the invention. Attached Figure Description

[0025] The above and other objects, features and advantages of the present invention will become more apparent from the more detailed description of exemplary embodiments of the invention in conjunction with the accompanying drawings, wherein the same reference numerals generally represent the same components in the exemplary embodiments of the invention.

[0026] Figure 1 This is a diagram of the overall system architecture of the present invention; Figure 2 This is a flowchart of the semantic difference and traffic splitting determination process of this invention; Figure 3 This is a flowchart of the CTG temporary submission status for this invention; Figure 4 This is a schematic diagram showing the association between the version record and the audit diagram of this invention; Figure 5 This is a schematic diagram of the multi-branch merging and unique reconstruction of the present invention; Figure 6 This is a flowchart illustrating the query rewriting and manual confirmation process of this invention. Figure 7 This is a schematic diagram of the core technology chain and submission blocking conditions of the present invention. Detailed Implementation

[0027] Preferred embodiments of the invention will now be described in more detail with reference to the accompanying drawings. While preferred embodiments of the invention are shown in the drawings, it should be understood that the invention can be implemented in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided so that the invention will be thorough and complete, and will fully convey the scope of the invention to those skilled in the art.

[0028] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the invention. The singular forms “a,” “the,” and “the” used in this invention and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used herein refers to and includes any or all possible combinations of one or more of the associated listed items.

[0029] It should be understood that although the terms "first," "second," "third," etc., may be used in this invention to describe various information, this information should not be limited to these terms. These terms are only used to distinguish information of the same type from one another. For example, without departing from the scope of this invention, first information may also be referred to as second information, and similarly, second information may also be referred to as first information. Thus, features defined as "first" or "second" may explicitly or implicitly include one or more of that feature. In the description of this invention, "a plurality of" means two or more, unless otherwise explicitly specified.

[0030] The technical solutions of the embodiments of the present invention are described in detail below with reference to the accompanying drawings.

[0031] This invention provides a cross-version knowledge graph consistency maintenance method based on ontology semantic difference, comprising five steps: ontology semantic difference calculation, change transaction graph construction and execution, multi-dimensional version identification and storage, provable equivalent query rewriting, and closed-world constraint verification. The overall process takes snapshots of the old and new versions of Web Ontology Language (OWL), existing instance data, and registered SPARQL protocol and RDF Query Language (SPARQL) query sets as input. Using the change transaction graph as the core execution carrier, it sequentially completes change identification, ordered execution, version archiving, query adaptation, and consistency verification, ultimately outputting a routable new version or structured manually confirmed items. The specific implementation of each step is as follows: S1, Ontology Semantic Difference Calculation In this embodiment, specifically, this step is executed by the ontology semantic difference calculation engine, with the old ontology as the input. With the new ontology Both are stored in Web Ontology Language (OWL) / Resource Description Framework (RDF) format. The engine executes two stages: syntax difference and semantic inference. The first stage uses triple set difference operations to initially distinguish between added and deleted content. The second stage uses a triple similarity index of labels, structure, and instances to perform semantic disambiguation, identifying changes as 12 types of atomic operations with semantic labels, and outputting a structured set of difference results to provide input for the subsequent construction of the change transaction graph.

[0032] S2, Change Transaction Diagram Construction and Execution In this embodiment, specifically, this step constructs a Change Transaction Graph (CTG) based on the differential result set output by S1. The CTG consists of three independent structures: a dependent directed acyclic graph (DAG), an executable compensation map, and a mutual exclusion set, used to manage execution order, failure rollback, and concurrency conflicts, respectively. After construction, a deterministic topological sort is performed on the dependent DAG to generate a globally unique execution sequence. Subsequently, in an independent temporary storage environment, five types of nodes—mode change, data migration, query rewriting, and constraint verification—are executed sequentially according to the sequence. If any core node fails, a compensation operation is triggered in reverse order of the completed nodes, restoring the temporary storage environment to its pre-execution state and preventing the formal version commit.

[0033] S3, Multidimensional Version Identification and Storage In this embodiment, specifically, this step generates a standardized version record for each successfully submitted version. The record includes core fields such as pattern hash, data hash, routing hash, and association with the parent version, thus providing a unique identifier for each version. For merged versions generated by parallel development across multiple branches, the system first calculates the Lowest Common Ancestor (LCA) of the two parent versions using a deterministic algorithm, and then generates a complete merge increment from the LCA to the merged version. This ensures that the reconstruction of the merged version depends only on the LCA snapshot and the merge increment, and not on the replay paths of the two parent chains, guaranteeing a unique reconstruction path and a deterministic result.

[0034] S4, Provable Equivalent Query Rewriting In this embodiment, specifically, this step performs rewriting adaptation for registered SPARQL queries based on the ontology change type. The system divides query equivalence into two strict levels: static proof equivalence and runtime proof equivalence. Only when all the judgment conditions of the corresponding level are met will the query be automatically rewritten and connected to the new version route. If the equivalence conditions are not met, silent rewriting is not performed. Instead, a structured manual confirmation item containing the failure reason, minimum confirmation items, and suggested solutions is output, and the automatic route switching of the query is blocked.

[0035] S5, Closed World Constraint Verification In this embodiment, specifically, this step performs constraint verification on a specified data snapshot based on Shapes Constraint Language (SHACL). The entire process employs the Closed World Assumption (CWA), meaning that any content not explicitly declared in the data graph is treated as not satisfying constraints, and open-world inference is not used by default to complete missing values. Verification nodes are categorized by severity into two levels: blocking submission and recording alarms. A blocking submission level verification failure directly triggers the compensation process, terminating the version submission; a recording alarm level only retains diagnostic information and does not affect subsequent node execution or version submission.

[0036] In this embodiment of the method, the following technical effects can be achieved through the coordinated operation of the above five steps: First, it eliminates the order error of batch ontology changes at the execution level, avoiding data corruption problems such as instance silos and constraint violations caused by dependency inversion; second, it eliminates silent semantic errors at the query level, preventing queries that are syntactically correct but semantically biased after rewriting from flowing downstream; third, it ensures the determinism and reproducibility of historical state reconstruction at the version level, meeting the strong consistency requirements of auditing, backtracking, and multi-branch collaboration; and fourth, through a hierarchical mechanism of automation + manual confirmation, it minimizes the cost of manual intervention while ensuring data security, and achieves cross-version strong consistency maintenance of ontology schema and instance data.

[0037] Optionally, in this embodiment, the syntax difference in step S1 specifically involves taking the set difference between the resource description framework triples of the old ontology and the new ontology to obtain the added set and the deleted set; The semantic inference specifically involves: for the candidate old classes in the deletion set, searching for the candidate new class set in the addition set, and making a joint judgment using three indicators: label edit distance, neighbor structure Jaccard similarity, and instance coverage, to distinguish between renaming, splitting, merging, and independent deletion / addition operation types.

[0038] In this embodiment, specifically, such as Figure 2 As shown, the syntax difference stage parses both the old and new ontology into sets of triples, and obtains the new set through set difference operations. Deleting a collection Triples that only appear in the new version are added to the new set, and those that only appear in the old version are added to the delete set. This allows for the initial identification of independent add and delete operations with no matching relationship.

[0039] In the semantic inference stage, each old class and old attribute in the deletion set is used as a candidate object. Potential matching items are retrieved in the new set. The three indicators of label edit distance, neighbor structure Jaccard similarity and instance coverage are calculated respectively. The operation type is distinguished by joint judgment rules.

[0040] In a specific embodiment, the joint determination criteria for the above three similarity indicators are as follows: 1. The label edit distance between candidate old class and candidate new class is not greater than the threshold (default 0.2); 2. The Jaccard similarity of the neighbor structure between the candidate old class and the candidate new class is not less than the threshold (default 0.6). 3. The intersection of the old instance set and the new instance set accounts for a proportion not less than the threshold (default 0.4). Based on the above similarity criteria, the joint judgment rules for operation types include: one-to-one high similarity matching is judged as renaming; one-to-many matching that satisfies the allocation and conservation rules is judged as splitting; many-to-one matching that satisfies the constraint coverage rule is judged as merging; and no matching relationship is retained as independent deletion and independent addition.

[0041] In this embodiment, specifically, after semantic inference is completed, the system finally outputs a standardized set of 12 types of atomic operations with semantic tags, corresponding to the 12 types of atomic operation encoding tables in the source document. The CC_ prefix represents class-level operations, the CP_ prefix represents property-level operations, the CH_ prefix represents hierarchy operations, and the CR_ prefix represents constraint operations. Each type of operation has a unique operation code, operation type definition, and automatic recognition prerequisites, as detailed below: CC_ADD (Class Addition): Corresponds to classes that appear only in the newly added triplet set and have no triple similarity matches. Automatic identification is based on the premise that they only appear in the newly added set. There is an existing class, but no matching old class exists.

[0042] CC_DEL (Class Deletion): Corresponds to classes that appear only in the deletion triple set and have no matching items. Automatic recognition is based on the premise that they only appear in the deletion set. There exists a matching new class.

[0043] CC_REN (Class Rename): A one-to-one mapping that corresponds to a change in the class's Uniform Resource Identifier but maintains semantic consistency. Automatic recognition requires that all three hard conditions—label edit distance, neighbor structure similarity, and instance coverage—are met, and that the mapping is one-to-one.

[0044] CC_SPL (Class Splitting): This corresponds to the operation of splitting an old class into multiple new classes. When all conditions are met, namely "an explicit instance allocation rule exists, all old instances are allocated with a coverage rate of 1.0, and mutual exclusion / overlap semantics verification passes", it is marked as CC_SPL_AUTO and can be executed automatically. When the coverage rate is between 0.95 and 1.0, only CC_SPL_CONDITIONAL condition candidates and manually confirmed items are output, and automatic migration or submission is not performed.

[0045] CC_MRG (Class Merge): This operation merges multiple old classes into a new class. Automatic recognition is based on the premise that all source class instances can be merged into the new class, and the constraints of the target class, such as field, value range, and cardinality, can cover all source class constraints; if these conditions are not met, candidate items and items requiring manual confirmation will be output.

[0046] CP_ADD (Attribute Addition): Corresponds to attributes that only appear in the newly added collection. Automatic recognition is based on the premise that the attribute only appears in the newly added collection. The predicate type triples that exist in the code do not match the old attributes; in this embodiment, ex:baseSalary and ex:bonus will be initially marked as such during the syntax difference stage.

[0047] CP_DEL (Attribute Deletion): Corresponds to attributes that only appear in the deletion set. Automatic recognition is based on the premise that the attribute only appears in the deletion set. There is no matching new attribute; in this embodiment, ex:salary will be initially marked as this type during the syntax difference stage.

[0048] CP_REN (Attribute Rename): A one-to-one mapping to the change of the Uniform Resource Identifier for the corresponding attribute. Automatic recognition is based on the premise that the domain, value range constraints and instance usage are similar and are a one-to-one mapping.

[0049] CP_SPL (Attribute Splitting): This corresponds to the operation of splitting an old attribute into multiple new attributes. When all the conditions are met, namely "there is an executable splitting function or explicit mapping table, there is a verifiable merging function, all old attribute instances are allocated and the value level coverage is 1.0", it is marked as CP_SPL_AUTO and can be executed automatically. When the coverage is between 0.95 and 1.0, only the CP_SPL_CONDITIONAL condition candidate and the manually confirmed item are output. In this embodiment, the salary splitting is finally identified as CP_SPL_AUTO.

[0050] CP_MRG (Attribute Merge): This operation merges multiple old attributes into a new attribute. Automatic recognition is provided that the source attribute value range, data type, and instance semantics are compatible; otherwise, only candidate and manually confirmed items are output.

[0051] CH_MOV (Hierarchical Migration): This operation changes the hierarchical position of a class or attribute while keeping its own Uniform Resource Identifier unchanged. Automatic recognition is based on the premise that the URI of the parent class / parent attribute changes while the URI of the attribute itself remains unchanged. In this example 2, the adjustment of the parent class of the Manager class is this type of operation.

[0052] CR_CHG (Relationship Constraint Change): The constraint conditions of the corresponding class or attribute have changed. It is automatically recognized when the domain, value range, cardinality, or semantic attribute changes, while the URI itself remains unchanged.

[0053] All atomic operations are assigned an operation sequence number after being sorted by "opcode, source URI, target URI, and normalized operation parameters". This sequence number serves as the basis for constructing schema nodes in the subsequent change transaction graph. Each type of operation generates a different combination of nodes, forming a one-to-one generation rule with the five types of CTG nodes.

[0054] In this embodiment, syntax difference is based on set operations to achieve fast and unambiguous basic difference identification, ensuring the integrity of change detection; semantic inference overcomes the limitations of pure syntax difference through multi-dimensional joint judgment, and can accurately identify compound changes with semantic associations such as renaming, splitting, and merging, avoiding misjudging semantically continuous changes as independent deletion + addition, providing accurate change semantic input for subsequent automated execution, and greatly reducing the workload of manual semantic judgment.

[0055] Optionally, in this embodiment, the label edit distance is the normalized edit distance (NED), calculated using the following formula: in, The Levenstein distance between two strings. , These represent the character lengths of the two strings; the strings undergo lemmatization and lowercase conversion before being included in the calculation.

[0056] The formula for calculating the neighbor structure Jaccard similarity is as follows: in, For class The set of Uniform Resource Identifiers (URIs) that are objects of directly related relational triples.

[0057] The instance coverage rate is the percentage of the intersection of the old class instance set and the union of all new class instance sets in the class splitting scenario, and the percentage of the intersection of the old attribute subject set and the union of all new attribute subject sets in the attribute splitting scenario.

[0058] In this embodiment, specifically, before calculating the normalized edit distance of the labels, lemmatization and lowercase preprocessing are performed on the rdfs:label text of the class / attribute. For example, WordNet lemmatization tool can be used for English, and stop word filtering and stemming are used for Chinese. Then, the standard Levenshtein distance is calculated and divided by the length of the longer string to obtain the normalized distance value in the range of 0 to 1. The smaller the value, the higher the label similarity.

[0059] When calculating the Jaccard similarity of the neighbor structure, the neighbor set only counts the object URIs corresponding to the six relation types: rdfs:domain, rdfs:range, rdfs:subClassOf, rdfs:subPropertyOf, owl:equivalentClass, and owl:equivalentProperty. The similarity is obtained by dividing the number of intersection elements by the number of union elements. The closer the value is to 1, the more similar the ontology structure context is.

[0060] Instance coverage is defined separately for classes and attributes: In the case of class splitting, it is the percentage of the intersection of the old class instance set and the union of all new class instance sets; in the case of attribute splitting, it is the percentage of the intersection of the old attribute subject set and the union of all new attribute subject sets. This is used to measure the degree of coverage of changes on existing instances.

[0061] In this embodiment, the three dimensions of label, structure, and instance complement each other, taking into account both text semantic similarity and ontology context structure and actual data distribution, thereby improving the accuracy and recall rate of change recall. All indicators adopt standardized formulas and configurable thresholds to ensure the reproducibility and configurability of differential recognition results, which can adapt to the differentiated recognition needs of different domains and different scales of ontology, and avoid result fluctuations caused by subjective judgment.

[0062] Optionally, in this embodiment, the automatic identification of class splitting operation needs to meet the following conditions: there is an explicit instance allocation rule, all old instances are allocated and the coverage rate is 1.0, and the mutual exclusion or overlap semantic verification is passed; the automatic identification of attribute splitting operation needs to meet the following conditions: there is an executable value splitting function and a verifiable merging function, all old attribute instances are allocated and the value level coverage rate is 1.0, and the result of splitting and merging is conserved with the original value; when the coverage rate is between the preset condition threshold and 1.0, the condition candidates and manual confirmation items are output, and automatic migration and rewriting are not performed.

[0063] In this embodiment, the automatic execution path for class splitting (CC_SPL_AUTO) sets three mandatory thresholds: First, there must be an executable explicit instance allocation rule that can determine the new class to which each old instance belongs; second, all old instances can be allocated, the instance coverage rate must reach 1.0, and there are no unallocated instances; third, the owl:disjointWith mutual exclusion constraint between new classes is checked, and if instance overlap is allowed, the overlap attribute is marked and the automatic rewriting of related counting class queries is prohibited.

[0064] The attribute splitting automatic execution path (CP_SPL_AUTO) sets four mandatory thresholds: First, there must be an executable splitting function. First, the input / output types strictly match the value ranges of the old and new attributes; second, a verifiable merging function exists. First, it can pass the SHACL node verification; second, all old attribute instances can generate valid new attribute values, with a value level coverage of 1.0; and third, it satisfies the strict conservation of the result of splitting and merging all instances with the original value.

[0065] When the instance coverage is between the condition candidate coverage threshold (default 0.95) and 1.0, the system only outputs the condition candidate flags and the list of uncovered instances, without triggering automatic data migration, query rewriting, or version submission. Manual confirmation is required before proceeding.

[0066] In this embodiment, strict automatic identification thresholds and hierarchical judgment mechanisms are set for class splitting and attribute splitting. Full coverage and conservation are used as mandatory standards for automatic execution to avoid data omissions and semantic distortions in automatic migration from the source. Through a three-level diversion of "automatic execution - condition candidate - manual confirmation", the execution efficiency of high-confidence changes is ensured while the risk is controlled to the minimum. The objects and boundaries of manual intervention are precisely defined to avoid the efficiency loss caused by indiscriminate manual review, while eliminating the risk of erroneous release of automatic processes.

[0067] Optionally, in this embodiment, the change transaction graph in step S2 includes five types of nodes: The schema node corresponds to an atomic difference operation, which is used to perform ontology schema changes; The data node corresponds to a batch of instance data migration operations and carries an idempotent execution flag. The query node corresponds to a rewrite or markup operation for a registered SPARQL query; The compat node corresponds to a compatibility mapping declaration, which is used to provide compatible access to the old identifier; The verify node corresponds to a SHACL shape verification rule and is used to perform data consistency verification.

[0068] In this embodiment, specifically, the five types of nodes each perform their respective functions, together forming a complete change execution chain: The schema node corresponds to one of the 12 types of atomic difference operations. It only operates on the ontology schema naming graph and is responsible for completing schema-level changes of classes, attributes, levels, and constraints. The data node is responsible for operations such as migration, splitting, and merging of batch instance data. It carries an idempotent execution flag, and repeated execution will not produce data side effects. Before execution, the original values ​​before migration need to be written into the audit graph for retention. The query node corresponds to each registered SPARQL query. Based on the change type, it performs equivalent rewriting or marks the query as pending manual confirmation, thus controlling the switching of query routes. The compat node is used to generate compatibility mapping declarations between the old and new Uniform Resource Identifiers, such as owl:equivalentClass equivalence declarations and virtual attribute views, to support compatibility access for queries from older versions. The verify node corresponds to a SHACL verification rule, which performs consistency verification on the specified temporary data snapshot and is the core verification step before submission.

[0069] In this embodiment, the decoupling design of five types of functional nodes enables the modular separation of five capabilities: schema change, data migration, query adaptation, compatibility support, and consistency verification. The responsibilities are clearly defined, facilitating the independent orchestration of dependencies and compensation logic. It can support lightweight execution of simple changes as well as adapt to full-link management of complex changes, providing standardized execution units for dependency orchestration, failure compensation, and concurrency control of the change transaction graph, thereby improving the scalability and maintainability of the entire change execution system.

[0070] Optionally, in this embodiment, the deterministic topological sorting in step S2 specifically involves: performing a topological sorting on the dependent directed acyclic graph, and in each step selecting the node with the smallest lexicographical order from the nodes with the current in-degree of 0, thereby generating a unique execution sequence; The compensation operation is specifically as follows: establish a compensation mapping for each strictly reversible node; when execution fails, perform idempotent compensation operation in reverse order of completed nodes to restore the temporary state to the state before execution; nodes that do not meet the strictly reversible condition are marked as having no compensation guarantee and the automatic submission path is blocked.

[0071] In this embodiment, specifically, such as Figure 3 As shown, deterministic topological sorting takes a dependent directed acyclic graph as input and adopts the standard topological sorting algorithm. In each round, all nodes with an in-degree of 0 are selected, and the node with the smallest lexicographical ID is added to the execution sequence. The node and its outgoing edges are removed. This process is repeated until all nodes are sorted, and finally a globally unique execution sequence is generated, avoiding the uncertainty of execution results caused by multiple valid topological orders.

[0072] In this embodiment, a deterministic topological sort is performed on the dependent directed acyclic graph. In the temporary storage environment, execution of mode change, data migration, query rewriting, compatibility access processing, and constraint verification nodes are carried out according to the obtained execution sequence. Before the data migration node is executed, the original data before migration is written into an audit naming graph uniquely bound to the current change transaction graph. After all data migration nodes are completed, the audit naming graph is frozen and a normalized hash value for the audit graph is generated. Constraint verification nodes referencing the audit naming graph use the frozen event of the audit naming graph as a prerequisite and verify the normalized hash value of the audit graph before execution. Only when the normalized hash value of the audit graph passes verification, the constraint verification at the blocking commit level passes verification, and there are no executed nodes without compensation guarantees, is a new version committed and version route switched. Otherwise, compensation operations are performed in reverse order of completed nodes, blocking version commit and version route switching.

[0073] The compensation operation is implemented based on an independent compensation mapping table. Each strictly reversible node is configured with a corresponding inverse operation as a compensation node. When execution fails, the system calls the compensation nodes in reverse order of the successfully executed nodes, and restores the temporary mode, temporary data, and temporary queries to their pre-change state through idempotent inverse operations. For nodes with irreversible side effects or that cannot fully retain the pre-state, the system marks them as "no compensation guarantee," directly blocking the automatic submission path and transferring them to the manual processing flow.

[0074] In this embodiment, a deterministic topology sorting and reverse order compensation mechanism is designed. The topology rule with lexicographical order as a fallback eliminates the execution uncertainty when there are multiple valid sequences in the dependency graph, ensuring that the same changed input always yields the same execution result. In case of failure, idempotent compensation is performed in reverse order of completed nodes, which can accurately restore the temporary environment to the state before the change, avoid the exposure of dirty data from partially executed nodes, and prevent data corruption caused by batch change order errors from the execution mechanism, thus ensuring the atomicity of version commit.

[0075] Optionally, in this embodiment, step S2 also includes an audit freeze mechanism: before the data migration node is executed, the original data before migration is written into the audit naming graph that is uniquely bound to the current change transaction graph; after all data nodes are executed, the audit naming graph is frozen and the normalized hash value is calculated; all verification nodes that reference the audit graph have the audit freeze event as a prerequisite.

[0076] In this embodiment, specifically, each CTG is assigned a globally unique change transaction graph identifier (ctgId), corresponding to a dedicated audit naming graph, with the graph URI format as follows:<audit:{ctgId}> This ensures that audit data from different change transactions and branches does not interfere with each other. Before the data node performs data migration, all original values ​​of the instances involved before migration are appended to the audit naming graph. The audit graph only supports appending and cannot modify existing data.

[0077] After all data nodes have completed execution, the system triggers an audit freeze event, setting the audit named graph to read-only mode. The audit graph is then standardized using the 2015 version of the RDF Dataset Canonicalization 2015 (URDNA2015) algorithm, and its SHA-256 hash value is calculated as the auditHash and stored in the version record. All verify nodes that need to reference the audit graph have a "Frozen Audit" pre-dependency edge added to their dependency graph to ensure that verification is only performed after the audit graph is solidified, preventing audit data from being tampered with.

[0078] In this embodiment, a dedicated audit naming graph and freezing mechanism are used to achieve the following: First, it provides a reliable original value basis for data conservation verification. The audit graph can only be added to and cannot be modified. Furthermore, the integrity is guaranteed by hash verification, eliminating the risk of verification data being tampered with. Second, it ensures that verification is only performed after the audit data is solidified through pre-dependency constraints, avoiding the distortion of results caused by changes in the audit data during the verification process. Third, it enables full-link auditability of change operations. All data migrations retain original snapshots, meeting the needs of compliance traceability and fault diagnosis.

[0079] Optionally, in this embodiment, the version record in step S3 is divided into four groups of fields: Group A consists of required fields for all committed versions, including version ID (versionId), schema version hash (schemaVersion), data version hash (dataVersion), route version hash (routeVersion), commit sequence number (commitSeq), branch ID (branchId), parent version ID list (parentVersionIds), effective time (validFrom), and expiration time (validTo). Group B consists of fields that are required for non-initial versions, including the change transaction graph identifier (ctgId), mapping rule version hash (mappingRuleVersion), logical deletion triple set (tombstones), recent snapshot reference (snapshotRef), incremental reference (deltaRef), and replay mode (replayMode). C is a required field for merging versions, including the most recent common ancestor version identifier (lcaVersionId) and the merge incremental reference (mergeDelta). Group D contains all audit fields that are required for non-initial versions, including audit graph reference (auditGraphRef) and audit graph hash (auditHash).

[0080] In this embodiment, specifically, such as Figure 4 As shown, the four sets of fields work together to achieve unique version identification, traceability, reconstructability, and auditability: Group A fields contain the basic identity information of the version. Among them, the schema version hash corresponds to the normalized hash of the ontology schema naming graph, the data version hash corresponds to the normalized hash of the instance data naming graph, and the route version hash corresponds to the hash of the query registry and compatibility view. The three are independent of each other and verify the integrity of the schema, data, and route respectively. The submission sequence number is a monotonically increasing global sequence number used for conflict resolution. Group B fields support incremental replay and change tracing, recording the CTG number that generated the version, the compatible mapping rule version, logically deleted content, the location of the most recent snapshot, incremental data references and replay modes. Linear versions reconstruct snapshots through incremental replay of the parent chain. Group C fields are specific to the merged version, recording the most recent common ancestor version ID and the complete merge incremental reference, supporting the unique reconstruction of the merged version; Group D fields are specific to auditing, binding the version to the corresponding audit graph, and retaining the audit graph hash for integrity verification to ensure the audit data is tamper-proof. The audit graph hash can be calculated by performing URDNA2015 RDF dataset normalization on the frozen audit naming graph, obtaining the normalized N-Quads byte sequence, and then using the SHA-256 algorithm. Before execution, the verification node performs integrity verification on the frozen audit naming graph based on the audit graph reference and audit graph hash value recorded in the version record. If the integrity verification is inconsistent, the verification node is not executed, the audit anomaly is recorded, and version submission and version routing switching are blocked.

[0081] In this embodiment, a multi-dimensional version identification system consisting of four sets of fields, where mode, data, and route are independently hashed and verified, can accurately locate the dimensions of version differences and avoid mutual interference between changes at different levels; the snapshot + incremental field design balances storage overhead and reconstruction efficiency, and can flexibly weigh cost and performance through checkpoint intervals; merging version-specific fields supports unique reconstruction, and audit fields are bound to version and change evidence, ultimately achieving unique identification, complete traceability, deterministic reconstruction, and compliant auditing for each version.

[0082] Optionally, in this embodiment, the reconstruction process of the merged versions in step S3 is as follows: S31. Based on the nearest common ancestor version identifier in the merged version record, load the complete knowledge graph snapshot of the corresponding version; S32. Apply the merged increment to the nearest common ancestor snapshot to obtain the merged knowledge graph state; S33. Calculate the normalized hash values ​​of the merged ontology schema and instance data respectively, and compare them with the schema version hash and data version hash in the version record; if they match, the reconstruction is confirmed to be valid, otherwise the reconstruction is rejected and an alarm is issued.

[0083] In this embodiment, specifically, such as Figure 5 As shown, the merged version reconstruction does not use the method of replaying the two parent chains separately, but strictly follows a single path of "LCA + merge increment": The first step is to read the lcaVersionId field from the merged version record, locate the most recent common ancestor version, load the complete knowledge graph snapshot based on the snapshotRef and playback mode of that version, and first verify whether the snapshot's mode hash and data hash are consistent with the record to ensure that the basic snapshot is complete and reliable. The second step is to load the mergeDelta merge increment, which contains all the add, delete, and replace operations from LCA to the merged version, with conflict resolution completed. The increment is then applied to the LCA snapshot in the order of "delete first, then replace, then add" to obtain the complete merged dataset. The third step involves performing URDNA2015 normalization and SHA-256 hash calculations on the merged schema naming graph and data naming graph, respectively, and comparing them one by one with the schemaVersion and dataVersion in the version record. If both hashes match, the reconstruction is deemed valid and the reconstruction result is returned. If either does not match, the reconstruction path is deemed abnormal, the data is rejected, and an alarm is recorded.

[0084] In this embodiment, the designed reconstruction process of "LCA + complete merge increment + double hash verification" completely eliminates the uncertain path of replaying the two parent chains separately. The merged version status is uniquely determined only by the nearest common ancestor and the merge increment, ensuring the consistency of historical reconstruction results in multi-branch scenarios. The dual hash verification of pattern and data serves as a final fallback, which can promptly detect anomalies such as increment corruption and replay errors, refuse to output unreliable historical snapshots, and ensure the certainty of historical query and backtracking results.

[0085] Optionally, in this embodiment, the static proof of equivalence in step S4 refers to proving the semantic equivalence of the queries before and after rewriting based solely on the ontology schema structure; the runtime proof of equivalence refers to confirming the equivalence of the query result sets before and after rewriting under variable mapping through runtime data verification. The runtime proof of equivalence in the attribute splitting scenario must satisfy the following: all old attribute values ​​are successfully split, the value level coverage is 1.0, the merged value after splitting is conserved from the original value, and all query operations are within the preset whitelist range.

[0086] In this embodiment, specifically, such as Figure 6As shown, the two-level equivalence determination strictly distinguishes the basis for proof: Static proof of equivalence relies solely on the structural information of the ontology schema, without needing to verify instance data. For example, in a class renaming scenario, if the query only uses rdf:type for exact type matching, without reasoning expansion or existence checks, then it can be statically proven that the semantics are completely consistent before and after the rewrite. Runtime equivalence proofs require verification results from instance data. Equivalence is only valid for the current version of the dataset. For example, in the scenario of attribute splitting, four conditions must be met simultaneously to mark it as runtime equivalence proofs: First, all old attribute instances are successfully split into new attribute values, with 100% value-level coverage; second, all instances pass the conservation check, and the merged value after splitting is completely equal to the original value; third, all operations in the query belong to the automatic rewriting whitelist; and fourth, the variable binding status, result cardinality, and sorting and pagination semantics of the query before and after rewriting are completely consistent.

[0087] Queries that do not meet the equivalence criteria will not be automatically rewritten and will be marked as pending manual review.

[0088] In this embodiment, a two-level equivalence judgment standard and a whitelist mechanism are designed to strictly distinguish the boundary between "static provability" and "runtime provability" and prevent false claims that equate migration strategy selection with equivalence proof. Automatic rewriting is limited to a controllable computational range, and manual confirmation items are actively output for complex operations such as aggregation, pathing, and reasoning. This mechanism eliminates the risk of silent errors in query rewriting and ensures the consistency of query semantics and the accuracy of results in downstream applications during version iteration.

[0089] Optionally, in this embodiment, the closed-world assumption in step S5 specifically means: attributes or instances that do not appear explicitly in the target data graph are treated as not satisfying constraints; open-world reasoning is not used by default to complete missing values. The severity levels of the verification nodes are divided into errors and warnings. When an error-level verification fails, the submission is blocked and compensation is triggered. When a warning-level verification fails, diagnostic information is recorded and subsequent execution continues.

[0090] In this embodiment, specifically, the SHACL verification under the closed-world assumption strictly relies on the explicit triples in the target snapshot: if an instance lacks a required attribute declared in the Shape declaration, the attribute value type does not match, the value exceeds the value range, or the cardinality constraint is violated, it is directly determined as a constraint violation; it will not default to satisfying the constraint because open-world inference assumes "there may be undeclared attributes". If the business requires verification based on the inference result, the inference result must first be materialized into an explicit triple and written into the specified named graph, and the inference rule version must be registered before it can be used as verification input.

[0091] Verification nodes are divided into two levels according to severity: error level corresponds to the BLOCK_COMMIT policy, which immediately terminates the execution of subsequent nodes, triggers the compensation rollback process, and marks the version as a failure when verification fails; warning level corresponds to the LOG_AND_CONTINUE policy, which only records violation details and diagnostic information when verification fails, without interrupting the execution process or blocking version submission, and is used for non-mandatory diagnosis and optimization prompts.

[0092] In this embodiment, the constraint verification under the closed-world assumption is more rigorous, avoiding the "virtual satisfaction" problem caused by open-world reasoning and ensuring that the data truly meets the constraint requirements. The two-level classification mechanism of errors and warnings can not only firmly safeguard the bottom line of core data consistency by blocking submissions, but also carry out diagnostic and optimization verification needs through non-blocking alarms, taking into account both data quality control and version iteration efficiency, and adapting to business scenarios with different levels of strictness.

[0093] In conclusion, Figure 7 The diagram shows the core technology chain and submission blocking conditions of this invention, illustrating the causal relationship between semantic differential, CTG construction, temporary storage, audit freeze, blocking verification, failure compensation, and atomic submission.

[0094] For ease of understanding, the present invention provides the following three embodiments.

[0095] Example 1: Proof of Semantic Difference and Query Equivalence for Attribute Splitting Changes In this embodiment, the scenario is as follows: In an enterprise human resources knowledge graph, the attribute ex:salary is split into ex:baseSalary and ex:bonus to verify the semantic difference recognition, CTG execution and query equivalence proof capabilities of this method.

[0096] Step 1: Ontology semantic difference calculation Enter version and The ontology snapshot is used to perform a two-phase differential operation: Syntax Differentiation Stage: After exact matching of the URI, it was detected that ex:salary is in a new version. The following do not exist: ex:baseSalary and ex:bonus are newly added. Initially, this is marked as a combination of attribute deletion and attribute addition.

[0097] Semantic disambiguation stage: Three similarity metrics are calculated for candidate recall and ranking, but are not used as hard thresholds for automatic splitting. These metrics include: 1. Tag normalized edit distance: The normalized edit distance between salary and baseSalary is 0.40, and between salary and bonus is 1.00, both of which are included in the candidate set; 2. Neighbor structure Jaccard similarity: The old attribute neighbor set is {Employee, xsd: decimal, compensation}, and the new attribute union neighbor set is {Employee, xsd: decimal, compensation, Payroll}. The Jaccard similarity is approximately 0.67, which meets the candidate recall threshold. 3. Instance Coverage: All employee instances successfully generated two new attribute values, achieving set-level coverage. .

[0098] Further verification of the automatic recognition conditions for attribute splitting: 1. Define the splitting function: (Basic salary accounts for 80%, rounded to two decimal places, with half-rounding rules applied). ; 2. Define the merge function: ; 3. Full instance verification: The result of splitting and merging all instances is exactly equal to the original salary, the value level coverage is 1.0, and there are no unallocated instances.

[0099] The final identification is CP_SPL_AUTO (automatic execution of attribute splitting), and the operation code is CP_SPL(ex:salary→ex:baseSalary,ex:bonus).

[0100] Step 2: CTG Construction and Execution Construct a change transaction graph containing the following nodes: s1: schema node, registers the schema declaration for new attributes; d1: The data node, migrates all instance salary data according to the split function, and writes the original salaries into the audit naming graph before execution. <audit:ctg-2024-001>; v1: Verify node, performs salary conservation SHACL verification; q1: The query node performs an equivalent rewrite of the registered query; c1: The compat node, which writes the compatibility access view for salary attributes.

[0101] Dependency arcs: s1→d1, d1→v1, s1→q1, v1→q1, v1→c1; Compensation mapping: d1→d1_rollback (restores the original value from the audit graph when data migration fails).

[0102] Execution process: 1. Topological sorting yields a unique execution sequence: s1→d1→v1→q1→c1; 2. Execute s1 to register two new attributes in the temporary schema diagram; 3. Execute d1, first write all employees' original salaries into the audit graph, then execute the split migration and write them into the temporary data graph; 4. Freeze the audit graph, calculate the audit hash, and store it in the version record; 5. Execute v1 to run conservation checks in closed-world mode: verify that baseSalary + bonus = archivedSalary for each instance (archivedSalary comes from the audit graph). 6. After successful verification, execute q1 and c1 to complete the query rewriting and compatible view generation; 7. All nodes executed successfully, atomically committed the version, and switched routes.

[0103] Step 3: Query equivalence determination The equivalence determination process for registration query Q_001 is as follows: 1. Query operation type verification: only includes basic graph mode and simple numerical filtering, which belongs to the automatic whitelist rewriting; 2. Verify node v1 has verified that the full instance salary is conserved and meets the runtime equivalence condition; 3. Generate a rewritten query, marked as RUNTIME_PROVEN: The result sets before and after the rewrite are completely equivalent, and downstream applications are unaware of this.

[0104] Example 2: Classification of Atomic Operations for Class Hierarchy Migration Changes This example scenario involves changing the parent class of class ex:Manager from ex:Staff to ex:Employee to verify the classification and execution logic of hierarchical migration operations. The specific process is as follows: 1. Atomic operation determination The distinction made by this invention regarding class hierarchy adjustments is as follows: (1) CH_MOV (hierarchical migration): Replaces the parent class, the class's own URI and instance remain unchanged, the effect is to remove the old rdfs:subClassOf relationship and add a new rdfs:subClassOf relationship; (2) CR_CHG (Constraint Change): While retaining the original parent class, a new parent class is added (multiple inheritance), only adding the rdfs:subClassOf relationship.

[0105] In this scenario, the parent class is replaced, so the operation CH_MOV(ex:Manager,ex:Staff→ex:Employee) is selected.

[0106] 2. CTG execution and query equivalence The CTG structure consists of schema node s2, query node q2, and compat node c2, with dependency edges s2→q2 and s2→c2.

[0107] The rules for determining query equivalence are as follows: (1) If the query only uses rdf:typeex:Manager for exact type matching, it belongs to STATIC_PROVEN and does not need to be rewritten or directly adapted; (2) If the query uses rdfs:subClassOf+passive closure path query, the equivalence is RUNTIME_PROVEN, and the instance set under the new level needs to be verified at runtime to be consistent with the expectation.

[0108] Example 3: Multi-branch parallel development and version uniqueness of merged versions The scenario in this example is: Team A and Team B develop in parallel on the same knowledge graph, and finally merge into the main branch to verify the unique reconstruction capability of the merged version.

[0109] First, let's explain the version branch structure, starting with the initial version. Based on a common ancestor, two branches diverged: Branch A: Branch B: Merged version The parent version is and .

[0110] The merge build process is as follows: 1. Calculate LCA: Determine the lowest common ancestor (LCA) of the two parent versions using a breadth-first search of the reverse parent chain. ; 2. Generate mergeDelta: Calculate separately arrive , arrive The increment is normalized into three final states: deletion, replacement, and addition; non-conflicting operations are combined into a union, and conflicting operations are decided according to the monotonically increasing rule of the commit sequence number (the larger commit sequence number takes precedence). 3. Generate merged version record and register lcaVersionId= MergeDelta references, and the merged pattern hash and data hash.

[0111] The merge version rebuild process is as follows: 1. Loading The corresponding complete snapshot is verified to ensure that its pattern hash matches the data hash. 2. Directly apply mergeDelta to A snapshot shows the merged state. 3. Calculate the hashes of the merged schema diagram and data diagram, and compare them with schemaVersion and dataVersion in the version record; if they match, the reconstruction is successful; if they do not match, reject the return and issue an alarm.

[0112] This process ensures that the merged version state is uniquely determined only by LCA and mergeDelta, without relying on the replay order of the two parent chains, thus completely eliminating the uncertainty of rebuilding in multi-branch merging.

[0113] like Figure 1 As shown, an exemplary embodiment of the present invention provides a cross-version knowledge graph consistency maintenance system driven by ontology semantic difference, comprising: The ontology semantic difference calculation engine module is used to take the old ontology and the new ontology as input, perform syntax difference and semantic inference in sequence, and generate a set of difference results with semantic labels containing multiple types of atomic operations; The change transaction graph construction and execution module is used to construct a change transaction graph from the differential result set. The change transaction graph includes a dependent directed acyclic graph, an executable compensation mapping, and a mutual exclusion set. A deterministic topological sort is performed on the dependent directed acyclic graph to obtain an execution sequence. In the temporary storage environment, the mode change, data migration, query rewriting, and constraint verification nodes are executed sequentially according to the execution sequence. If the execution fails, a compensation operation is triggered in reverse order to block version submission. The multidimensional version identification and storage model module is used to generate a version record for each committed version, which includes a pattern hash, a data hash, a version routing hash, and an association with the parent version. For merged versions, the least common ancestor is calculated and a complete merge increment from the least common ancestor to the merged version is generated, ensuring that the reconstruction path of the merged version is unique. The query rewriting module is used to rewrite and adapt registered SPARQL queries, classifying query equivalence into two levels: static proof equivalence and runtime proof equivalence. It automatically completes query rewriting and route switching only when the corresponding equivalence judgment conditions are met; otherwise, it outputs a minimal structured manual confirmation item and blocks automatic submission. The SHACL verification module is used to perform constraint verification on a specified data snapshot based on the closed-world assumption and shape constraint language. The verification nodes are divided into blocking submission level and recording alarm level. When the blocking submission level verification fails, the compensation process is triggered.

[0114] Regarding the system in the above embodiments, the specific ways in which each module performs operations have been described in detail in the embodiments related to the method, and will not be elaborated further here.

[0115] An exemplary embodiment of the present invention illustrates a control device including a memory and a processor.

[0116] The processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor can be a microprocessor or any conventional processor.

[0117] Memory can include various types of storage units, such as system memory, read-only memory (ROM), and permanent storage devices. ROM can store static data or instructions required by the processor or other modules of the computer. Permanent storage devices can be read-write storage devices. Permanent storage devices can be non-volatile storage devices that retain stored instructions and data even when the computer is powered off. In some embodiments, permanent storage devices use mass storage devices (e.g., magnetic or optical disks, flash memory) as permanent storage devices. In other embodiments, permanent storage devices can be removable storage devices (e.g., floppy disks, optical drives). System memory can be a read-write storage device or a volatile read-write storage device, such as dynamic random access memory. System memory can store some or all of the instructions and data required by the processor during operation. Furthermore, memory can include any combination of computer-readable storage media, including various types of semiconductor memory chips (DRAM, SRAM, SDRAM, flash memory, programmable read-only memory), and disks and / or optical disks can also be used. In some implementations, the memory may include removable storage devices that are readable and / or writable, such as laser discs (CDs), read-only digital multifunction optical discs (e.g., DVD-ROMs, dual-layer DVD-ROMs), read-only Blu-ray discs, ultra-high density optical discs, flash memory cards (e.g., SD cards, mini SD cards, Micro-SD cards, etc.), magnetic floppy disks, etc. Computer-readable storage media do not contain carrier waves or transient electronic signals transmitted wirelessly or via wired connections.

[0118] The memory stores executable code, which, when processed by the processor, can cause the processor to execute some or all of the methods described above.

[0119] Furthermore, the method according to the present invention can also be implemented as a computer program or computer program product, which includes computer program code instructions for performing some or all of the steps in the above-described method of the present invention.

[0120] Alternatively, the present invention can also be implemented as a non-transitory machine-readable storage medium (or computer-readable storage medium, or machine-readable storage medium) storing executable code (or computer program, or computer instruction code) thereon, which, when executed by a processor of an electronic device (or computing device, server, etc.), causes the processor to perform part or all of the steps of the method described above according to the present invention.

[0121] The present invention has been described in detail above with reference to the accompanying drawings. In the above embodiments, the descriptions of each embodiment have their own emphasis; for parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments. Those skilled in the art should also understand that the actions and modules involved in the specification are not necessarily essential to the present invention. Furthermore, it is understood that the steps in the method of the embodiments of the present invention can be adjusted, combined, and deleted according to actual needs, and the modules in the device of the embodiments of the present invention can be combined, divided, and deleted according to actual needs.

[0122] Those skilled in the art will also understand that the various exemplary logic blocks, modules, circuits, and algorithm steps described in connection with the disclosure herein can be implemented as electronic hardware, computer software, or a combination of both.

[0123] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems and methods according to various embodiments of the present invention. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions marked in the blocks may occur in a different order than those marked in the drawings. For example, two consecutive blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0124] The various embodiments of the present invention have been described above. These descriptions are exemplary and not exhaustive, nor are they limited to the disclosed embodiments. Many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the described embodiments. The terminology used herein is chosen to best explain the principles, practical application, or improvement of the technology in the market, or to enable others skilled in the art to understand the embodiments disclosed herein.

Claims

1. A cross-version knowledge graph consistency maintenance method based on ontology semantic difference, characterized in that, Includes the following steps: S1. Input the old ontology and the new ontology, and perform syntactic difference and semantic inference in sequence to generate a set of difference results with semantic labels containing multiple types of atomic operations; S2. Construct a change transaction graph based on the differential result set. The change transaction graph includes a dependent directed acyclic graph, an executable compensation mapping, and a set of mutual exclusions. A deterministic topological sort is performed on the dependent directed acyclic graph to obtain the execution sequence. In the temporary storage environment, the schema change, data migration, query rewriting, and constraint verification nodes are executed sequentially according to the execution sequence. If the execution fails, a compensation operation is triggered in reverse order to block version submission. S3. Generate a version record for each committed version that includes a pattern hash, a data hash, a version routing hash, and an association with the parent version; for merged versions, calculate the nearest common ancestor and generate a complete merge increment from the nearest common ancestor to the merged version, ensuring that the reconstruction path of the merged version is unique; S4. Rewrite and adapt the registered SPARQL queries, and divide the query equivalence into two levels: static proof equivalence and runtime proof equivalence. Only when the corresponding equivalence judgment conditions are met will the query rewriting and route switching be completed automatically. If the conditions are not met, the structured minimum manual confirmation items will be output to block automatic submission. S5. Adopting the closed-world assumption, constraint verification is performed on the specified data snapshot based on the shape constraint language; the verification node is divided into the blocking submission level and the recording alarm level. When the blocking submission level verification fails, the compensation process is triggered.

2. The cross-version knowledge graph consistency maintenance method based on ontology semantic difference driven according to claim 1, characterized in that, The syntax difference mentioned in step S1 is specifically as follows: take the set difference of the resource description framework triples set of the old ontology and the new ontology to obtain the added set and the deleted set; The semantic inference specifically involves: for the candidate old classes in the deletion set, searching for the candidate new class set in the addition set, and making a joint judgment using three indicators: label edit distance, neighbor structure Jaccard similarity, and instance coverage, to distinguish between renaming, splitting, merging, and independent deletion / addition operation types.

3. The cross-version knowledge graph consistency maintenance method based on ontology semantic difference driven according to claim 2, characterized in that, The tag edit distance is a normalized edit distance, calculated using the following formula: in, Two strings and Lewinstein distance, , These are the character lengths of the two strings, respectively. The formula for calculating the neighbor structure Jaccard similarity is as follows: in, As a candidate old class, As a candidate new class, For class The set of Uniform Resource Identifiers for the objects of directly related relation type triples; The instance coverage rate is the proportion of the intersection of the set of instances of the old class and the set of instances of the new class to the old instance set.

4. The cross-version knowledge graph consistency maintenance method based on ontology semantic difference driven by claim 1, characterized in that, The deterministic topological sorting in step S2 specifically involves: performing a topological sort on the dependent directed acyclic graph, and in each step selecting the node with the smallest lexicographical order from the nodes with an in-degree of 0, thereby generating a unique execution sequence; The compensation operation is specifically as follows: establish a compensation mapping for each strictly reversible node; when execution fails, perform idempotent compensation operation in reverse order of completed nodes to restore the temporary state to the state before execution; nodes that do not meet the strictly reversible condition are marked as having no compensation guarantee and the automatic submission path is blocked.

5. The cross-version knowledge graph consistency maintenance method based on ontology semantic difference driven according to claim 1, characterized in that, Step S2 also includes an audit freeze mechanism: before the data migration node is executed, the original data before migration is written into the audit naming graph that is uniquely bound to the current change transaction graph; after all data nodes are executed, the audit naming graph is frozen and the normalized hash value is calculated; all verification nodes that reference the audit graph have the audit freeze event as a prerequisite.

6. The cross-version knowledge graph consistency maintenance method based on ontology semantic difference driven according to claim 1, characterized in that, The version record mentioned in step S3 is divided into four groups of fields: Group A consists of required fields for all committed versions, including version identifier, schema version hash, data version hash, route version hash, commit sequence number, branch identifier, parent version identifier list, effective time, and expiration time. Group B consists of fields that are not required for the initial version, including the change transaction graph identifier, mapping rule version hash, logical deletion triple set, recent snapshot reference, incremental reference, and replay mode. C is a required field for merging versions, including the most recent common ancestor version identifier and the merging increment reference; Group D contains all audit fields that are required for non-initial versions, including audit graph references and audit graph hashes.

7. The cross-version knowledge graph consistency maintenance method based on ontology semantic difference driven according to claim 1, characterized in that, The rebuild process for the merged version in step S3 is as follows: S31. Based on the nearest common ancestor version identifier in the merged version record, load the complete knowledge graph snapshot of the corresponding version; S32. Apply the merged increment to the nearest common ancestor snapshot to obtain the merged knowledge graph state; S33. Calculate the normalized hash values ​​of the merged ontology schema and instance data respectively, and compare them with the schema version hash and data version hash in the version record; if they match, the reconstruction is confirmed to be valid, otherwise the reconstruction is rejected and an alarm is issued.

8. The cross-version knowledge graph consistency maintenance method based on ontology semantic difference as described in claim 1, characterized in that, The static proof of equivalence in step S4 refers to proving the semantic equivalence of queries before and after rewriting based solely on the ontology schema structure; the runtime proof of equivalence refers to confirming the equivalence of query result sets before and after rewriting under variable mapping through runtime data verification. The runtime proof of equivalence in the attribute splitting scenario must satisfy the following: all old attribute values ​​are successfully split, the value level coverage is 1.0, the merged value after splitting is conserved from the original value, and all query operations are within the preset whitelist range.

9. The cross-version knowledge graph consistency maintenance method based on ontology semantic difference as described in claim 1, characterized in that, The closed-world assumption mentioned in step S5 specifically means that attributes or instances that do not appear explicitly in the target data graph are treated as not satisfying constraints; open-world reasoning is not used by default to complete missing values. The severity levels of the verification nodes are divided into errors and warnings. When an error-level verification fails, the submission is blocked and compensation is triggered. When a warning-level verification fails, diagnostic information is recorded and subsequent execution continues.

10. A cross-version knowledge graph consistency maintenance system driven by ontology semantic difference, characterized in that, include: The ontology semantic difference calculation engine module is used to take the old ontology and the new ontology as input, perform syntax difference and semantic inference in sequence, and generate a set of difference results with semantic labels containing multiple types of atomic operations; The change transaction graph construction and execution module is used to construct a change transaction graph from the difference result set. The change transaction graph includes a dependent directed acyclic graph, an executable compensation mapping, and a set of mutual exclusions. A deterministic topological sort is performed on the dependent directed acyclic graph to obtain the execution sequence. In the temporary storage environment, the schema change, data migration, query rewriting, and constraint verification nodes are executed sequentially according to the execution sequence. If the execution fails, a compensation operation is triggered in reverse order to block version submission. The multidimensional version identification and storage model module is used to generate a version record for each committed version, which includes a pattern hash, a data hash, a version routing hash, and an association with the parent version. For merged versions, the least common ancestor is calculated and a complete merge increment from the least common ancestor to the merged version is generated, ensuring that the reconstruction path of the merged version is unique. The query rewriting module is used to rewrite and adapt registered SPARQL queries, classifying query equivalence into two levels: static proof equivalence and runtime proof equivalence. It automatically completes query rewriting and route switching only when the corresponding equivalence judgment conditions are met; otherwise, it outputs a minimal structured manual confirmation item and blocks automatic submission. The SHACL verification module is used to perform constraint verification on a specified data snapshot based on the closed-world assumption and shape constraint language. The verification nodes are divided into blocking submission level and recording alarm level. When the blocking submission level verification fails, the compensation process is triggered.

Images