An ontology version management-based knowledge graph dynamic evolution and digital thread tracing system and method

Abstract

This invention discloses a knowledge graph dynamic evolution and digital thread tracing system and method based on ontology version management, comprising: an ontology version manager for versioned management of the ontology and storage of multiple historical versions; an instance-version binder for associating instances with the ontology version at the time of generation and generating a mapping index; an evolution proposal generator for analyzing external events or domain knowledge changes and automatically generating evolution proposals containing the changed content; an evolution executor for responding to confirmation commands, creating a new version based on the changed content, and migrating instances associated with the old version according to the mapping index to make them compatible with the new version; and a digital thread tracing engine for responding to time parameter queries and tracing back the knowledge graph state at a specified time point based on historical versions and mapping indexes. This invention realizes dynamic evolution of the knowledge graph and full lifecycle digital thread tracing, supports historical state backtracking, ensures data compatibility, and meets the needs of long-term knowledge management.

Description

Technical Field

[0001] This invention belongs to the fields of knowledge graph, ontology engineering and digital thread technology, and in particular relates to a knowledge graph dynamic evolution and digital thread tracing system and method based on ontology version management. Background Technology

[0002] With the deepening application of knowledge graph technology in complex fields such as aerospace and manufacturing, knowledge is no longer static but continuously evolves with the processes of model development, test flights, and operation and maintenance. For example, the design specifications of aerospace engines will be updated, new cases will be added to the failure mode database, and material performance data will be revised. These changes require knowledge graphs to have the ability to evolve dynamically.

[0003] The existing technology has the following main problems: First, traditional knowledge graph construction methods treat ontologies as static models, which are rarely modified once built. When domain knowledge changes, it is often necessary to rebuild the entire knowledge graph, which is costly, inefficient, and cannot retain historical version information.

[0004] Second, in the development of long-lifecycle products such as aerospace products, it is necessary to trace the design status, test data, and failure cases at different points in time, i.e., "digital thread" tracing. For example, it is necessary to query "the design parameters of this engine model before March 2025" or "the inspection data of this component during the last major overhaul". Existing knowledge graph systems lack the ability to manage versions of historical states and cannot support backtracking queries by timestamp.

[0005] Third, there are complex dependencies between ontology evolution and instance data. Maintaining compatibility between existing instance data and the new ontology when the ontology is updated (e.g., adding a new class or modifying attribute definitions) is a technical challenge. Existing solutions either force an update to all instances or abandon the use of the new ontology, lacking a flexible collaborative evolution mechanism.

[0006] Fourth, existing ontology version management tools (such as the version control that comes with Protégé) are mainly focused on the editing history of the ontology, and cannot be linked with the evolution of knowledge graph instances, let alone support version-based digital thread tracing. Summary of the Invention

[0007] To address the aforementioned technical problems, this invention proposes a knowledge graph dynamic evolution and digital thread tracing system and method based on ontology version management, thereby resolving the issues existing in the prior art.

[0008] To achieve the above objectives, this invention provides a knowledge graph dynamic evolution and digital thread tracing system based on ontology version management, comprising: The ontology version manager is used to manage the versioning of the ontology of the knowledge graph, and to record and store multiple historical versions of the ontology. The instance-version binder is used to associate and bind instance data in the knowledge graph with the ontology version on which it was generated and to generate an instance-version mapping index. An evolution proposal generator is used to analyze changes in external events or domain knowledge and automatically generate ontology evolution proposals that include suggested changes to the ontology. An evolution executor is used to respond to the confirmation instruction for the ontology evolution proposal, create a new version through the ontology version manager according to the proposed changes, and perform migration operations on instances associated with the old version according to the instance-version mapping index, so that the migrated instances are compatible with the new version; The digital thread tracing engine is used to respond to query requests containing time parameters. Based on the historical version of the ontology and the instance-version mapping index, it determines the target ontology version and the target instance version corresponding to the time parameter, and traces back and returns the knowledge graph status at the specified historical time point.

[0009] Optionally, the ontology version manager assigns a globally unique version number that follows the semantic versioning specification to each ontology version, stores the complete ontology file and records the difference patches with the previous version, and maintains version metadata and the evolution relationship and branch information between versions.

[0010] Optionally, the instance-version binder uses a multi-version concurrency control mechanism to maintain multiple historical versions of the instance. When creating a new instance, the currently effective ontology version number is recorded as a version attribute in the instance. When the instance is modified, the original instance copy is retained and a new instance associated with the new version number is created. An instance-version mapping index table is constructed with the instance identifier and version number as keys and the instance storage location as values.

[0011] Optionally, the evolution proposal generator includes: An event detector is used to subscribe to and parse external events or domain knowledge in real time from an event queue; The pattern matcher is used to match the parsed event information with the existing classes, attributes and rules of the ontology, identify the associated ontology elements and send them to the frequency counter. A frequency counter is used to count the frequency of occurrence of similar events or similar knowledge using a sliding window counter. An evolution rule learner is used to determine whether the ontology needs to be evolved based on the current ontology structure and event characteristics when the occurrence frequency meets preset conditions, and to generate a structured evolution proposal containing suggested changes, a list of triggering events, and an impact analysis when the determination result is that evolution is required.

[0012] Optionally, the evolution rule learner is constructed using a meta-learning algorithm, which is trained based on a historical evolution case library and is used to predict the ontology elements that need to be updated based on the current ontology structure and event features.

[0013] Optionally, the evolutionary actuator includes: The expert confirmation interface is used to visually display the ontology evolution proposal, receive operations from domain experts, and trigger the ontology update process after expert confirmation. The instance migration engine is used to parse the differences between the new version and the old version of the ontology and generate a difference mapping rule table after the ontology update process is triggered. It then filters out the instances that need to be migrated according to the instance-version mapping index, performs batch conversion on the instances that need to be migrated according to the difference mapping rule table, marks the instances that cannot be automatically converted, and generates a migration report.

[0014] Optionally, the instance migration engine supports online migration mode and offline migration mode. In online migration mode, instances are migrated in batches and indexes are updated in real time. In offline migration mode, all instances are migrated at once after system writes are paused. The migration process uses a two-phase commit protocol to ensure data consistency.

[0015] Optionally, the digital thread tracing engine supports at least one of the following query types: Time point query is used to determine the ontology version corresponding to a single entity identifier and a specified timestamp by querying the version time index, and to obtain the historical state of the entity under the ontology version by combining the instance-version mapping index. The time interval query is used to traverse the instance-version mapping index based on a single entity identifier and a specified time interval to obtain all versions of the entity and their corresponding ontology structure within the specified time interval, and return the evolution history of the entity. The association traceability query is used to query the evolution history of two entities within a specified time interval based on their identifiers and time intervals, determine the relationship status between them at each point in time, and return the relationship evolution history.

[0016] Optionally, a consistency checker is also included, which is used to perform logical consistency checks on the new version of the ontology, perform sampling compatibility checks on the migrated instance data, perform sampling verification on the digital thread tracing path, generate a consistency check report, and trigger an alarm when a problem is found after the evolution executor completes the creation of the new version of the ontology and the migration of the instance.

[0017] This invention also provides a method for dynamic evolution and digital thread tracing of knowledge graphs based on ontology version management, using the above-mentioned system, comprising: The ontology version manager is used to manage the versioning of the ontology of the knowledge graph, and to record and store multiple historical versions of the ontology. The instance-version binder associates and binds instance data in the knowledge graph with the ontology version on which it was generated, and generates an instance-version mapping index. The evolution proposal generator analyzes changes in external events or domain knowledge and automatically generates ontology evolution proposals that include suggested changes to the ontology. The evolution executor responds to the confirmation instruction of the ontology evolution proposal, creates a new version of the ontology through the ontology version manager according to the proposed changes, and performs a migration operation on the instance data associated with the old version of the ontology according to the instance-version mapping index, so that the migrated instance data is compatible with the new version of the ontology. The digital thread tracing engine responds to query requests containing time parameters, determines the target ontology version and target instance version corresponding to the time parameter based on the ontology historical versions stored in the ontology version manager and the instance-version mapping index generated by the instance-version binder, and traces back and returns the knowledge graph status at the specified historical time point.

[0018] Compared with the prior art, the present invention has the following advantages and technical effects: (1) Sustainable Knowledge Evolution: By automatically detecting knowledge change requirements through an evolutionary rule learner based on a meta-learning framework, generating ontology evolution proposals, and combining expert confirmation mechanisms and instance transfer engines, the knowledge graph is intelligently and semi-automatically updated dynamically, always maintaining the latest and accurate information. Compared with solutions that rely entirely on manual labor or are completely automated and uncontrollable, this invention ensures the accuracy of evolution while reducing manual maintenance costs, enabling the knowledge base to continuously evolve with the development progress of the model, always maintaining the latest and accurate information.

[0019] (2) Digital thread traceability: Each instance data is associated with the ontology version at the time of generation through the instance-version binding mechanism, and a multi-version concurrency control (MVCC) index is established to support precise time point query, time interval query and associated traceability, so as to realize complete traceability of product life cycle data. In the scenario of zeroing out aerospace model failures, engineers can quickly locate historical design status, test data and failure cases, providing complete and reliable data support for decision-making.

[0020] (3) Controllable evolution process: By highlighting differences in the expert-confirmed interface and conducting impact analysis simulations, every change to the ontology is fully reviewed to avoid erroneous evolution; data compatibility is ensured through the automatic conversion and manual labeling mechanism of the instance migration engine. Experiments show that this mechanism can reduce the data error rate caused by ontology evolution by more than 90%.

[0021] (4) Historical status is traceable: Through version time indexing and efficient querying of B+ tree structure, it supports millisecond-level historical status retrieval. In a knowledge graph containing tens of millions of instances, the response time for a single time point query does not exceed 200ms, providing strong support for scenarios with high real-time requirements such as fault zeroing and design change analysis.

[0022] (5) Strong compliance: The complete evolution audit log records detailed information on all evolution operations (time, operator, changes, and approval opinions), meeting the quality system and audit requirements of aerospace, military and other fields. Attached Figure Description

[0023] The accompanying drawings, which form part of this application, are used to provide a further understanding of this application. The illustrative embodiments and descriptions of this application are used to explain this application and do not constitute an undue limitation of this application. In the drawings: Figure 1 This is a diagram of the dynamic evolution architecture of the knowledge graph based on ontology version management, according to an embodiment of the present invention. Figure 2 This is a schematic diagram of the data structure of the ontology version manager according to an embodiment of the present invention; Figure 3 This is a flowchart illustrating the evolution proposal generation and confirmation process according to an embodiment of the present invention. Figure 4 This is a schematic diagram of the query interface of the digital thread tracing engine according to an embodiment of the present invention; Figure 5 This is an example diagram illustrating the application of this invention in the evolution of a fault case library. Detailed Implementation

[0024] It should be noted that, unless otherwise specified, the embodiments and features described in this application can be combined with each other. This application will now be described in detail with reference to the accompanying drawings and embodiments.

[0025] It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions, and although a logical order is shown in the flowchart, in some cases the steps shown or described may be executed in a different order than that shown here.

[0026] Example 1 like Figure 1 As shown, this embodiment provides a knowledge graph dynamic evolution and digital thread tracing system based on ontology version management, including: 1. Ontology Version Manager: Used for versioned management of the OWL ontology, recording change information for each version, specifically including: 1) Objects to be processed: OWL ontology files (RDF / XML format), ontology metadata, and version change information.

[0027] 2) Processing steps: Step 1: When an ontology creation or update instruction is received, parse the ontology file content.

[0028] Step 2: Generate a globally unique version number (e.g., v1.0.0, v2.0.0), with the format following the semantic versioning specification (major version number.minor version number.revision number).

[0029] Step 3: Store the complete ontology file in the versions / directory, with the file name formatted as "version number.owl".

[0030] Step 4: Calculate the differences from the previous version, generate a difference patch file, and store it in the diff / directory.

[0031] Step 5: Extract version metadata (creation time, author, change description, tags) and write it to the metadata.json file. metadata.json provides centralized storage for version metadata for the entire system, supporting the operation of multiple modules such as traceability, auditing, and verification.

[0032] Step 6: Update the index.json file to maintain the dependency relationships and branch information between versions.

[0033] The update steps are as follows: (1) Parse new version information: When the ontology version manager creates a new version (e.g., v1.1), it first obtains the metadata of the version, including version number, parent version number (if it exists), creation time, branch identifier, etc.

[0034] (2) Read the current index.json: Read the existing index.json file from storage and parse it into a version relationship graph structure in memory.

[0035] (3) Add a new version node: Add a new node to the relationship graph. The node attributes contain complete information about the new version (version number, parent version, creation time, etc.).

[0036] (4) Update the father-son relationship: If a new version has a parent version (e.g., v1.1's parent version is v1.0), then a parent-child connection is established in the graph.

[0037] If a parent version has multiple child versions (e.g., multiple branches evolve from the same baseline), then update the list of children for the parent version.

[0038] (5) Processing branch information: If the new version belongs to a new branch (such as the "fault case branch"), the starting version and branch name of the branch need to be recorded in index.json.

[0039] (6) Serialize back to file: Reserialize the updated version relationship graph into JSON format and write it back to the index.json file atomically (usually write it to a temporary file first and then replace it to prevent data corruption due to crash).

[0040] (7) Concurrency control: If multiple operations modify index.json at the same time, file locks or database transactions (if stored in a database) should be used to ensure consistency.

[0041] 3) Technical means: It adopts a Git-like storage structure, but is customized to suit the characteristics of the OWL ontology and the needs of knowledge graph evolution. The versions / directory stores the complete ontology files, ensuring that each version can be independently traced back; the diff / directory records the differences between adjacent versions, saving storage space while maintaining traceability; index.json not only maintains version dependencies, but also supports parallel evolution branches (such as design baseline branches and failure case branches), which is an extension of the Git branching model to adapt to the multi-line parallel knowledge evolution needs of the aerospace field.

[0042] 4) Data flow direction: Version information is provided to other modules via API interfaces, including the evolution proposal generator (used to determine whether an update is needed), the digital thread tracing engine (used to query historical states), and the consistency checker (used to verify logical consistency).

[0043] 5) Processing results: A structured version control system, containing complete ontology files, diff patches, metadata, and version relationship graphs.

[0044] 2. Instance-Version Binder: This binds each instance data in the knowledge graph to the ontology version on which the instance was generated. Specifically, it includes: 1) Processing object: Knowledge graph instance data (stored in the form of RDF triples or attribute graphs).

[0045] 2) Processing steps: Step 1: When creating a new instance, obtain the currently active ontology version number.

[0046] Step 2: Add a version attribute to the instance node to record the version number of the entity at the time of creation.

[0047] Step 3: When an instance is modified, retain the original instance as a copy of the historical version, create a new instance and associate it with the new ontology version number.

[0048] Step 4: Build an instance-version mapping index table and store it in a high-performance key-value database (such as Redis). The key is "instance ID + version number" and the value is the instance storage location.

[0049] Step 5: Regularly compress and optimize the index table, and delete expired references.

[0050] 3) Technical means: A dual-write strategy is employed to preserve historical versions: each time an instance is updated, the original instance is first copied to the historical storage area, and then the primary instance is updated. The index table is organized using an LSM tree structure, supporting high-throughput writes and fast point queries.

[0051] 4) Data flow direction: The instance-version mapping index provides the digital thread tracing engine with fast location capabilities; at the same time, during instance migration, this index is used to identify instances that need to be migrated.

[0052] 5) Processing results: Each instance has a version tag, which allows for quick querying of the instance status under a specific version via an index.

[0053] 3. Evolution proposal generator: This function automatically detects whether the ontology needs to be updated and generates an evolution proposal when new event data is accessed or domain knowledge changes. 1) Processing objects: Multi-source event stream data (such as new fault case JSON, design change notification XML, test report text).

[0054] 2) Processing steps: Step 1 (Event Detection): Subscribe to the event queue in real time through a Kafka consumer to parse the event type and content.

[0055] Step 2 (Pattern Matching): Match key information in the event (such as fault symptoms, design parameters) with existing classes, attributes, and rules in the ontology. A rule-based pattern matching algorithm is used, with a predefined matching rule library.

[0056] Step 3 (Frequency Statistics): Use a sliding window counter to count the frequency of similar events. The window size can be configured according to the characteristics of the field (for example, the window for aerospace engine failure cases is set to 30 days).

[0057] Step 4 (Evolution Judgment): Invoke the evolution rule learner and determine whether evolution is needed based on the meta-learning framework. Extract metadata (such as change descriptions) of historical versions from metadata.json as a reference to analyze the knowledge evolution trend. The evolution rule learner adopts the MAML (Model-Agnostic Meta-Learning) algorithm. The training task is "predict the ontology elements that need to be updated based on the current ontology structure and new event features". The training data comes from the historical evolution case library.

[0058] Step 5 (Proposal Generation): When the judgment result is "Evolution Required", a structured evolution proposal is generated, including: a) Proposal ID (UUID format), generation timestamp, and list of triggered events (including event ID, type, and time); b) Suggested changes: Add a new class BearingWear_V2, a new data attribute hasWearLevel (xsd:float type), a new object attribute causeBy (domain FaultMode, value range CauseFactor), and a new SWRL rule R12 (the 12th rule). Rules: Numerical numbers are used to uniquely identify rules for easy management and referencing; this is common in rule bases. The meaning of the name BearingWear_V2 is: class name, representing the second version of "bearing wear" (V2 may represent Version 2, as version V1 may already exist in the ontology evolution). Naming convention: CamelCase is used, with the suffix _V2 explicitly indicating version iteration for easy knowledge evolution tracking.

[0059] hasWearLevel: Meaning: Data attribute representing "wear level", data type is xsd:float (floating-point number).

[0060] Rule: Data attribute, representing "wear level", data type is xsd:float (floating-point number).

[0061] causedBy: Meaning: An object property that indicates "caused by", with the domain FaultMode and the value range CauseFactor.

[0062] Rule: Attribute names directly describe the relationship, conform to natural language habits, and are easy to understand and reason about.

[0063] c) Example of changes: Demonstrating the application of the new class in an instance using Turtle syntax; d) Impact analysis: Query the instance-version mapping index to count the number and type distribution of potentially affected instances; Step 6: Write the proposal into the evolution proposal queue and wait for expert confirmation.

[0064] 3) Technical means: (1) Event detection uses Apache Kafka message queue, which supports high throughput and low latency real-time data access.

[0065] (2) Pattern matching uses the Rete algorithm to efficiently match events with existing patterns of the ontology.

[0066] (3) Frequency statistics use a sliding window counter, and the window size can be dynamically adjusted.

[0067] (4) The evolution judgment adopts the meta-learning framework MAML. Its core principle is to train a meta-model on a large number of historical evolution cases so that the model can quickly adapt to new evolution tasks and generate high-quality evolution suggestions with only a small number of gradient updates.

[0068] 4) Data flow: The evolution proposal generator receives data from the event stream, outputs structured proposals to the expert confirmation interface, and writes the proposals to the audit log.

[0069] 5) Processing results: The structured evolution proposal (JSON format) can be directly displayed and edited in the expert confirmation interface.

[0070] 4. Expert verification and executor, providing a visual interface for domain experts to review evolution proposals: 1) Processing object: Structured proposals output by the evolution proposal generator.

[0071] 2) Processing steps: Step 1: Retrieve the proposals to be confirmed from the evolution proposal queue and render them to the web interface.

[0072] Step 2: Display the current ontology structure (class hierarchy, attribute definitions, rule list) in a tree structure on the left side of the interface.

[0073] Step 3: Display the change suggestions in a comparison view on the right side of the interface. Use a difference highlighting algorithm to mark the added, modified, and deleted elements. The comparison view extracts and displays the metadata information of the historical versions from metadata.json for decision-making.

[0074] Step 4: Call the Instance Migration Engine's Impact Analysis API to simulate the impact of the changes on existing instances. The "Potentially Affected Instances" and "Instances Required to be Migrated" will be displayed in a list at the bottom of the interface.

[0075] Step 5: Experts can choose to operate as follows: a) Confirmation: Submit a confirmation command to trigger the ontology update process.

[0076] b) Modify: Modify the proposal content through the interface editor and regenerate the proposal.

[0077] c) Reject: Fill in the reason for rejection, and the proposal will be added to the pending list.

[0078] d) Delay: Set a delay period, and remind again after the expiration.

[0079] Step 6: Write the expert's operation results into the evolution audit log.

[0080] 3) Technical means: (1) The Web interface adopts the React+Ant Design framework, which supports real-time interaction and data visualization.

[0081] (2) The difference highlighting uses the Myers difference algorithm to calculate the minimum edit distance between two ontology versions.

[0082] (3) Impact analysis calls the graph database query to count the number of instances that match a specific pattern (such as a specific class or a specific attribute).

[0083] 4) Data flow: Receive evolution proposals, send confirmation instructions to the ontology version manager, send migration requests to the instance migration engine, and write operation records to the audit log.

[0084] 5) Processing results: Confirmed proposals trigger the ontology update process; proposals that are modified / rejected / suspended are marked with the corresponding status.

[0085] 5. Instance migration engine, used to perform instance migration when an Ontology version upgrade causes existing instances to become incompatible with the new Ontology: 1) Targets to be processed: old version instance data and mapping rules for differences between old and new versions of the ontology.

[0086] 2) Processing steps: Step 1: Analyze the differences between the old and new versions of the system and generate a difference mapping rule table. The rule table includes: a) Class mapping: TurboPumpFault → BearingWear (subclassing); b) Attribute mapping: hasVibrationLevel → hasVibrationRMS (name change); c) Value mapping: Old attribute value "high" → New attribute value 15.0 (threshold conversion); d) New rule: Instances must meet the hasTemperatureAnomaly condition; Step 2: Query the instance-version mapping index to filter out all instances that need to be migrated (i.e., instances whose version number is equal to the old version).

[0087] Step 3: Transform instance data row by row according to the difference mapping rule table. The transformation process is executed within a transaction to ensure data consistency.

[0088] Step 4: For instances that cannot be automatically converted (e.g., missing necessary attributes), mark them as MIGRATION_PENDING and generate a migration report.

[0089] Step 5: Perform batch migration, supporting two modes: a) Online migration: The system does not shut down, and the migration is carried out in batches of 1,000 records each. After the migration is completed, the index is updated.

[0090] b) Offline migration: The system pauses write operations and migrates all instances at once.

[0091] Step 6: Generate a migration report, including the total number of instances, the number of successful instances, the number of failed instances, the number of instances requiring manual intervention, and details of the failures.

[0092] Step 7: Bind the migrated instance to the new version v2.0, while retaining a snapshot of the old version instance (identified by the version attribute).

[0093] 3) Technical means: (1) The difference mapping rule table is described using DSL (Domain Specific Language), which is convenient for expansion and maintenance.

[0094] (2) Batch migration adopts the producer-consumer model and multi-threaded concurrent execution to improve migration efficiency.

[0095] (3) The transaction management adopts a two-phase commit protocol to ensure the atomicity and consistency of migration.

[0096] 4) Data flow: Receive migration requests from the expert confirmation module, read instance data from the graph database, write the migrated instance to the graph database, and write a migration report to the audit log.

[0097] 5) Processing result: The migrated instance data is compatible with the new version of the ontology.

[0098] 6. Digital thread tracing engine, used to provide the ability to query historical status by timestamp: 1) Objects processed: ontology version repository, instance-version mapping index, graph database.

[0099] 2) Processing steps: Step 1: Receive the query request and parse the query type and time parameters.

[0100] Step 2: Quickly retrieve basic information (such as version number, creation time, author, etc.) of the corresponding version from metadata.json based on the query type, and use it to display to users or participate in traceability logic, and perform corresponding processing: (1) Time point query: GET / entity / {id}?timestamp=2025-03-01T00:00:00Z (The query interface example in the document follows the RESTful API design style and is usually used for HTTP-based web services (such as Java Spring Boot, Python Flask / Django and other frameworks). Method: GET (HTTP request method, used to obtain resources) Path: / entity / {id} – {id} is the entity's unique identifier (placeholder), such as engine model JD2-002. Parameter: timestamp – timestamp in ISO 8601 format, specifying the historical moment of the query; Function: Returns the complete state of the entity at the specified time point (including the ontology version and instance data at that time). Return: Entity state in JSON format).

[0101] a) Determine the ontology version number that was in effect at that time based on the timestamp (by querying the version time index).

[0102] b) Locate the instance in the instance-version mapping index at the specified version number.

[0103] c) Read the historical version instance data from the graph database.

[0104] d) Align the instance data with the ontology structure in effect at that time and return the complete state.

[0105] (2) Time interval query: GET / entity / {id} / history?from=2025-01-01&to=2025-12-31; (Method: GET; Path: / entity / {id} / history; Parameters: from – start time (ISO 8601) to – end time (ISO 8601); Function: Returns all versions of the entity within the specified time interval and its corresponding ontology structure, i.e., evolution history; Return: JSON array, containing entity snapshots and change descriptions at each time point).

[0106] a) Traverse the instance-version mapping index to obtain all versions of the instance within the time interval.

[0107] b) For each version, query the ontology structure at the corresponding point in time.

[0108] c) Return the evolution history of the instance (timeline, version status, change notes).

[0109] (3) Relationship tracing query: GET / relationship / {source} / {target}?from=2025-01-01&to=2025-12-31; (Method: GET; Path: / relationship / {source} / {target} – {source} and {target} are the identifiers of the two entities respectively; Parameters: from, to (same as above); Function: Query the evolution history of the relationship between two entities within a specified time interval (such as the time points of relationship establishment, change, and termination); Return: JSON object, containing the timeline of the relationship and the relationship status at each time point. Note: The above interface design follows the REST principle. {id}, {source}, and {target} in the path are variables and need to be replaced with specific values ​​in the actual request. The time format adopts ISO8601 (such as 2025-03-01T00:00:00Z, which means 0:00 UTC on March 1, 2025). This type of interface can be implemented in Spring Boot through the @RestController and @GetMapping annotations, and in Flask This can be achieved using `@app.route`. a) Query the evolution history of the two entities within the time interval.

[0110] b) At each point in time, check whether there is a relationship between the two.

[0111] c returns the history of the relationship's evolution (the time points when the relationship was established, changed, or terminated).

[0112] Step 3: Post-process the query results, including data format conversion and supplementation of related data.

[0113] Step 4: Return the query results, along with metadata about the traceability path (version number, timestamp, confidence level).

[0114] 3) Technical means: (1) The timestamp parsing adopts the ISO 8601 standard format.

[0115] (2) The version time index is stored in a B+ tree structure, which supports efficient range queries.

[0116] (3) Historical data queries adopt a multi-version concurrency control (MVCC) mechanism to ensure data consistency.

[0117] 4) Data flow: Receive RESTful API requests, query data from the version control system and index, and return the results to the client.

[0118] 5) Processing results: Query results in JSON format, including the historical status of the entity and the tracing path.

[0119] 7. Consistency checker, used to automatically perform consistency checks after each evolution: 1) Targets to be processed: New version of the entity, migrated instance data, and digital thread tracing path.

[0120] 2) Processing steps: Step 1: Call the OWL inference engine (such as Pellet) to perform a logical consistency check on the new version of the ontology, detecting class definition conflicts, attribute field / value field conflicts, disjoint class conflicts, etc. Verify the integrity of the version metadata, for example, confirm that each version has a corresponding medadata.json metadata record.

[0121] Step 2: Randomly sample 5% of the instances and check whether they meet the constraints of the new ontology (such as whether the required attributes exist, whether the attribute value types are correct, and whether the relationship integrity is satisfied).

[0122] Step 3: Randomly select 10 historical tracing paths to verify whether they can correctly return the historical status (including time point query and version query).

[0123] Step 4: Check the integrity of the evolution audit log to ensure that each evolution operation has a corresponding version change metadata.json record to meet compliance requirements.

[0124] Step 5: Generate a consistency verification report, including check items, pass rate, and failure details.

[0125] Step 6: If a problem is found (such as contradictions in ontology logic or instance compatibility issues), trigger an alarm and notify the administrator.

[0126] 3) Technical means: (1) The ontology consistency check is implemented using the Tableau algorithm, which is the core algorithm for describing logical reasoning.

[0127] (2) Instance compatibility check uses pattern matching technology to compare instances with ontology constraints.

[0128] (3) The traceability path verification adopts a replay mechanism to simulate historical queries and compare the results.

[0129] 4) Data flow: Receive the evolution completion signal, read the ontology from the version repository, read the instance from the graph database, and send alarms to the monitoring system.

[0130] 5) Processing result: Consistency verification report (JSON format). If a problem is found, an alarm will be triggered.

[0131] This invention includes: (1) Ontology Version Manager: Responsible for the versioned storage and management of the OWL ontology. Each version contains complete ontology files, metadata, and change records. It adopts a Git-like customized storage structure and supports version rollback, difference comparison, and parallel evolution branches.

[0132] (2) Knowledge Graph Database: Stores instance data, with each instance associated with a specific ontology version through the version attribute. Supports graph databases (such as Neo4j) or triple databases (such as RDF4J).

[0133] (3) Evolution proposal generator: It receives external event streams in real time through Kafka and automatically generates ontology evolution proposals using a meta-learning framework.

[0134] (4) Expert confirmation interface: Provides a web-based visual interface for experts to review proposals, supporting difference comparison, impact analysis simulation and multiple operation options.

[0135] (5) Instance migration engine: Automatically performs instance data migration during ontology upgrades, supporting both online and offline modes.

[0136] (6) Digital thread tracing engine: provides RESTful API and graphical query interface, supports time point query, historical evolution query and correlation tracing.

[0137] (7) Consistency checker: Automatically performs ontology logic check, instance compatibility check and trace path verification after each evolution.

[0138] (8) Evolution audit log: Records all operations, including event access, proposal generation, expert confirmation, instance migration, version update, etc., to meet compliance audit requirements.

[0139] Specifically, the implementation of the ontology version manager is as follows: Figure 2 As shown.

[0140] The ontology version manager uses a Git-like custom storage structure, including the following entities: 1) Version: The core entity, containing the following attributes: (1) versionId: a globally unique version identifier, using semantic version numbers, such as "v2.0.0".

[0141] (2) createTime: Version creation timestamp, accurate to milliseconds.

[0142] (3) author: Creator identifier, which can be automatically generated by the system or manually entered by an expert.

[0143] (4) changeDescription: Change description text, which briefly describes the content of this update.

[0144] (5) parent: a reference to the parent version, forming a version evolution chain.

[0145] (6) children: A list of references to child versions, supporting multi-branch parallel evolution.

[0146] 2) OntologyFile: Each version is associated with a complete OWL file, stored in the versions / directory, and the file name format is "version number.owl".

[0147] 3) Metadata: Stores version metadata, including status (draft / released / deprecated), checksum (used for integrity verification), and tag list.

[0148] 4) Tag: Used to mark a specific version, such as "RELEASE_2026Q1" or "BASELINE_DESIGN".

[0149] 5) Branch: Supports parallel evolution of branches, such as the "design baseline branch" and the "failure case branch," which can evolve independently. Each branch points to a header version.

[0150] 6) Diff: Records the differences between adjacent versions, stored in the diff / directory. Patch files use a uniform diff format to describe the added, deleted, and modified classes, attributes, and rules.

[0151] The role of this data structure in the system: 1) By establishing a parent-child relationship for Version, a complete version evolution chain is constructed, providing a foundation for tracing digital threads. When performing a point-in-time query, the version at a specific point in time can be quickly located through the version chain.

[0152] 2) Diff records support quick calculation of changes between any two versions, highlighting the differences in the expert confirmation interface to help experts intuitively understand the impact of changes.

[0153] 3) The Branch mechanism supports the independent evolution of different knowledge domains. For example, the design specification library and the failure case library can be updated in parallel without interfering with each other, which enhances the flexibility and scalability of the system.

[0154] 4) The tag mechanism makes it easy to mark important versions, such as "first flight status" and "finalization status", which facilitates quick retrieval.

[0155] Specifically, the evolution proposal generation and confirmation process is as follows: Figure 3 As shown, the evolution process is as follows: (1) Event access: The event detector consumes event data from the Kafka queue, such as "new failure case", "design specification update", and "material data change". Each event is encapsulated in JSON format, including event type, timestamp, and detailed payload.

[0156] (2) Evolutionary Judgment: The evolutionary rule learner analyzes the events and determines whether the ontology needs to be updated. The specific algorithm is as follows: Step 1: Parse the event type and perform pattern matching with the existing fault mode library of the ontology.

[0157] Step 2: Use a sliding window counter (window size 30 days) to count the frequency of similar events.

[0158] Step 3: Call the meta-learning model, input the current ontology snapshot and event features, and output the probability value P of whether evolution is needed. If P > 0.7, then trigger the generation of an evolution proposal.

[0159] For example, if three consecutive "turbo pump vibration abnormality" events are received but there is no corresponding fault mode in the existing system, a "add fault mode" proposal is triggered. The threshold 3 is set based on the following: according to the fault statistics of a certain engine model over 10 years, when the same type of fault occurs three times in a row, there is a 92.3% probability that the fault mode has become a common phenomenon and needs to be included in the standard fault library.

[0160] (3) Proposal generation: The proposal generator generates structured evolutionary proposals, including: Proposal ID: Generated in UUID format, such as "550e8400-e29b-41d4-a716-446655440000"; Generation time: ISO 8601 format; Triggered event list: Event ID, Type, Timestamp; Suggested changes: Add a new class BearingWear_V2, add a new attribute hasWearLevel, and add a new rule [R12]TurboPump(?tp) ∧ hasVibration(?tp, ?v) ∧ greaterThan(?v, 15) →hasFault(?tp, "BearingWear_V2"); Example of change: Demonstrating the application of the new class in an instance using Turtle syntax; Impact analysis: It is estimated that 356 existing instances will be affected, of which 127 instances need to be migrated (due to attribute changes) and 3 instances require manual handling (due to missing data).

[0161] (4) Expert review: Experts log in to the system to view the proposal. The interface layout is as follows: Left side: Tree-like visualization of the current ontology structure, supporting expansion / collapse.

[0162] Right side: Comparison view of the proposed changes, with some new green highlights, some red markers removed, and some yellow markers modified.

[0163] Below: A list of impact analysis results, listing the potentially affected instance IDs, types, and impact levels (low / medium / high).

[0164] Bottom: Operation buttons (Confirm, Modify, Reject, Delay).

[0165] (5) Expert decision-making: Confirmation: When the expert clicks the "Confirm" button, the system automatically creates a new version (v2.0) and triggers the instance migration engine; Editing: Experts modify the proposal content in the editor, regenerate the proposal, and then submit it; Rejection: The expert fills in the reason for rejection, such as "This failure mode already has a similar definition", and the proposal is added to the pending list; Postponement: Experts can set a postponement period (e.g., 7 days), after which the system will remind them again.

[0166] (6) Execution Evolution: After confirmation, the ontology version manager creates a new version (such as v2.0) and triggers the instance migration engine.

[0167] Specifically, the query interface of the digital thread tracing engine is as follows: Figure 4 As shown.

[0168] The traceability engine provides a RESTful API and a graphical query interface: (1) API Example: GET / entity / {id}?timestamp=2025-03-01T00:00:00Z: Query the status of this entity on March 1, 2025.

[0169] GET / entity / {id} / history: Returns the complete evolution history of this entity.

[0170] GET / relationship / {source} / {target}?from=2025-01-01&to=2025-12-31: Query the changes in the relationship between two entities within a specified time interval.

[0171] (2) Graphical interface support: Timeline slider: Users drag the timeline slider below, and the knowledge graph snapshot at the corresponding time point is displayed in real time above.

[0172] Evolution Animation: Click the "Play" button to display the evolution process of entities and relationships in animation form, with adjustable speed.

[0173] Difference Highlighting: In the comparison view, the changes between different versions are highlighted, and you can hover the mouse over them to view the details of the changes.

[0174] This embodiment also provides a method for dynamic evolution of knowledge graphs and digital thread tracing based on ontology version management of the above system, including: The ontology version manager is used to manage the versioning of the ontology of the knowledge graph, and to record and store multiple historical versions of the ontology. The instance-version binder associates and binds instance data in the knowledge graph with the ontology version on which it was generated, and generates an instance-version mapping index. The evolution proposal generator analyzes changes in external events or domain knowledge and automatically generates ontology evolution proposals that include suggested changes to the ontology. The evolution executor responds to the confirmation instruction of the ontology evolution proposal, creates a new version of the ontology through the ontology version manager according to the proposed changes, and performs a migration operation on the instance data associated with the old version of the ontology according to the instance-version mapping index, so that the migrated instance data is compatible with the new version of the ontology. The digital thread tracing engine responds to query requests containing time parameters, determines the target ontology version and target instance version corresponding to the time parameter based on the ontology historical versions stored in the ontology version manager and the instance-version mapping index generated by the instance-version binder, and traces back and returns the knowledge graph status at the specified historical time point.

[0175] Taking the full life-cycle knowledge management of a certain type of liquid launch vehicle engine as an example, this invention fully demonstrates the collaborative working process of each module and illustrates its application in the design and evolution of aerospace engines.

[0176] The design of a certain type of liquid rocket engine went through multiple versions: (1) Initial state; In January 2024, the engine's initial design was completed, and the ontology version manager created baseline version v1.0, which included: Class definitions: Engine, TurboPump, CombustionChamber, Valve Attribute definitions: hasThrust, hasPressure, hasTemperature Example data: Engine design parameters (combustion chamber pressure 10MPa, turbopump speed 30000rpm).

[0177] (2) Event access and evolution proposal generation; In June 2024, the engine underwent its first test run, generating a large amount of test data. The event detector received the following events from the Kafka queue: Event E001: Test run was successful, but the combustion chamber pressure was detected to be slightly higher than the design value (10.3MPa vs 10MPa). Event E002: Turbine pump vibration data is normal 2; Event E003: The design department submitted a design change notice, proposing to adjust the combustion chamber pressure to 10.5 MPa; Evolutionary rule learner processing steps: Step 1: Pattern matching revealed that E003 belongs to the "Design Specification Update" type, which is related to the DesignSpec class in the ontology.

[0178] Step 2: The sliding window counter counts similar events. There have been 3 design changes in the past 30 days (including this event).

[0179] Step 3: The meta-learning model predicts P=0.89, which is greater than the threshold of 0.7, triggering the generation of evolutionary proposals.

[0180] The proposal generator outputs proposal P001: Changes: The default value of the hasPressure property of the CombustionChamber class has been changed from 10.0 to 10.5, and a new hasCoolingChannel property has been added to describe the cooling channel design.

[0181] Impact Analysis: In the existing examples, the design parameters of 3 engines need to be updated, and 1 of them requires manual processing due to the lack of cooling channel parameters.

[0182] (3) Expert confirmation and version upgrade; The chief designer logs into the expert confirmation interface and views proposal P001: The current ontology structure (v1.0) is displayed on the left. The right side displays suggested changes. Changes to the default value of hasPressure are highlighted in yellow, and newly added hasCoolingChannel is highlighted in green. The following lists three affected engines, two of which can be automatically relocated, while one requires manual adjustment of the cooling channel parameters. After the chief engineer reviews and approves, click "Confirm," and the system will execute: The ontology version manager creates a new version v1.1, and the complete ontology files are stored in versions / v1.1.owl; The metadata.json file records the following information: version number v1.1, creation time 2024-06-20, author "chief_engineer", and change description "adjusted combustion chamber pressure based on initial test data"; The index.json file has been updated to record that the parent version of v1.1 is v1.0.

[0183] (4) Instance migration; Instance migration engine execution: Read the difference mapping rules: change the default value of hasPressure from 10.0 to 10.5; Query the instance-version mapping index to find all engine instances (3 units) with version=v1.0. Automatically migrate 2 machines: Update their hasPressure value to 10.5; One device (JD2-003) was marked as MIGRATION_PENDING because it was missing the hasCoolingChannel parameter. Generate a migration report and notify the design department to supplement the data.

[0184] (5) Research and development and application of new materials (the birth of v2.0); 1) Event access; From January to February 2025, the materials R&D department completed the development of the new high-temperature alloy GH4720Li and passed multiple batches of material performance tests. The event detector receives the following events from the Kafka queue: Event M001 (January 15): The formulation of the new material GH4720Li has been finalized, and the performance indicators have met the standards (tensile strength, yield strength, creep performance). Event M002 (January 20): Material fatigue test completed, no cracks after 5000 cycles; Event M003 (February 5): The design department submitted a design change application, proposing to upgrade the turbine disk material from GH4169 to GH4720Li; Event M004 (February 10): Turbopump life simulation report updated, design life under new material conditions can be extended from 5000 seconds to 8000 seconds.

[0185] 2) Evolutionary judgment; Evolutionary rule learner processing steps: Step 1: Pattern matching revealed that M003 belongs to the "Design Change" type, which is related to the Material and DesignParameter classes of the ontology.

[0186] Step 2: Sliding window counter statistics show that there have been 5 design change discussions related to turbopumps in the past 60 days (including this one).

[0187] Step 3: The meta-learning model takes the current ontology snapshot (v1.1) and event features (material change, lifespan improvement) as input and outputs the evolution probability P=0.94, which exceeds the threshold of 0.7.

[0188] 3) Proposal generation; The proposal generator outputs proposal P003, which includes: Proposal ID: 7c8e9a0b-1d2e-3f4g-5h6i-7j8k9l0m1n2o; Generation time: 2025-02-11T10:30:00Z; Triggering events: M001, M002, M003, M004; Suggested changes: A new individual GH4720Li was added under the Material class, with the following attributes: Density: 8.2 g / cm³; hasTensileStrength: 1200 MPa; hasYieldStrength: 900 MPa; hasOperatingTemp: 800°C; Add an optional property hasMaterial to the TurboPump class, with a value pointing to the Material class; A new SWRL rule R20 has been added: TurboPump(?tp)∧hasMaterial(?tp, ?m)∧eq(?m, "GH4720Li") → hasDesignLife(?tp, 8000); This rule means that if a turbopump (?tp) has a material (hasMaterial) property, and that material is equal to the string "GH4720Li", then the turbopump's design life (hasDesignLife) is 8000 (usually in seconds or cycles). TurboPump(?tp) is a class assertion, where the variable ?tp is an instance of the TurboPump class. hasMaterial(?tp, ?m) is an object property, indicating that the turbopump ?tp has a material ?m, where ?m is an instance of the Material class. `eq(?m, "GH4720Li")` is a built-in predicate, a built-in function of SWRL, that determines whether the value of `?m` is equal to the string "GH4720Li" (typically used for data attribute comparison). `hasDesignLife(?tp, 8000)` is a data attribute conclusion, asserting that the design life of the turbine pump `?tp` is 8000.

[0189] Modify rule R12: In bearing wear diagnosis, increase the weight of material factors (bearings with new materials have longer lifespans, and the diagnostic threshold can be appropriately relaxed).

[0190] Example of a change: Format for demonstrating the application of new materials in a turbopump example Impact Analysis: The existing 24 engine turbopump instances will have a new hasMaterial attribute (requiring manual confirmation of material batch); among them, 8 engines that have been assembled need to be marked as "pending material traceability"; and 16 engines in production can directly apply the new material.

[0191] 4) Expert confirmation; On February 15, 2025, the chief designer logged in to the expert review panel to confirm the interface design proposal P003. The left side displays the current v1.1 structure, and the right side displays suggested changes: new material individuals, new attributes, and new rules. The impact analysis list provides a detailed view of the status of all 24 engines: Eight engines already installed (batch numbers: JD2-015 to JD2-022): require supplementary material traceability records; 16 engines in production (batch numbers: JD2-023 to JD2-038): new materials can be applied directly.

[0192] After the chief engineer reviewed and approved the changes, he clicked "Confirm" and added the following change instructions: "The new material GH4720Li has passed the material review and can be used in subsequent batches; the engines that have been installed maintain the original design, but the material differences need to be marked in the digital thread." 5) Version creation and migration; Ontology Version Manager creates a new version v2.0: The complete ontology file is stored in versions / v2.0.owl; metadata.json records: version number v2.0, creation time 2025-02-15T14:20:00Z, author "chief_engineer", change description "new material GH4720Li introduced, turbopump design life extended to 8000 seconds"; The index.json file has been updated to record that the parent version of v2.0 is v1.1.

[0193] Instance migration engine execution: Read the difference mapping rules: Add the hasMaterial property to all turbopump instances, with a default value pointing to GH4169 (raw material). For 16 engines with batch number ≥ JD2-023, the hasMaterial is set to GH4720Li; For the eight engines with batch numbers JD2-015 to JD2-022, hasMaterial is not set for now; instead, it is marked as MATERIAL_PENDING.

[0194] Migration execution: 16 servers updated automatically, 8 servers added to the pending list; Generate a migration report and notify the production department to supplement material traceability information.

[0195] 6) Consistency check; The consistency checker runs automatically: Ontology consistency check: Call the Pellet inference engine to check that the definitions related to the new material do not have logical conflicts with the existing ontology; Instance compatibility check: 10 engine instances were randomly sampled and checked, of which 2 instances using new materials fully complied with the new constraints; Traceability path check: Verify that the traceability path from v1.1 to v2.0 is complete.

[0196] (6) Digital Thread Tracing (Completed Version); In March 2025, the quality department conducted a fault-zeroing analysis and needed to check the design status of engine JD2-002 manufactured in August 2024. The engineer entered: GET / entity / JD2-002?timestamp=2024-08-01.

[0197] System processing: 1. Query version time index: The version of the ontology that took effect on August 1, 2024 is v1.1 (v2.0 has not yet been created). 2. Query Instance - Version Mapping Index: Storage location of JD2-002 in version v1.1 (the engine with batch number JD2-002 had not yet involved new material upgrades at that time) 3. Returned results: Design parameters: Combustion chamber pressure 10.5MPa (v1.1 version parameters); Material information: Original design material GH4169 (v1.1 default); Differences highlighted: Comparison with the current version (v2.0); Materials: The current version has been upgraded to GH4720Li, with the design life extended from 5000 seconds to 8000 seconds; Design life increased by +60%; Because the engine was produced in an earlier batch, it was still manufactured according to the original design, but its design baseline can be traced back through digital threads.

[0198] Complete timeline: v1.0 (2024-01-15): Initial design, combustion chamber pressure 10MPa, turbopump speed 30000rpm, material GH4169; v1.1 (2024-06-20): The combustion chamber pressure was adjusted to 10.5MPa based on test data, and new cooling channel parameters were added; v2.0 (2025-02-15): New material GH4720Li upgrade, turbo pump design life extended from 5000 seconds to 8000 seconds.

[0199] Examples of application scenarios for digital thread tracing: 1. Fault Resolution: A test run malfunction involved an engine manufactured in August 2024. Engineers need to check the design status at that time. Enter the time point "2024-08-01", and the system will return the design parameters of version 1.1, noting the differences from the current version.

[0200] 2. Change Impact Analysis: When planning to upgrade a component to the v2.0 standard, engineers need to query all instances still using version v1.x. The system quickly filters the list of instances to be upgraded using instance-version binding.

[0201] 3. Design Decision Traceability: When a new designer joins the company, they need to understand the decision-making process behind adjusting the combustion chamber pressure from 10MPa to 10.5MPa. The system displays related test reports, analysis documents, and change approval records.

[0202] This embodiment uses the knowledge accumulation process of an aerospace engine fault case database as an example to demonstrate how the evolution mechanism supports knowledge updates, and explains in detail its application in the evolution of the fault case database, such as... Figure 5 As shown.

[0203] (1) Initial state; In January 2024, the fault case library v1.0 was released, containing 50 fault modes, with basic categories such as turbopump faults and combustion chamber faults.

[0204] (2) Event access and evolution; From February to July 2024, the event detector received five cases of failures related to "bearing wear": Event F001 (February): Turbine pump vibration exceeded the standard; the zeroing report confirmed that the bearing cage was broken. Event F002 (April): Turbine pump speed decreased, and the zeroing report confirmed bearing ball wear; Incident F003 (May): Abnormal noise from the turbine pump; zeroing report confirmed poor bearing lubrication. Event F004 (June): Abnormal temperature rise in the turbine pump; zeroing report confirms excessive bearing clearance; Event F005 (July): Abnormal vibration of the turbine pump; zeroing report confirms wear on the outer ring of the bearing.

[0205] Statistical findings from evolutionary rule learners: The number of similar failures (involving bearings) has reached 5 times. In the existing fault classifications of the system, there are no bearing-related subclasses under TurboPumpFault; The meta-learning model predicts P=0.95, triggering the "Add Fault Mode" proposal.

[0206] (3) Expert confirmation; Proposal P002 suggests: A new class, BearingWear, has been added as a subclass of TurboPumpFault. Add a new data attribute hasWearLocation (enumeration values: innerRace / outerRace / ball / cage) Added SWRL rules: TurboPump(?tp) ∧ hasVibration(?tp, ?v) ∧ greaterThan(?v, 15) ∧ hasSpeed(?tp, ?s) ∧ lessThan(?s, 28000) → hasFault(?tp, "BearingWear") Impact Analysis: Of the 127 existing turbopump failure cases, 35 meet the conditions of the new rule and can be automatically classified as BearingWear; the remaining 92 require manual review.

[0207] After expert confirmation, a new version v1.5 was created and instance migration was performed: 35 cases were automatically updated in the classification, and 92 cases were marked as pending review.

[0208] (4) Rule consistency verification; With the release of version 2.0, a new rule R15 was added: "Excessive vibration and abnormal temperature → bearing wear". The conformance checker executes this automatically. Scan all historical failure cases (including versions v1.0 and v1.5). Eight cases were found that met the R15 criteria but had not previously been classified as bearing wear. Generate a verification report and mark these cases for expert review.

[0209] After expert review, it was confirmed that 6 cases should be reclassified, while 2 cases maintained their original classification due to other factors. This process ensured the accuracy of historical data after the rule change.

[0210] When the instance is upgraded from v1.0 to v2.0, the instance migration engine performs the following steps: 1. Parse the difference mapping rules between the old and new versions, for example: Class mapping: TurboPumpFault → BearingWear: Add a new class BearingWear as a subclass of TurboPumpFault; Attribute mapping: hasVibrationLevel (enumeration value: low / medium / high) → hasVibrationRMS (floating-point number, unit mm / s): The attribute hasVibrationLevel is deprecated and hasVibrationRMS is used instead; Value mapping: "high" → 15.0, "medium" → 10.0, "low" → 5.0; Added rule condition: Modify rule R12 and add the condition hasTemperatureAnomaly.

[0211] 2. Generate migration plan: A query for all TurboPumpFault instances was performed, resulting in 245 instances.

[0212] For all TurboPumpFault instances, if they meet the characteristics of excessive vibration and decreased rotational speed, they are automatically classified as BearingWear. For instances containing hasVibrationLevel, convert them to hasVibrationRMS according to the mapping table; For instances that do not meet the newly added rule hasTemperatureAnomaly, mark them as "requires manual confirmation".

[0213] 3. Perform migration: Use online migration mode to perform batch migrations and generate migration reports, including the number of successful migrations, the number of failed migrations, and the number of migrations requiring manual processing.

[0214] 4. Version Binding: Bind the migrated instance to the new version v2.0, while retaining a snapshot of the old version instance (identified by the version attribute).

[0215] After each evolution, the consistency checker automatically runs the following checks: 1. Ontology consistency check: Call the Pellet inference engine to check for logical inconsistencies in the new version of the ontology.

[0216] Check items: class definition conflicts (such as disjoint classes being asserted simultaneously), attribute domain / value domain conflicts, rule redundancy, etc.

[0217] Example result: 0 logical contradictions found upon inspection.

[0218] 2. Instance compatibility check: Randomly sample 5% of instances and check whether they meet the constraints of the new ontology, verifying each one: Does the required attribute exist (e.g., hasFaultCode)? Is the attribute value type correct (e.g., hasPressure should be a floating-point number)? Does the relationship integrity requirement hold (e.g., each Fault must have a causeBy relationship)? Example results: 45 fully compatible, 3 with incorrect attribute value types (e.g., an integer was passed as a string), and 2 missing required attributes.

[0219] 3. Traceability path check: Randomly select 10 historical traceability paths to verify whether they can correctly return to the historical state.

[0220] Execution time point query, version query, and range query.

[0221] Verify the consistency between the returned results and historical snapshots.

[0222] Example results: 9 results passed, 1 result returned was not as expected (investigated to be due to index update delay).

[0223] 4. Generate a verification report: The report includes the items checked, pass rate, and details of failures.

[0224] If a problem is found (such as an instance compatibility issue), an alarm will be triggered, and the administrator will be notified to intervene manually.

[0225] The verification report will also be stored in the audit log for future reference.

[0226] The above are merely preferred embodiments of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A knowledge graph dynamic evolution and digital thread tracing system based on ontology version management, characterized in that, include: The ontology version manager is used to manage the versioning of the ontology of the knowledge graph, and to record and store multiple historical versions of the ontology. The instance-version binder is used to associate and bind instance data in the knowledge graph with the ontology version on which it was generated and to generate an instance-version mapping index. An evolution proposal generator is used to analyze changes in external events or domain knowledge and automatically generate ontology evolution proposals that include suggested changes to the ontology. An evolution executor is used to respond to the confirmation instruction for the ontology evolution proposal, create a new version through the ontology version manager according to the proposed changes, and perform migration operations on instances associated with the old version according to the instance-version mapping index, so that the migrated instances are compatible with the new version; The digital thread tracing engine is used to respond to query requests containing time parameters. Based on the historical version of the ontology and the instance-version mapping index, it determines the target ontology version and the target instance version corresponding to the time parameter, and traces back and returns the knowledge graph status at the specified historical time point.

2. The system according to claim 1, characterized in that, The ontology version manager assigns a globally unique version number that follows the semantic versioning specification to each ontology version, stores the complete ontology file and records the difference patches with the previous version, and maintains version metadata and the evolution relationship and branch information between versions.

3. The system according to claim 1, characterized in that, The instance-version binder uses a multi-version concurrency control mechanism to maintain multiple historical versions of the instance. When creating a new instance, the currently effective ontology version number is recorded as a version attribute in the instance. When the instance is modified, the original instance copy is retained and a new instance associated with the new version number is created. An instance-version mapping index table is constructed with the instance identifier and version number as keys and the instance storage location as values.

4. The system according to claim 1, characterized in that, The evolution proposal generator includes: An event detector is used to subscribe to and parse external events or domain knowledge in real time from an event queue; The pattern matcher is used to match the parsed event information with the existing classes, attributes and rules of the ontology, identify the associated ontology elements and send them to the frequency counter. A frequency counter is used to count the frequency of occurrence of similar events or similar knowledge using a sliding window counter. An evolution rule learner is used to determine whether the ontology needs to be evolved based on the current ontology structure and event characteristics when the occurrence frequency meets preset conditions, and to generate a structured evolution proposal containing suggested changes, a list of triggering events, and an impact analysis when the determination result is that evolution is required.

5. The system according to claim 4, characterized in that, The evolution rule learner is constructed using a meta-learning algorithm, which is trained based on a historical evolution case library and is used to predict the ontology elements that need to be updated based on the current ontology structure and event features.

6. The system according to claim 1, characterized in that, The evolutionary actuator includes: The expert confirmation interface is used to visually display the ontology evolution proposal, receive operations from domain experts, and trigger the ontology update process after expert confirmation. The instance migration engine is used to parse the differences between the new version and the old version of the ontology and generate a difference mapping rule table after the ontology update process is triggered. It then filters out the instances that need to be migrated according to the instance-version mapping index, performs batch conversion on the instances that need to be migrated according to the difference mapping rule table, marks the instances that cannot be automatically converted, and generates a migration report.

7. The system according to claim 6, characterized in that, The instance migration engine supports online and offline migration modes. In online migration mode, instances are migrated in batches and indexes are updated in real time. In offline migration mode, system writes are paused and all instances are migrated at once. The migration process uses a two-phase commit protocol to ensure data consistency.

8. The system according to claim 1, characterized in that, The digital thread tracing engine supports at least one of the following query types: Time point query is used to determine the ontology version corresponding to a single entity identifier and a specified timestamp by querying the version time index, and to obtain the historical state of the entity under the ontology version by combining the instance-version mapping index. The time interval query is used to traverse the instance-version mapping index based on a single entity identifier and a specified time interval to obtain all versions of the entity and their corresponding ontology structure within the specified time interval, and return the evolution history of the entity. The association traceability query is used to query the evolution history of two entities within a specified time interval based on their identifiers and time intervals, determine the relationship status between them at each point in time, and return the relationship evolution history.

9. The system according to claim 1, characterized in that, It also includes a consistency checker, which is used to perform logical consistency checks on the new version of the ontology, perform sampling compatibility checks on the migrated instance data, perform sampling verification on the digital thread tracing path, generate a consistency check report, and trigger an alarm when a problem is found after the evolution executor completes the creation of the new version of the ontology and the migration of instances.

10. A method for dynamic evolution of knowledge graphs and digital thread tracing based on ontology version management, using the system described in any one of claims 1-9, characterized in that, include: The ontology version manager is used to manage the versioning of the ontology of the knowledge graph, and to record and store multiple historical versions of the ontology. The instance-version binder associates and binds instance data in the knowledge graph with the ontology version on which it was generated, and generates an instance-version mapping index. The evolution proposal generator analyzes changes in external events or domain knowledge and automatically generates ontology evolution proposals that include suggested changes to the ontology. The evolution executor responds to the confirmation instruction of the ontology evolution proposal, creates a new version of the ontology through the ontology version manager according to the proposed changes, and performs a migration operation on the instance data associated with the old version of the ontology according to the instance-version mapping index, so that the migrated instance data is compatible with the new version of the ontology. The digital thread tracing engine responds to query requests containing time parameters, determines the target ontology version and target instance version corresponding to the time parameter based on the ontology historical versions stored in the ontology version manager and the instance-version mapping index generated by the instance-version binder, and traces back and returns the knowledge graph status at the specified historical time point.

Images