Multi-person collaborative labeling operation transformation method and device, and storage medium

Abstract

The application discloses a multi-person collaborative labeling operation transformation method and device and a storage medium. The method comprises the following steps: acquiring an attribute graph model corresponding to a collaborative labeling task; receiving concurrent operations of at least two collaborative clients based on the attribute graph model, wherein the concurrent operations comprise a first operation set for nodes and / or a second operation set for edges in the attribute graph model; when it is detected that the concurrent operations have conflicts, calling an operation transformation function based on the graph constraint rules, modifying the operation type or operation object of at least one operation in the concurrent operations; and applying the modified operation type or operation object to the attribute graph model. The application eliminates the pending relationship and attribute mutual exclusion conflict by presetting medical semantic constraint rules for the attribute graph model and modifying the operation transformation function based on the rules when the concurrent operation conflict is detected, thereby maintaining the clinical logical consistency of the labeling graph structure.

Description

Technical Field

[0001] This application relates to the field of medical image processing technology, and in particular to a method, device and storage medium for multi-person collaborative annotation operation transformation. Background Technology

[0002] With the explosive growth of medical imaging data, high-quality, multimodal medical annotation data has become a key infrastructure for the development of AI-assisted diagnostic systems. In clinical scenarios such as lung cancer screening and stroke analysis, radiologists need to accurately annotate lesions, blood vessels, organs, and their spatial and functional relationships in computed tomography (CT) scans and other images. Such annotation tasks often involve multiple doctors simultaneously; collaborative annotation by multiple doctors can significantly improve annotation efficiency and diagnostic quality, and has become an important development direction in the field of medical image processing.

[0003] In real-time collaborative editing scenarios involving multiple users, manipulation transformation algorithms are a core technical means to ensure data consistency among all participants. However, when dealing with medical image annotation scenarios, the data models relied upon by conventional manipulation transformation methods are often oversimplified. They typically abstract medical annotation objects into independent bounding boxes or discrete point sets, which can only express the marked location of a single nodule, but cannot describe complex anatomical structural relationships and their semantic hierarchy.

[0004] The above content is only used to help understand the technical solution of this application and does not represent an admission that the above content is prior art. Summary of the Invention

[0005] The main purpose of this application is to provide a method, device and storage medium for multi-person collaborative annotation operation transformation, which aims to solve the technical problem that existing collaborative annotation concurrent editing cannot guarantee the clinical logical consistency and graph structure integrity of the annotation graph model.

[0006] To achieve the above objectives, this application proposes a multi-person collaborative annotation operation transformation method, the method comprising: Obtain the attribute graph model corresponding to the collaborative annotation task. The attribute graph model includes nodes representing entities, edges representing semantic relationships between the nodes, and graph constraint rules. Receive concurrent operations from at least two collaborative clients based on the property graph model, the concurrent operations including a first set of operations on nodes in the property graph model and / or a second set of operations on edges; When a conflict is detected in the concurrent operations, the operation transformation function is invoked based on the graph constraint rules to modify the operation type or operation object of at least one of the concurrent operations. Apply the modified operation type or operation object to the attribute graph model.

[0007] In one embodiment, before the step of obtaining the attribute graph model corresponding to the collaborative annotation task, the method further includes: Nodes are created based on lesion entities and / or anatomical structure entities in medical imaging data; Based on the clinical semantic relationship between the lesion entity and / or anatomical entity corresponding to the node, create relationship edges between the nodes; The nodes and relation edges are combined into an attribute graph model. Based on the type of the nodes and relation edges, medical semantic preset graph constraint rules are used to assign corresponding graph constraint rules to each node and each relation edge.

[0008] In one embodiment, the step of creating nodes based on lesion entities and / or anatomical structure entities in medical imaging data includes: The node type is determined based on the entity type attribute of the node; If the entity type attribute indicates that the node corresponds to a lesion entity, then the node is determined to be a lesion node type; If the entity type attribute indicates that the node corresponds to an anatomical structure entity, the node is determined to be a key anatomical structure node type; The step of assigning corresponding graph constraint rules to each node and each relation edge using medical semantic preset graph constraint rules, based on the type of the node and relation edge, includes: Assign mutual exclusion constraints to nodes of the lesion node type; Assign solid protection constraints to nodes of the critical anatomical structure node type.

[0009] In one embodiment, the step of creating relationship edges between the nodes based on the clinical semantic relationships of the lesion entities and / or anatomical entities corresponding to the nodes includes: Based on the clinical relationship type attribute of the relationship edge, the relationship edge is determined to be of clinical relationship edge type; The step of assigning corresponding graph constraint rules to each node and each relation edge using medical semantic preset graph constraint rules, based on the type of the node and relation edge, includes: Assign existence dependency constraints to the relation edges.

[0010] In one embodiment, the step of invoking an operation transformation function based on the graph constraint rules to modify the operation type or operation object of at least one operation in the concurrent operations when a conflict is detected includes: Determine the type of operation object targeted by each operation in the concurrent operations, wherein the operation object type includes node type and edge type; Match the corresponding graph constraint rules according to the type of the operation object, and determine whether the concurrent operation constitutes a conflict based on the matched graph constraint rules; If a conflict occurs, the operation transformation function is invoked to modify the operation type or operation object of at least one of the concurrent operations, so that the modified operation is compatible with the graph constraint rules.

[0011] In one embodiment, when the operation object type is a node type, the step of matching the corresponding graph constraint rules according to the operation object type and determining whether the concurrent operations constitute a conflict based on the matched graph constraint rules includes: If the first operation in the concurrent operations is to delete the target node and the second operation is to modify the node attribute of the target node, the modification operation of the node attribute depends on the existence of the target node based on the existence of dependency constraints, and it is determined that the first operation and the second operation constitute a conflict. The step of calling the operation transformation function to modify the operation type or operation object of at least one operation in the concurrent operations includes: changing the operation type of the second operation from modifying node attributes to an invalid operation.

[0012] In one embodiment, when the operation object type is an edge type, the step of matching the corresponding graph constraint rules according to the operation object type and determining whether the concurrent operations constitute a conflict based on the matched graph constraint rules includes: If the first operation in the concurrent operation is to delete the target node, and the second operation is to create a target edge with the target node as the source node or the target node, the creation operation of the target edge depends on the existence of the target node based on the existence dependency constraint, and it is determined that the first operation and the second operation constitute a conflict. The step of calling the operation transformation function to modify the operation type or operation object of at least one operation in the concurrent operations includes: changing the operation type of the second operation from creating an edge to an invalid operation.

[0013] In one embodiment, before the step of applying the modified operation type or operation object to the attribute graph model, the method further includes: Perform a conflict re-check on the corrected operation type or operation object to determine whether there are any new conflicts between the corrected operation type or operation object and the current state of the attribute graph model; If a new conflict exists, the operation transformation function is called again based on the graph constraint rules to make corrections until the corrected operation does not conflict with the current state of the attribute graph model.

[0014] In addition, to achieve the above objectives, this application also proposes a multi-person collaborative annotation operation transformation device, the device comprising: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the multi-person collaborative annotation operation transformation method described above.

[0015] In addition, to achieve the above objectives, this application also proposes a storage medium, which is a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, it implements the steps of the multi-person collaborative annotation operation transformation method described above.

[0016] One or more technical solutions proposed in this application have at least the following technical effects: Obtain the attribute graph model corresponding to the collaborative annotation task. The attribute graph model includes nodes representing entities, edges representing semantic relationships between the nodes, and graph constraint rules. Receive concurrent operations from at least two collaborative clients based on the attribute graph model. The concurrent operations include a first set of operations on nodes in the attribute graph model and / or a second set of operations on edges. When a conflict is detected among the concurrent operations, call an operation transformation function based on the graph constraint rules to modify the operation type or operation object of at least one operation in the concurrent operations. Apply the modified operation type or operation object to the attribute graph model.

[0017] Through the above technical means, while ensuring the efficiency of concurrent editing by multiple people, the automatic preservation of medical semantic constraints is achieved. This solves the technical problem that the integrity of the annotation graph structure is destroyed and cannot be actively repaired under the general merging strategy. It realizes the technical leap of medical image collaborative annotation from simplified merging for unrelated objects to constraint-driven transformation for graph structure semantics, and from passively bearing semantic conflicts to actively resolving semantic contradictions. Attached Figure Description

[0018] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

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

[0020] Figure 1 This is a flowchart illustrating the first embodiment of the multi-person collaborative annotation operation transformation method of this application; Figure 2This is a detailed schematic diagram of step S30 in the first embodiment; Figure 3 This is a flowchart illustrating the second embodiment of the row-level multi-person collaborative annotation transformation method of this application; Figure 4 This is a flowchart illustrating the third embodiment of the row-level multi-person collaborative annotation transformation method of this application; Figure 5 This is a schematic diagram of the transformation process for multi-person collaborative annotation operations based on an attribute graph model. Figure 6 This is a schematic diagram of the lifecycle process of a graph model; Figure 7 This is a schematic diagram of the hardware operating environment involved in the multi-person collaborative annotation operation transformation method in the embodiments of this application.

[0021] The purpose, features, and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0022] It should be understood that the specific embodiments described herein are merely illustrative of the technical solutions of this application and are not intended to limit this application.

[0023] In the field of collaborative medical image annotation, operation transformation and data consistency maintenance mainly follow the technical path of simplified models and general merging strategies for independent annotation objects. However, this approach has inherent flaws, making it difficult to simultaneously meet the dual requirements of concurrent editing efficiency and medical semantic consistency. This type of approach typically abstracts annotation objects such as lesions, blood vessels, and organs into independent bounding boxes or discrete point sets. When conflicts arise in multi-user operations, a merging strategy of "last write wins" or timestamp priority is used to synchronize the state. In scenarios where there are no relationships between annotation objects and editing operations are independent, this approach can achieve collaborative functions with a relatively simple data structure, facilitating system integration and deployment. However, this approach is essentially a conflict resolution paradigm for unrelated planar data, failing to incorporate the structured semantic relationships between annotation objects into the logical framework of operation transformation. Simplified models can only record the spatial location and category attributes of individual objects, failing to express clinical relationships such as tumor invasion of the pleura, vascularized lesions, and adhesions between lymph nodes and surrounding tissues. General merging strategies, when faced with concurrent operations, can only mechanically select based on timing or permissions, failing to perceive semantic conflicts arising from graph-structured relationships between operations. When multiple doctors simultaneously edit related labeled objects, such as one doctor deleting a tumor node while another doctor is creating an invasion relationship edge based on that tumor, the merging strategy will produce states that violate medical logic, such as blood vessels pointing to tumors that no longer exist, and contradictions between tumor staging attributes and deletion operations, making the labeled data unusable in clinical diagnosis and surgical planning.

[0024] Comprehensive analysis reveals that the core dilemma faced by the above-mentioned technical approaches lies in the fact that, although the control methods of modeling data with independent labeled objects and handling concurrent conflicts with general merging strategies are simple in structure and intuitive in process, their characteristics of missing semantics in graph structure and disconnect between constraint rules and transformation logic are fundamentally contradictory to the inherent requirements of medical image collaborative annotation for expressing complex anatomical relationships and maintaining consistency with clinical logic. As a result, semantic conflicts cannot be actively resolved during concurrent editing.

[0025] To address the aforementioned shortcomings, this application proposes a multi-user collaborative annotation operation transformation method based on an attribute graph model. This method addresses the core pain points of collaborative annotation lacking graph structure semantic modeling and the inability of operation transformations to maintain medical constraints. It models lesion entities and anatomical structure entities as nodes in an attribute graph model, and clinical relationships as directed edges. Based on a pre-defined set of graph constraint rules including existence dependency, attribute mutual exclusion, and entity protection, a constraint-driven operation transformation system is constructed. Specifically, this method receives concurrent operations on nodes and edges in the attribute graph model from multiple collaborative clients. When a conflict is detected due to a violation of graph constraint rules, an operation transformation function is invoked to correct the operation type or object of the conflicting operation. For example, an edge creation operation that loses its existence basis due to the deletion of the target node is transformed into an invalid operation; concurrent modification operations of mutually exclusive attributes targeting the same lesion node are retained based on a merging strategy, thus ensuring that the corrected operation sequence remains compatible with the graph constraint rules.

[0026] Through the above technical means, this application achieves automatic preservation of medical semantic constraints while ensuring the efficiency of concurrent editing by multiple users. It solves the technical problem that the integrity of the annotation graph structure is destroyed and cannot be actively repaired under the general merging strategy. It realizes the technical leap of medical image collaborative annotation from simplified merging oriented to unrelated objects to constraint-driven transformation oriented to graph structure semantics, and from passively bearing semantic conflicts to actively resolving semantic contradictions.

[0027] To better understand the technical solution of this application, a detailed description will be provided below in conjunction with the accompanying drawings and specific implementation methods.

[0028] Based on this, the embodiments of this application provide a method for transforming multi-person collaborative annotation operations, referring to... Figure 1 , Figure 1 This is a flowchart illustrating the first embodiment of the multi-person collaborative annotation operation transformation method of this application. In this embodiment, the multi-person collaborative annotation operation transformation method includes steps S10 to S40: Step S10: Obtain the attribute graph model corresponding to the collaborative annotation task. The attribute graph model includes nodes representing entities, edges representing semantic relationships between the nodes, and graph constraint rules. In scenarios involving collaborative annotation of medical images, each image dataset and its existing annotations need to be organized into a data structure that computers can understand, manipulate, and apply medical constraints to. Attribute graph models provide such a structure. They represent labeled objects in the form of a graph: each node in the graph represents an entity, such as a lung nodule, tumor, blood vessel segment, or an organ like the pleura; each directed or undirected edge represents a semantic relationship between entities, for example, the edge "tumor invading the pleura" expresses this clinical relationship. In addition to nodes and edges, attribute graph models also carry graph constraint rules. These rules specify what types of nodes can be created or deleted, what types of edges can connect which types of nodes, and the medical integrity conditions that must be followed during concurrent operations.

[0029] There are two ways to obtain the aforementioned attribute graph model. When starting a collaborative annotation task for the first time, the model needs to be built from scratch. Read a medical image dataset, such as a complete lung CT sequence, and identify the existing annotations. If the image does not yet contain any structured annotations, call a pre-trained AI model to automatically detect suspected lesions and major anatomical structures, generating an initial set of nodes. Then, based on an anatomical knowledge base, pre-set common relationship edges between these nodes, such as the anatomical inclusion relationship between the left upper lobe and apical segment. If the image has already been pre-annotated with some lesions by a physician, these annotations are converted into corresponding nodes, and relationship edges are extracted from the free text description using natural language processing or a rule engine. After completing the initial node and edge creation, configure a set of graph constraint rules for the task based on the medical knowledge graph. These rules may include: the source node of any invasion relationship is the tumor type, and the target node is the organ or structure type; nodes corresponding to key anatomical structures such as the aorta and heart are marked as non-deletable; for the T-staging attribute of the same lesion, multiple concurrent assignment operations must adhere to the uniqueness and mutual exclusion of the staging values.

[0030] Another approach is to load an existing model from persistent storage. When doctors reopen the same case after their previous collaborative annotation, the system directly reads the previously saved attribute graph model from the database or distributed file system, including all nodes, edges, and the previously set graph constraints. This eliminates the need for reconstructing the model, allowing doctors to continue collaborative editing on the existing one. Regardless of the method used, the output is a fully loaded and validated attribute graph model instance, and all subsequent concurrent operations will operate on this instance. The above description clarifies the necessity of obtaining the model and its specific implementation path, laying the foundation for subsequent collaborative editing.

[0031] Step S20: Receive concurrent operations from at least two collaborative clients based on the attribute graph model, wherein the concurrent operations include a first set of operations on nodes in the attribute graph model and / or a second set of operations on edges. In a multi-user real-time collaborative system, each doctor's client runs independently. Doctors edit the attribute graph model on their clients, such as adding a node for a lung nodule, deleting an invading edge, or modifying the diameter attribute of a tumor. These operations are captured by the client and encapsulated as operation objects. Each operation object contains at least the operation type, an operation object identifier, and the new value or relationship carried by the operation. The client immediately sends these operation objects to the collaboration server, while also executing them locally once to maintain an immediate response. Due to network latency and differences in the operation speed of different doctors, the server may receive multiple operations from different clients within a similar time window. These operations do not have a strict temporal dependency and are therefore referred to as concurrent operations.

[0032] This embodiment specifically defines concurrent operations as including a first set of operations on nodes and / or a second set of operations on edges. The first set of operations can include three basic types: creating nodes, deleting nodes, and updating node attributes. For example, doctor A creates a node with the ID "Nodule_01" for a lung nodule and assigns it attributes such as size and edge features. The second set of operations includes three types: creating edges, deleting edges, and updating edge attributes. For example, doctor B creates an invasive edge pointing from "Nodule_01" to "Pleura". These operations can arrive at the server simultaneously or interleaved, forming a concurrent set.

[0033] In the implementation, to ensure orderly processing of concurrent operations without losing any operational intent, the server assigns a globally monotonically increasing logical timestamp to each received operation. Simultaneously, the server maintains a queue of pending operations. When a batch of operations arrives, step S20 groups these operations according to the objects in the attribute graph model they point to. Multiple attribute update operations belonging to the same node are grouped together, as are deletion and update operations pointing to the same edge. This is done to efficiently identify which operations may have mutual exclusion or dependency relationships during subsequent conflict detection.

[0034] Basic syntax validation is also required for the operations, such as checking whether the node IDs referenced in the operation meet the format specifications and whether the attribute names of the update operation belong to the predefined attribute set of that type of node. If an operation does not meet the syntax requirements, it will be directly marked as an invalid operation and will not enter the subsequent conflict detection process. Through the above receiving and preprocessing, the original concurrent operation stream is transformed into a structured internal representation that can be sent to the conflict detection module, providing data input for the next processing step.

[0035] Step S30: When a conflict is detected in the concurrent operations, the operation transformation function is called based on the graph constraint rules to modify the operation type or operation object of at least one operation in the concurrent operations. When a conflict is detected between concurrent operations, an operation transformation function is invoked based on graph constraint rules to modify the operation type or object of at least one operation. This is based on a set of concurrent operations input by the user, and an attribute graph model already loaded into memory along with its associated graph constraint rules. The graph constraint rules are predefined medical integrity assertions, such as "a source node and a target node connected by an intrusive edge both exist in the current graph model," "the T-staging attribute of the same tumor node cannot be set to different mutually exclusive values ​​by two concurrent operations simultaneously," and "critical anatomical structure nodes cannot be affected by any deletion operation."

[0036] First, conflict detection is performed on each pair of concurrent operations. The basic logic of the detection is as follows: for each pair of operations (op1, op2), simulate whether applying op1 to the current graph model first, and then applying op2, would violate any graph constraint rules; and vice versa. If both orders result in a violation of graph constraints, or if one order violates a constraint while the other violates a different rule, then the two operations are determined to be in conflict. For example, operation opA deletes a tumor node, and operation opB modifies the T-staging attribute of the same tumor node. According to the existence dependency constraint in the graph constraint rules, any operation that modifies a node's attribute requires that the node currently exists. If opA is executed first, the node is deleted, and opB will violate the constraint because the node cannot be found. If opB is executed first, it modifies the attribute normally, and then opA deletes the node, ultimately resulting in the node being lost in the model. Both orders will produce inconsistencies or information loss. Therefore, opA and opB are determined to be in conflict.

[0037] Once a conflict is identified, the operation transformation function is invoked. Based on the type of graph constraint rule and the specific content of the operation, the operation transformation function determines whether to modify at least one of the operations. Modification methods include changing the operation type, changing the operation object, or converting the operation into an invalid operation. Taking the example of deleting a node and modifying node attributes, the operation transformation function can determine that deleting the node has higher priority because deleting the node represents the doctor's belief that the lesion no longer exists. In this case, the function converts the operation of modifying node attributes into an invalid operation, meaning it has no effect on the graph model. Another example is concurrent operations involving creating an intrusive edge and deleting the target node of that edge. Based on the existence dependency in the graph constraint rule, the operation transformation function determines that the operation of creating the edge depends on the existence of the target node, therefore converting the operation of creating the edge into an invalid operation, while retaining the operation of deleting the node.

[0038] Another typical conflict scenario is when two doctors simultaneously update the T-staging of the same tumor node, one setting it to T2 and the other to T3. The graph constraint rules pre-define a mutual exclusion constraint on staging, meaning the same node cannot have two different T-stagings simultaneously. The operation transformation function reads the "higher stage takes precedence" rule from the medical constraint manager, converting the operation set to T2 into an invalid operation, while retaining the T3 operation. If the rule is configured as "last write confirmed by doctor," the function compares the timestamps of the two operations, converting the operation with the earlier timestamp into an invalid operation, and retaining the later operation. Through the above process, step S30 ensures that any pair of concurrent operations will no longer violate the graph constraint rules after the transformation, thus guaranteeing the consistency of medical semantics.

[0039] Step S40: Apply the modified operation type or operation object to the attribute graph model.

[0040] After the operation transformation, a set of potentially conflicting concurrent operations has been converted into a set of mutually compatible, sequentially executable operations. Each operation in this sequence is applied to the current property graph model in order, updating the model's state. The entire application process must guarantee atomicity and observability: Atomicity means that the batch of corrected operations must either all be successfully applied or, in the event of a serious error, all be rolled back, avoiding an inconsistent state of partial updates to the model; observability means that every change in the model's state is recorded and broadcast to all participating clients, ensuring that each doctor's interface can promptly see the results of other doctors' operations.

[0041] The specific execution process depends on the underlying storage structure of the attribute graph model. This model can be implemented using an in-memory graph database, for example, by using an adjacency list to store the relationships between nodes and edges, and maintaining a version number for each node and edge. When a revised operation reaches the application layer, it first checks whether the node or edge referenced by the operation still exists in the current model. Since the model has already been transformed based on its previous state, but the model state may have changed again before actual execution, an existence check is required again.

[0042] For confirmed valid operations, specific graph modification actions are executed. If the operation is to create a node, a new node record is added to the node set of the graph, a unique internal ID is assigned to it, and all attribute values ​​are written. If the operation is to delete a node, the node and all its associated edges are recursively deleted, and the callback functions defined in the graph constraint rules are triggered simultaneously. For example, deleting a tumor node requires simultaneously canceling all invasion, blood supply, and other related edges associated with that node. If the operation is to update node attributes, the attribute dictionary of the corresponding node is directly modified, and an attribute change event is triggered. For edge operations, the addition, deletion, and modification of edges are performed similarly. Each of these modifications generates a serializable change log, including a snapshot of the state before the modification or incremental differences.

[0043] Finally, all operations performed in this application, along with the resulting model version number, are encapsulated into confirmation messages and sent to the clients that initiated these operations. Upon receiving the confirmation, the client marks the locally stored operations as committed or corrects its local model based on the final state returned by the server. Simultaneously, the server persists the batch-processed model state to the database for later recovery or auditing. This process completes a closed loop from corrected operations to the change in the attribute graph model state, ensuring final consistency and medical semantic integrity during multi-user collaborative annotation.

[0044] Furthermore, you can also view Figure 2 , Figure 2 This is a schematic diagram illustrating the detailed process of step S30 in the first embodiment. Figure 2 The step of creating an attribute graph model based on the lesion entity and the anatomical structure entity, and setting the graph constraint rules of the attribute graph model through medical semantic preset graph constraint rules, includes S31~S32: Step S31: Determine the type of operation object targeted by each operation in the concurrent operation, wherein the type of operation object includes node type and edge type; Step S32: Match the corresponding graph constraint rules according to the type of the operation object, and determine whether the concurrent operation constitutes a conflict based on the matched graph constraint rules; Step S33: If a conflict occurs, the operation transformation function is called to modify the operation type or operation object of at least one of the concurrent operations, so that the modified operation is compatible with the graph constraint rules.

[0045] In this embodiment, after receiving the identified concurrent operations, the operation transformation engine performs conflict detection and correction processing on each concurrent operation according to a three-stage processing flow: first, determining the type of operation object; second, matching graph constraint rules to determine conflicts; and finally, calling the operation transformation function for correction.

[0046] The operation transformation engine determines the type of operation object targeted by each operation in concurrent operations. Operation object types include node types and edge types. The engine parses the operation object identifier carried in each operation message in the concurrent operations. The operation object identifier is a unique identifier for the target node or edge targeted by the operation. Based on the operation object identifier, the engine locates the corresponding target object in the attribute graph model and reads the identified and recorded node type or relation edge type on the target object. When the operation object identifier points to a node, the engine determines the operation object type of the operation as a node type and further obtains the specific node type, which can be one of the following: lesion node type, anatomical structure node type, or key anatomical structure node type. When the operation object identifier points to a directed edge, the engine determines the operation object type of the operation as an edge type and further obtains the specific relation edge type. The engine determines the operation object type for each operation in the concurrent operations and associates the determination result with the corresponding operation.

[0047] The operation transformation engine matches the corresponding graph constraint rules based on the determined operation object type, and determines whether there are conflicts between operations in concurrent operations based on the matched graph constraint rules. When the operation object type is a node, the operation transformation engine reads the graph constraint rules bound to that node. If the node type is a lesion node, the matched graph constraint rule is an attribute mutual exclusion constraint; if the node type is a critical anatomical structure node, the matched graph constraint rule is an entity protection constraint. When the operation object type is an edge, the operation transformation engine reads the graph constraint rules bound to that edge, which are existence dependency constraints. After obtaining the matched graph constraint rules, the operation transformation engine simulates the graph state change results generated when each operation in the concurrent operation simultaneously takes effect on the attribute graph model, and checks whether the graph state change results violate any of the matched graph constraint rules. The conflict determination criteria are as follows: if the graph state change intended by one operation and the graph state change intended by another operation, when taken effect simultaneously, would cause the state of the attribute graph model to violate any of the above graph constraint rules, then the operation transformation engine determines that the concurrent operation is in conflict.

[0048] If the conflict determination result indicates a conflict, the operation transformation engine calls the operation transformation function to modify the operation type or operation object of at least one operation in the concurrent operations. The operation transformation function is a pre-defined transformation processing program that encapsulates transformation strategies for different conflict types. The operation transformation function receives the conflicting operation pair and the matched graph constraint rule type as input parameters, and determines which operation needs to be modified and what form of modification to perform based on the transformation strategy. Modification forms include transforming the operation type into an invalid operation or redirecting the operation object to an alternative node. Invalid operation transformation refers to changing the operation type to a null operation that does not produce any graph state change effect, ensuring that the operation does not trigger any graph model modification in subsequent application phases. After completing the modification, the operation transformation function outputs the modified operation. This modified operation no longer conflicts with the graph constraint rules of the attribute graph model; that is, the modified operation is in a state compatible with the graph constraint rules.

[0049] The above three-stage processing flow constitutes the complete processing chain for conflict detection and correction of concurrent operations by the operation transformation engine. The operation object type determination stage provides an index basis for subsequent rule matching, the rule matching and conflict judgment stage realizes the automated verification of medical semantic constraints, and the operation transformation stage completes the automatic resolution of conflicts. Through the sequential execution of the above three-stage processing flow, the entire conflict correction process is completed automatically without manual intervention.

[0050] Specifically, when the operation object type is a node type, the step of matching the corresponding graph constraint rules according to the operation object type and determining whether the concurrent operations constitute a conflict based on the matched graph constraint rules includes: If the first operation in the concurrent operations is to delete the target node and the second operation is to modify the node attribute of the target node, the modification operation of the node attribute depends on the existence of the target node based on the existence dependency constraint, and the first operation and the second operation are determined to conflict; the step of calling the operation transformation function to modify the operation type or operation object of at least one operation in the concurrent operations includes: changing the operation type of the second operation from modifying node attribute to invalid operation.

[0051] In this embodiment, the process of matching the corresponding graph constraint rules according to the operation object type when the operation object type is a node type, determining whether concurrent operations constitute a conflict based on the matched graph constraint rules, and calling the operation transformation function to correct the concurrent operations is described.

[0052] The operation transformation engine has determined that the operation object type of each operation in the concurrent operation is a node type, and reads the bound graph constraint rules from the target node. Since the target node is targeted by two operations in the concurrent operation, the operation transformation engine needs to determine whether the simultaneous activation of the two operations will result in a graph state that violates the graph constraint rules.

[0053] The first operation in this concurrent operation is to delete the target node. The operation object identifier of the first operation points to a node in the attribute graph model, and the operation type is a node deletion operation. The graph state change intended by this operation is to remove the target node and all its associated directed edges from the attribute graph model. The second operation is to modify the node attribute of the target node. The operation object identifier of the second operation also points to the target node, and the operation type is a node attribute modification operation. The graph state change intended by this operation is to modify a certain attribute value on the target node to a new attribute value.

[0054] After obtaining the operation types and objects of the two operations mentioned above, the operation transformation engine matches the corresponding graph constraint rules based on the node type of the target node. Since the target node is targeted by two operations, and the first operation is a deletion operation, the operation transformation engine needs to check whether this deletion operation will destroy the existence of nodes on which other operations depend. The operation transformation engine performs conflict judgment based on existence dependency constraints. Existence dependency constraints are constraint rules bound to each directed edge in the attribute graph model, but the judgment logic of these constraint rules also applies to node attribute modification operations: when the object of a node attribute modification operation is a target node, the execution of the modification operation depends on the existence of the target node in the attribute graph model. If the target node is deleted by the first operation, the second operation will lose its object, and the attribute value that the second operation intends to modify will have nowhere to be written.

[0055] Based on the aforementioned dependency constraint, the operation transformation engine determines that the modification of node attributes in the second operation depends on the existence of the target node, while the first operation deletes the target node. If both operations take effect simultaneously, the target node will no longer exist when the second operation is executed, making the second operation an invalid modification operation without an operand. Therefore, the operation transformation engine determines that the first and second operations conflict.

[0056] After conflict resolution, the operation transformation engine calls the operation transformation function to correct concurrent operations. The operation transformation function receives the conflicting operation pair, which includes a first operation deleting the target node and a second operation modifying the node attributes of that target node. Based on a preset transformation strategy, the operation transformation function analyzes the semantic dependency between the two operations. Since the execution of the second operation depends on the existence of the target node deleted by the first operation, and the deletion action of the first operation has semantic priority over the modification action of the second operation, the operation transformation function selects the second operation as the operation to be corrected. The operation transformation function transforms the operation type of the second operation from modifying node attributes to an invalid operation. An invalid operation means that the operation will not be executed in subsequent application stages and will not produce any graph state change effect, thus avoiding attribute modification on a node that no longer exists. The first operation deleting the target node is retained and continues to the subsequent processing flow. This process restores compatibility between the corrected operation set and the existence dependency constraints of the attribute graph model.

[0057] Additionally, when the operation object type is an edge type, the step of matching the corresponding graph constraint rules according to the operation object type and determining whether the concurrent operations constitute a conflict based on the matched graph constraint rules includes: If the first operation in the concurrent operations is to delete the target node, and the second operation is to create a target edge with the target node as the source node or the target node, the creation operation of the target edge depends on the existence of the target node based on the existence dependency constraint, and the first operation and the second operation are determined to conflict; the step of calling the operation transformation function to modify the operation type or operation object of at least one operation in the concurrent operations includes: changing the operation type of the second operation from creating an edge to an invalid operation.

[0058] In this embodiment, when the operation object type is an edge type, the process includes matching the corresponding graph constraint rules according to the operation object type, determining whether concurrent operations constitute a conflict based on the matched graph constraint rules, and calling the operation transformation function to correct the concurrent operations.

[0059] The transformation engine has determined the object type of each operation in the concurrent operations. The object type of the first operation is a node, and the object type of the second operation is an edge. The bound graph constraint rules are read from the target node of the first operation and the target edge of the second operation, respectively.

[0060] The first operation in this concurrent operation is to delete a target node. The target node of this first operation is identified by an identifier pointing to a node in the attribute graph model. The operation type is node deletion, and the intended graph state change is to remove the target node and all its associated directed edges from the attribute graph model. The second operation is to create a target edge with the target node as either the source or target node. The operation type of this second operation is edge creation, and its parameters include the source node identifier and the target node identifier of the target edge. At least one of these identifiers must be identical to the unique identifier of the target node targeted by the first operation. The intended graph state change of this second operation is to add a new directed edge to the attribute graph model. One of the two nodes connected by this directed edge is the target node to be deleted in the first operation.

[0061] After obtaining the operation types and objects of the two operations mentioned above, the operation transformation engine performs graph constraint rule matching and conflict judgment. The object of the second operation is a target edge to be created. The relation edge type of this target edge is a clinical relation edge. The result is assigned according to the classification of graph constraint rules. The graph constraint rule corresponding to the clinical relation edge type is the existence dependency constraint. The existence dependency constraint requires that the source node and the target node connected by the edge must both exist in the attribute graph model. This constraint rule requires that the existence of the edge is a prerequisite for the existence of the nodes at both ends.

[0062] The operation transformation engine performs conflict judgment based on this existence dependency constraint. The second operation is an edge creation operation, which intends to create an edge that depends on the target node as one of its connected nodes. The first operation is a node deletion operation, which intends to remove the target node from the attribute graph model. If both operations take effect simultaneously, the edge created by the second operation will have its one connected node as its target node, while the first operation simultaneously deletes the target node, resulting in a directed edge with one end connected to a node that no longer exists, making the edge a dangling relationship edge. The clinical relationship represented by the dangling relationship edge loses its pointed entity object, violating the basic requirement in medical semantics that a clinical relationship connects two existing entities.

[0063] Based on the above analysis, the operation transformation engine determines that the creation of the target edge in the second operation depends on the existence of the target node, while the first operation will delete the target node. The simultaneous effect of the two operations will violate the existence dependency constraint. Therefore, it is determined that the first operation and the second operation are in conflict.

[0064] After conflict determination, the operation transformation engine calls the operation transformation function to correct concurrent operations. The operation transformation function receives the conflicting operation pair, which includes a first operation (deleting the target node) and a second operation (creating a target edge with the target node as its endpoint). The operation transformation function analyzes these two operations according to a preset transformation strategy. The first operation, deleting the target node, removes an existing element from the attribute graph model. The second operation, creating a target edge, adds an element to the attribute graph model. One end of this added edge connects to the target node to be deleted by the first operation, and the addition operation semantically depends on the existence of this target node. When this dependency is no longer satisfied due to the first operation, the execution of the second operation will result in an invalid graph state that violates the existence dependency constraint. Therefore, the operation transformation function selects the second operation as the corrected operation, changing its operation type from edge creation to invalid operation. This invalid operation is not executed during the application phase, does not produce any graph state change effect, and the target edge will not be created in the attribute graph model. The first operation (deleting the target node) is retained and continues into the subsequent processing flow. The target node and its associated existing edges will be normally deleted when the main graph state is updated. The above corrections prevent dangling edges from appearing in the attribute graph model, maintaining the structural integrity of all directed edges in the attribute graph model, where both ends are connected to nodes.

[0065] Furthermore, you can also view Figure 3 , Figure 3 This is a flowchart illustrating the second embodiment of the row-level multi-person collaborative annotation transformation method of this application. Figure 3 Before the step of obtaining the attribute graph model corresponding to the collaborative annotation task, steps S50~S70 are also included: Step S50: Create nodes based on lesion entities and / or anatomical structure entities in medical imaging data; Step S60: Based on the clinical semantic relationship between the lesion entity and / or anatomical entity corresponding to the node, create relationship edges between the nodes; Step S70: Combine the nodes and relation edges into an attribute graph model. Based on the type of the nodes and relation edges, assign corresponding graph constraint rules to each node and each relation edge using medical semantic preset graph constraint rules.

[0066] This model is built before acquiring the attribute graph model. It is suitable for scenarios where a collaborative annotation task is launched for the first time, when there is no structured graph representation in the system, only raw medical image data and possibly scattered annotation information. The entire construction process is divided into three closely connected sub-steps, which respectively complete node creation, relation edge creation, and model combination and constraint assignment.

[0067] In this embodiment, nodes are created based on lesion entities and / or anatomical structure entities in medical imaging data. In actual execution, a set of medical imaging data, such as a complete lung CT sequence, is first read, and all existing annotations associated with the image are loaded. If the image has not been annotated, the system can invoke a pre-trained artificial intelligence model for automatic identification. This model can detect suspected lesion areas in the image. For each detected instance, a unique node identifier is generated, and the entity's type attribute is recorded. Furthermore, the imaging attributes of the entity are extracted from the image, including location coordinates, size, CT value range, edge features, etc., and these attributes are stored in the node as key-value pairs. For anatomical structure entities, structural attributes may be supplemented based on standard anatomical atlases, such as the lobe level to which "left upper lobe" belongs. If the image already contains some annotations manually drawn by doctors, the system converts these annotations into corresponding nodes, maintaining the original identifiers and attributes. Through the above methods, an initial set of nodes is output, where each node carries a type, a unique identifier, and a set of medically relevant attribute values.

[0068] Based on the clinical semantic relationships between the lesion entities and anatomical entities corresponding to each node, relational edges are created between nodes. Clinical semantic relationships include spatial proximity, functional dependency, and pathological relationships. Using a medical knowledge graph and a predefined relational rule base, these relationships between nodes are automatically inferred or guided to the physician. Technically, a rule-based approach can be used: if a tumor node and a pleural node exist, and the tumor's edge features indicate a distance to the pleura less than a preset threshold, the system automatically creates an "invasion" relational edge pointing from the tumor to the pleura. For the relationship between blood vessels and lesions, if a blood vessel is visible within or at the edge of the lesion, a "nourishing vessel" edge can be created, connecting the lesion node to the corresponding blood vessel segment node. In addition to automatic inference, physicians can manually add relational edges. Physicians can create a new relational edge between two nodes by dragging and dropping lines in the client interface, and select the relation type. Each edge contains a unique edge identifier, source node identifier, target node identifier, relation type, and optional direction and strength attributes. After step S60 is completed, a primitive graph structure with nodes as vertices and relation edges as edges is formed in the system, but at this time, this graph has not yet been bound with any integrity constraints.

[0069] The nodes and edges described above are combined into the final attribute graph model. Based on the types of nodes and edges, corresponding constraints are assigned to each node and edge using pre-defined graph constraint rules in medical semantics. Specifically, each generated node is traversed, and applicable rules are matched from the constraint library according to the node's type attribute. For nodes of type "lesion," a mutual exclusion constraint is assigned, which stipulates that certain key attributes of the node can only take one value from a mutually exclusive set at any given time. For example, the benign / malignant tendency attribute of a lung nodule cannot be both "benign" and "malignant" at the same time, and the T-staging attribute of a tumor can only have one definite stage value at any given time. For nodes of type "critical anatomical structure," such as the heart, aorta, or main bronchus, an entity protection constraint is assigned, prohibiting any deletion operation from directly affecting these nodes. For edges, an existence dependency constraint is assigned based on the edge's clinical relationship type. Taking the "invasive" edge as an example, the constraint rule requires that the source node and target node connected by the edge must both exist in the graph model. When either node is deleted, the edge is automatically removed or marked as invalid. For edges labeled "blood supply" or "drainage," the constraints also require the existence of both vascular nodes and lesion nodes at both ends. Furthermore, the system assigns cardinality constraints to certain edge types; for example, a tumor node can have at most one "T-staging" edge connected to a stage definition node, but can have multiple "invasion" edges connected to different organ nodes. All constraint rules are stored in the medical constraint manager as executable assertions, with each constraint containing triggering conditions, validation logic, and conflict handling strategies. After constraint assignment, the attribute graph model is formally constructed and can be acquired and used for subsequent multi-user collaborative annotation operations. This process ensures that each piece of medical image data can be accurately converted into a graph structure carrying rich semantics and integrity rules, laying a solid foundation for achieving logically consistent concurrent editing in medicine.

[0070] Specifically, the creation of a graph attribute model also includes nodes and edges, as well as graph constraint rules assigned to the nodes and edges. Therefore, the step of creating nodes based on lesion entities and / or anatomical structure entities in medical image data includes: The node type is determined based on the entity type attribute of the node; If the entity type attribute indicates that the node corresponds to a lesion entity, then the node is determined to be a lesion node type; If the entity type attribute indicates that the node corresponds to an anatomical structure entity, the node is determined to be a key anatomical structure node type; The step of assigning corresponding graph constraint rules to each node and each relation edge using medical semantic preset graph constraint rules, based on the type of the node and relation edge, includes: Assign mutual exclusion constraints to nodes of the lesion node type; Assign solid protection constraints to nodes of the critical anatomical structure node type.

[0071] This embodiment defines the specific method for creating nodes and the rules for assigning corresponding constraints to different node types. When constructing an attribute graph model, nodes are the core units representing medical entities, and different types of nodes need to comply with different medical integrity constraints. Therefore, the node creation process can distinguish the type of node and bind appropriate graph constraint rules accordingly.

[0072] For the node creation step, the system first iterates through each entity instance identified from the medical image data. Each instance carries an entity type attribute during detection or import, which can be obtained from the classification output of an artificial intelligence model or from the type selection during manual annotation by a doctor. The system reads this entity type attribute and determines the node type based on a predefined medical entity classification system. If the entity type attribute indicates that the node corresponds to a lesion entity, such as a lung nodule, tumor, metastasis, or enlarged lymph node, the node type is determined to be a lesion node type. Lesion node types are characterized by carrying dynamic attributes such as clinical stage, benign or malignant nature, and size variations. These attributes are prone to concurrent conflicts during collaborative editing, thus requiring special mutual exclusion constraints. If the entity type attribute indicates that the node corresponds to an anatomical structure entity, such as a lung lobe, pleura, vascular segment, or organ, the node type is determined to be an anatomical structure node type. Anatomical structure node types can be further subdivided into ordinary anatomical structure nodes and critical anatomical structure nodes. Key anatomical structure nodes refer to structures that cannot be deleted or removed medically, such as the heart, aorta, main bronchus, and spine. The system identifies these nodes based on a pre-defined whitelist of key anatomical structures. For ordinary anatomical structure nodes, the system creates them in the conventional way; for key anatomical structure nodes, the system adds a protection flag to their node attributes.

[0073] After determining the node type, the constraint assignment phase begins. This step selects applicable graph constraint rules from the medical constraint manager based on the node type and binds the rules to the corresponding nodes. For nodes of the lesion node type, the system assigns attribute mutual exclusion constraints. This constraint means that at any given time, only one valid attribute value can exist in certain mutually exclusive attribute sets of the node. For example, for a tumor node, its T-stage attribute can take one of T1, T2, T3, or T4, but cannot simultaneously have two different stage values. Attribute mutual exclusion constraints are implemented by maintaining an attribute lock table within the node, recording which attributes belong to mutually exclusive groups. When multiple concurrent operations attempt to modify attributes belonging to the same mutually exclusive group simultaneously, the operation transformation function will reject all but one operation according to the constraint rules. For nodes of the critical anatomical structure node type, entity protection constraints are assigned. The core provision of this constraint is that any operation attempting to delete the node will be automatically converted into an invalid operation or a warning operation, indicating to the doctor that the structure cannot be deleted. Entity protection constraints are not only bound during node creation but are also repeatedly verified during the execution of the operation transformation function. Specifically, in a concurrent operation containing an instruction to delete a target node, the system first checks whether the node has a critical anatomical structure node type and whether it is already bound to entity protection constraints. If so, the deletion operation is unconditionally converted into an invalid operation. Through this process, nodes with different medical semantics are ensured to receive differentiated protection mechanisms in collaborative editing, thereby avoiding clinically unacceptable accidental deletions or attribute conflicts.

[0074] Furthermore, the step of creating relationship edges between the nodes based on the clinical semantic relationships of the lesion entities and / or anatomical entities corresponding to the nodes includes: Based on the clinical relationship type attribute of the relationship edge, the relationship edge is determined to be of clinical relationship edge type; The step of assigning corresponding graph constraint rules to each node and each relation edge using medical semantic preset graph constraint rules, based on the type of the node and relation edge, includes: Assign existence dependency constraints to the relation edges.

[0075] This embodiment defines the specific method for creating relational edges and the rules for assigning existence dependency constraints to them. In the attribute graph model, relational edges carry the core function of describing the clinical semantic connections between nodes, such as tumor invasion of the pleura or vascularized lesions. These clinical relationships have strict medical dependencies: the existence of a relational edge presupposes the simultaneous existence of the nodes connected to its two ends. If a node is deleted during collaborative editing but the relational edges connected to that node are still retained, dangling edges will be created, leading to incomplete semantics in the labeled data and errors in clinical interpretation. Therefore, binding existence dependency constraints to relational edges is crucial to ensuring the integrity of the graph structure.

[0076] In the edge creation process, a new edge is first generated based on the doctor's actions or the results of automatic inference. Each edge carries a clinical relationship type attribute upon creation, which is selected by the doctor during creation or automatically determined by the system based on anatomical proximity rules. Common clinical relationship types include "invasion," "blood supply," "drainage," "adjacent," "regional lymph node metastasis," and "containment." The system reads this clinical relationship type attribute and compares it with a predefined whitelist of relationship types. If the relationship type falls within the scope of clinical relationship edge types, the system identifies the edge as a clinical relationship edge type. For example, an edge pointing from a tumor node to a pleural node has a clinical relationship type attribute of "invasion," and the system marks it as a clinical relationship edge type. Conversely, if an edge is only used to represent interface layout or temporary grouping and does not carry clinical semantics, it may not be marked as a clinical relationship edge type, and therefore will not be subject to subsequent strict constraints.

[0077] After determining the type of the relation edges, the constraint assignment phase begins. For each edge identified as a clinical relation edge type, an existence dependency constraint is assigned. The mathematical expression of an existence dependency constraint is: both the source node and the target node connected by the relation edge exist in the current attribute graph model. At any time, if either node is deleted, the relation edge is automatically removed or marked as invalid and awaits subsequent cleanup. In specific implementations, existence dependency constraints can be implemented in two ways. The first way is active triggering: when the system performs a node deletion operation, it traverses all adjacent edges of that node and deletes those marked as clinical relation edge types. The second way is passive verification during the operation transformation process: when the system receives an edge creation operation, the operation transformation function first checks whether the source node identifier and the target node identifier of the edge can both be found in the current graph model. If either node does not exist, the edge creation operation is converted into an invalid operation, thus preventing the creation of dangling edges. For example, when two doctors operate concurrently, doctor A performs an operation to delete a tumor node, and doctor B performs an operation to create an invasion edge from the tumor node to the pleural node earlier or simultaneously. Upon receiving these two concurrent operations, the server's operation transformation function determines the dependencies: the edge creation operation depends on the existence of the source node, while the node deletion operation has already removed that node. Therefore, the edge creation operation is converted into an invalid operation. Ultimately, the node deletion operation is applied to the model, preventing the creation of an edge pointing to a non-existent tumor. This mechanism ensures that every clinical relationship edge in the attribute graph model has a valid node endpoint, thus maintaining the medical semantic integrity and logical consistency of the labeled data.

[0078] Furthermore, you can also view Figure 4 , Figure 4 This is a flowchart illustrating the third embodiment of the row-level multi-person collaborative annotation transformation method of this application. Figure 4 Before the step of applying the modified operation type or operation object to the attribute graph model, the method further includes steps S80-S90: Step S80: Perform a conflict re-check on the corrected operation type or operation object to determine whether there is a new conflict between the corrected operation type or operation object and the current state of the attribute graph model. Step S90: If a new conflict exists, the operation transformation function is called again based on the graph constraint rules to make corrections until the corrected operation does not conflict with the current state of the attribute graph model.

[0079] In this embodiment, after the operation transformation engine completes the conflict correction for concurrent operations, it outputs a set of corrected operations. These corrected operations include retained valid operations and operations transformed into invalid operations. The valid operations carry corresponding graph state changes and will be applied to the main graph state of the attribute graph model in subsequent steps. Since conflict correction only addresses conflicts between operations in concurrent operations and does not check whether each retained valid operation will generate new conflicts when combined with the current main graph state of the attribute graph model, an additional conflict review process is performed before the corrected operations are officially applied to ensure that the corrected operations do not introduce new semantic inconsistencies into the main graph state.

[0080] The operation transformation engine performs conflict review on the corrected operation types or operation objects. The core task of conflict review is to determine whether there are new conflicts between each corrected valid operation and the current state of the attribute graph model. The operation transformation engine first extracts each retained valid operation from the corrected operation set. For each extracted valid operation, the operation transformation engine simulates the execution effect of the operation on the current main graph state of the attribute graph model. Simulated execution means calculating the graph state change result of the attribute graph model after the operation is executed without actually modifying the main graph state. The operation transformation engine obtains the graph constraint rules bound to the operation object targeted by the operation and checks whether the graph state after simulated execution violates any of the graph constraint rules.

[0081] The operation transformation engine checks three types of graph constraint rules during the review process: dependency constraints, attribute exclusivity constraints, and entity protection constraints. For valid operations whose application object is an edge, the operation transformation engine checks after simulation whether the source node and target node connected by the edge both exist in the attribute graph model. If one end node does not exist, the operation is deemed to violate the dependency constraint. For valid operations whose application object is a node, the operation transformation engine checks after simulation whether the node's attribute values ​​violate the attribute exclusivity constraint, i.e., whether the node has two or more attribute values ​​from the mutually exclusive attribute set at the same time. For valid operations of deleting a node, the operation transformation engine checks whether the node targeted by the deletion operation is a node of the critical anatomical structure type. If so, the operation is deemed to violate the entity protection constraint.

[0082] After completing the simulation execution and constraint check of the currently valid operation, the operation transformation engine arrives at a review conclusion for that valid operation. If the graph state after simulation execution does not violate any graph constraint rules, the operation transformation engine determines that the valid operation has passed the review and marks it as an applicable operation. If the graph state after simulation execution violates any graph constraint rules, the operation transformation engine determines that the valid operation has a new conflict and marks it as an operation requiring further correction.

[0083] If the conflict re-check result indicates the existence of new conflicts, the operation transformation engine calls the operation transformation function again for correction based on graph constraint rules. The operation transformation engine passes the operation to be corrected and the type of graph constraint rule violated by the operation as input parameters to the operation transformation function. The operation transformation function determines the transformation strategy for this correction based on the graph constraint rule type, and corrects the operation type or operation object of the operation to be corrected. For example, if the operation to be corrected is to modify the attribute value of a lesion node, and this modification results in the node having two mutually exclusive T-stage attribute values ​​after simulation, the operation transformation function transforms the modification operation into an invalid operation, or redirects the modification target to other attribute values ​​that do not constitute a mutual exclusion conflict with the original attribute value. After the correction is completed, the operation transformation engine includes the newly generated corrected operation in the set of operations to be re-checked and repeats the conflict re-check process in step S60.

[0084] In each review, the operation transformation engine extracts valid operations to be reviewed, simulates their execution and checks constraints, and re-invokes the operation transformation function to correct operations that fail the review. The corrected results are then fed back into the next round of review. This iterative loop continues until all valid operations in the set to be reviewed do not violate any graph constraint rules after simulation, meaning there is no conflict between the corrected operations and the current state of the attribute graph model. At this point, the operation transformation engine outputs the final set of operations that pass the review, where all operations are in a state completely compatible with the graph constraint rules of the attribute graph model. The collaboration server then formally applies this set of operations that pass the review to the main graph state of the attribute graph model.

[0085] Through the above steps of conflict review and iterative correction, a security mechanism is added before operation and application. This mechanism can intercept secondary conflicts caused by the superposition of multiple rounds of concurrent operations or changes in the order of operations after correction, and avoid new semantic contradictions in the main graph state after correction. Overall, it ensures that the attribute graph model can maintain its medical semantic consistency in the three dimensions of existence dependency, attribute mutual exclusion, and entity protection even after multiple concurrent editing.

[0086] Furthermore, you can also view Figure 5 , Figure 5This is a schematic diagram of the transformation process for multi-person collaborative annotation operations based on the attribute graph model. Figure 5 This paper illustrates the complete processing flow of the multi-user collaborative annotation operation transformation method based on an attribute graph model provided in this application. The flow begins with the initialization of the collaborative annotation task and continues until the modified operations are applied to the attribute graph model and synchronized with each collaborative client. It covers the complete processing chain of attribute graph model construction, graph constraint rule configuration, concurrent operation reception, conflict detection and correction, and operation application. The following follows... Figure 5 The processing sequence is shown, and each processing step is explained one by one.

[0087] When the collaborative annotation task starts, the construction of the attribute graph model is performed. A medical image dataset is read, and the target object is parsed from it. Further identification of lesion entities and anatomical structures within the target object's range is then performed. Lesion entities are regions in the image exhibiting abnormal pathological features, while anatomical structures are regions in the image exhibiting normal anatomical structures. For each identified entity, a node is created in the attribute graph model. Each node is assigned a unique node identifier and configured with entity type and medical attributes. The entity type attribute distinguishes whether the node represents a lesion entity, an anatomical structure entity, or a key anatomical structure entity; medical attributes include imaging attributes extracted from the image data and clinical attributes related to diagnostic decisions. After node creation, directed edges are created between nodes with clinical relationships based on the types of clinical relationships between entities. Each directed edge is assigned a relationship type attribute and a direction attribute. Clinical relationship types include invasion relationships, blood supply relationships, lymphatic metastasis relationships, adjacency relationships, and belonging relationships. Upon completion of this processing step, an attribute graph model corresponding to the medical image data is obtained.

[0088] After the attribute graph model is constructed, the configuration phase of graph constraint rules begins. All nodes in the attribute graph model are traversed, and the entity type attribute of each node is read. Based on this attribute value, the node type of each node is determined. When the entity type attribute indicates that the node corresponds to a lesion entity, the node type is determined to be a lesion node type; when the entity type attribute indicates that the node corresponds to an anatomical structure entity, the node type is determined to be an anatomical structure node type; when the entity type attribute indicates that the node corresponds to a preset key anatomical structure entity, the node type is determined to be a key anatomical structure node type. Simultaneously, all directed edges in the attribute graph model are traversed, and the clinical relationship type attribute of each directed edge is read. Based on this attribute value, the relationship edge type of each edge is determined to be a clinical relationship edge type. After completing the above type determination, based on the node type and relationship edge type, the corresponding graph constraint rules are assigned to each node and each edge using preset medical semantic graph constraint rules. For lesion node types, the system assigns attribute mutual exclusion constraints, which limit that a node can only have one valid attribute value from the mutually exclusive attribute set at any given time. For critical anatomical structure node types, an entity protection constraint is assigned, which prevents the node from being deleted. For clinical relation edge types, an existence dependency constraint is assigned, which limits that the source node and target node connected by the edge must both exist in the attribute graph model. At the end of this processing step, each node and edge in the attribute graph model carries the graph constraint rules corresponding to its type.

[0089] During the collaborative annotation phase, communication connections are established between the collaborative server and multiple collaborative clients. Each collaborative client maintains a local copy of the attribute graph model and provides editing functions for nodes and edges to participating doctors. When a doctor performs an editing operation on their respective collaborative client, each client encapsulates the operation instruction into a standardized operation message and sends it to the collaborative server. Each operation message carries an operation type identifier, an operation object identifier, operation parameters, and a timestamp. The collaborative server queues the received operation messages in a time sequence, identifies operations that overlap in time as concurrent operations, and submits these concurrent operations to the operation transformation engine for processing.

[0090] Upon receiving concurrent operations, the operation transformation engine first determines the type of operation object targeted by each operation. Operation object types include node types and edge types. The engine parses the operation object identifier in the operation message to locate the target node or edge in the attribute graph model and reads the determined node type or relation edge type on the target object. Subsequently, the engine matches the corresponding graph constraint rules based on the operation object type. If the operation object is a lesion node type, attribute mutual exclusion constraints are matched; if the operation object is a key anatomical structure node type, entity protection constraints are matched; if the operation object is a clinical relation edge type, dependency constraints are matched. After matching the graph constraint rules, the engine simulates the graph state change results generated when all operations in the concurrent operations simultaneously apply to the attribute graph model and checks whether the results violate the matched graph constraint rules. If any graph constraint rule is violated, the engine determines that the concurrent operations are in conflict.

[0091] Upon determining a conflict, the operation transformation engine invokes the operation transformation function to modify the operation type or operation object of at least one operation in the concurrent operations. The modification can take the form of transforming the operation type into an invalid operation or redirecting the operation object. For example, when one concurrent operation deletes a target node and another creates a target edge with that target node as its endpoint, the operation transformation function, based on dependency constraints, transforms the edge creation operation into an invalid operation. Similarly, when two concurrent operations modify the same attribute of the same lesion node to two mutually exclusive attribute values, the operation transformation function, based on attribute mutual exclusion constraints, timestamps, and a merging strategy, retains one operation and transforms the other into an invalid operation.

[0092] After the operation transformation function completes the correction, the operation transformation engine performs a conflict review on the corrected operations. The conflict review process involves extracting each corrected valid operation, simulating the execution effect of the operation on the current main graph state of the attribute graph model, and checking whether the graph state after the simulation violates graph constraint rules. If a violation is found, the operation transformation engine calls the operation transformation function again for correction and resubmits the correction result for review. This review and correction process is iteratively executed until there are no conflicts between all corrected valid operations and the current state of the attribute graph model.

[0093] After all conflict re-checks pass, the collaboration server applies the corrected operations to the main graph state of the attribute graph model. For valid operations, the collaboration server performs the corresponding graph state change on the main graph state; for operations that are transformed into invalid operations, the collaboration server discards the operation. After the main graph state is updated, the collaboration server broadcasts the corrected operations to all collaboration clients, carrying the operation content and a conflict triggering reason identifier in the broadcast message. After receiving the broadcast message, each collaboration client performs a synchronous update on its local copy of the attribute graph model, ensuring that the local graph state of all clients is consistent with the main graph state, thus completing the full processing flow of this round of collaborative editing.

[0094] Furthermore, you can also view Figure 6 , Figure 6 This is a diagram illustrating the lifecycle of a graph model. Figure 6 This paper illustrates the complete lifecycle of the attribute graph model in the collaborative annotation task. The lifecycle begins with the start of the collaborative annotation task, progresses through three stages: initialization and construction, collaborative editing, and persistent saving. Upon task restart, the existing graph model is loaded to restore the state, forming a closed-loop lifecycle management system. Figure 6 The processing sequence is shown, and each stage is explained in detail.

[0095] When a collaborative annotation task is started, it is first determined whether the task is a newly created collaborative task or a continuation of an existing collaborative task. This determination is made by querying the task identifier or the graph model storage record. If there is no persistent attribute graph model file corresponding to the task in the storage, it is determined that the task is a newly created task, and the initialization and construction phase begins. If there is already a persistent attribute graph model file corresponding to the task in the storage, it is determined that the existing task is being continued, and the graph state restoration phase begins.

[0096] For newly created collaborative tasks, the initialization of the attribute graph model is performed. The system reads a medical image dataset, which can be a computed tomography (CT) sequence, magnetic resonance imaging (MRI) sequence, or positron emission tomography (PET) image. The medical image data is parsed to extract target objects and identify lesion entities and anatomical structures within the target object range. Lesion entities refer to areas in the image exhibiting abnormal pathological features, while anatomical structures refer to areas in the image exhibiting normal anatomical structures. After identifying lesion entities and anatomical structures, the system creates a node in the attribute graph model for each entity, assigns a unique node identifier to each node, and configures entity type attributes and medical attributes. Medical attributes include imaging attributes extracted from the image data and clinical attributes related to diagnostic decisions. Imaging attributes include CT values, edge features, and calcification levels of lesions in CT scans, while clinical attributes include the benign or malignant tendency of the lesion, and the T and N stages of the tumor. After completing the creation of all nodes and attribute configuration, directed edges are created between nodes with clinical relationships, based on the clinical relationships between entities. Clinical relationships include one or more of the following: invasion, blood supply, lymphatic metastasis, adjacency, and ownership. Each directed edge is assigned a relationship type attribute and a direction attribute, with the direction of the directed edge pointing from the source node to the target node. Upon completion of this step, an initial attribute graph model corresponding to the medical image data is constructed.

[0097] Simultaneously with the initial construction of the attribute graph model, graph constraint rules are configured for this model. All nodes in the attribute graph model are traversed, and the entity type attribute of each node is read. The node type is determined based on this attribute value. When the entity type attribute indicates that the node corresponds to a lesion entity, the node type is determined to be a lesion node type; when the entity type attribute indicates that the node corresponds to an anatomical structure entity, the node type is determined to be an anatomical structure node type; when the entity type attribute indicates that the node corresponds to a critical anatomical structure entity, the node type is determined to be a critical anatomical structure node type. Simultaneously, all directed edges are traversed, and the relationship edge type is determined to be a clinical relationship edge type based on the clinical relationship type attribute. After the type determination is completed, attribute mutual exclusion constraints are assigned to nodes of the lesion node type, entity protection constraints are assigned to nodes of the critical anatomical structure node type, and existence dependency constraints are assigned to edges of the clinical relationship edge type. After the above graph constraint rules are configured, the attribute graph model enters a ready state, awaiting operations from the collaborative client.

[0098] For continuing existing collaborative tasks, skip the initialization and construction process described above, and directly load the persistent file of the existing attribute graph model from storage. The persistent file stores the complete graph state of the attribute graph model, including the unique identifiers, entity type attributes, medical attributes, and node types of all nodes, as well as the relationship type attributes, direction attributes, and relationship edge types of all directed edges. It also stores the graph constraint rule information bound to each node and edge. The graph state recorded in the persistent file is then completely restored to memory, returning the attribute graph model to the state at the end of the last collaborative task. After the graph state restoration is complete, the attribute graph model also enters the ready state.

[0099] Once the attribute graph model is ready, the collaborative annotation phase begins. Multiple participating doctors connect to the collaborative server through their respective collaborative clients. Each client maintains a local copy of the attribute graph model and provides doctors with visual editing capabilities for nodes and edges. Editing operations performed by doctors on their clients are encapsulated into standardized operation messages and sent to the collaborative server. The collaborative server receives concurrently submitted operations from multiple clients, performs conflict detection, and corrects the operations based on graph constraint rules. This correction process ensures that concurrent operations do not create graph states in the attribute graph model that violate graph constraint rules. The corrected operations are applied to the main graph state of the attribute graph model, resulting in corresponding graph state changes. The collaborative server then broadcasts the corrected operations to all collaborative clients, and each client synchronously updates its local copy. This collaborative editing process is continuously executed cyclically throughout the collaborative annotation task. The state of the attribute graph model gradually evolves as doctors perform operations, but its graph structural integrity and medical semantic consistency are continuously guaranteed by graph constraint rules.

[0100] When the collaborative annotation task ends or a preset persistence trigger condition is reached, the attribute graph model is persistently saved. The persistence trigger condition can include any of the following: all collaborative clients disconnect and a preset time threshold is exceeded; a save command is received from the task initiator; or a preset timed save point is reached. The complete graph state of the current attribute graph model is serialized into a persistent file. The serialized content includes the unique identifier of all nodes, entity type attributes, medical attributes, node types and their bound graph constraints, all directed edge connections, relationship type attributes, direction attributes, relationship edge types and their bound graph constraints, as well as the version identifier and save timestamp of the current graph model. This persistent file is stored on a server or connected database for direct loading and restoration when the collaborative annotation task is resumed later. After persistence is complete, the attribute graph model enters a dormant state. When the collaborative annotation task is restarted, the corresponding persistent file is read from the database, and the graph state recovery phase begins again, starting a new lifecycle cycle.

[0101] It should be noted that the above examples are only for understanding this application and do not constitute a limitation on the multi-person collaborative annotation operation transformation method of this application. Any simple transformations based on this technical concept are all within the protection scope of this application.

[0102] This application provides a multi-user collaborative annotation operation transformation device, which includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to perform the multi-user collaborative annotation operation transformation method in the above embodiment 1.

[0103] The following is for reference. Figure 7 The diagram illustrates a structural schematic of a multi-user collaborative annotation operation transformation device suitable for implementing embodiments of this application. The multi-user collaborative annotation operation transformation device in the embodiments of this application may include, but is not limited to, mobile terminals such as mobile phones, laptops, digital broadcast receivers, PDAs (Personal Digital Assistants), PADs (Portable Application Description), etc., and fixed terminals such as digital TVs, desktop computers, etc. Figure 7 The multi-person collaborative annotation operation transformation device shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0104] like Figure 7As shown, the multi-user collaborative annotation operation transformation device may include a processing unit 1001 (e.g., a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 1002 or a program loaded from a storage device 1003 into a random access memory (RAM) 1004. The RAM 1004 also stores various programs and data required for the operation of the multi-user collaborative annotation operation transformation device. The processing unit 1001, ROM 1002, and RAM 1004 are interconnected via a bus 1005. An input / output (I / O) interface 1006 is also connected to the bus. Typically, the following can be connected to the I / O interface 1006: input devices 1007 including, for example, a touch screen, touchpad, keyboard, mouse, image sensor, microphone, accelerometer, gyroscope, etc.; output devices 1008 including, for example, a liquid crystal display (LCD), speaker, vibrator, etc.; storage devices 1003 including, for example, magnetic tape, hard disk, etc.; and communication devices 1009. Communication device 1009 allows the multi-user collaborative annotation operation transformation device to communicate wirelessly or wiredly with other devices to exchange data. While various multi-user collaborative annotation operation transformation devices are shown in the figures, it should be understood that implementation or possession of all shown is not required. More or fewer devices may be implemented alternatively.

[0105] Specifically, according to the embodiments disclosed in this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device, or installed from storage device 1003, or installed from ROM 1002. When the computer program is executed by processing device 1001, it performs the functions defined in the methods of the embodiments disclosed in this application.

[0106] The multi-user collaborative annotation operation transformation device provided in this application, employing the multi-user collaborative annotation operation transformation method in the above embodiments, can solve the technical problem that existing collaborative annotation concurrent editing cannot guarantee the clinical logical consistency and graph structural integrity of the annotation graph model. Compared with the prior art, the beneficial effects of the multi-user collaborative annotation operation transformation device provided in this application are the same as those of the multi-user collaborative annotation operation transformation method provided in the above embodiments, and other technical features in this multi-user collaborative annotation operation transformation device are the same as those disclosed in the previous embodiment method, and will not be repeated here.

[0107] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any suitable manner in one or more embodiments or examples.

[0108] The above description is merely a specific embodiment 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.

[0109] This application provides a storage medium, which is a computer-readable storage medium having computer-readable program instructions (i.e., a computer program) stored thereon, which are used to execute the multi-person collaborative annotation operation transformation method in the above embodiments.

[0110] The computer-readable storage medium provided in this application may be, for example, a USB flash drive, but is not limited to electrical, magnetic, optical, electromagnetic, infrared, or semiconductor devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), or flash memory, optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be executed by instructions, used by devices, or used in conjunction with them. The program code contained on the computer-readable storage medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, RF (Radio Frequency), etc., or any suitable combination thereof.

[0111] The aforementioned computer-readable storage medium may be included in a multi-user collaborative annotation operation transformation device; or it may exist independently and not be assembled into a multi-user collaborative annotation operation transformation device.

[0112] The aforementioned computer-readable storage medium carries one or more programs. When the aforementioned one or more programs are executed by the multi-user collaborative annotation operation transformation device, the multi-user collaborative annotation operation transformation device implements the technical content of the multi-user collaborative annotation operation transformation method embodiment shown above.

[0113] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a Local Area Network (LAN) or a Wide Area Network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0114] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of methods and computer program products according to various embodiments of this application. 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 the specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated 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 dedicated hardware-based implementations that perform the specified functions or operations, or can be implemented using a combination of dedicated hardware and computer instructions.

[0115] The modules described in the embodiments of this application can be implemented in software or hardware. The names of the modules do not necessarily limit the functionality of the unit itself.

[0116] The readable storage medium provided in this application is a computer-readable storage medium that stores computer-readable program instructions (i.e., computer programs) for executing the above-described multi-person collaborative annotation operation transformation method. This solves the technical problem that existing collaborative annotation methods cannot guarantee the clinical logical consistency and structural integrity of the annotated graph model during concurrent editing. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in this application are the same as those of the multi-person collaborative annotation operation transformation method provided in the above embodiments, and will not be elaborated upon here.

Claims

1. A method for multi-person collaborative annotation transformation, characterized in that, The method includes the following steps: Obtain the attribute graph model corresponding to the collaborative annotation task. The attribute graph model includes nodes representing entities, edges representing semantic relationships between the nodes, and graph constraint rules. Receive concurrent operations from at least two collaborative clients based on the property graph model, the concurrent operations including a first set of operations on nodes in the property graph model and / or a second set of operations on edges; When a conflict is detected in the concurrent operations, an operation transformation function is invoked based on the graph constraint rules to modify the operation type or operation object of at least one operation in the concurrent operations. The operation transformation function is an operation transformation function based on medical constraints. Apply the modified operation type or operation object to the attribute graph model; Prior to the step of obtaining the attribute graph model corresponding to the collaborative annotation task, the method further includes: Nodes are created based on lesion entities and / or anatomical structure entities in medical imaging data; Based on the clinical semantic relationships of the lesion entities and / or anatomical structure entities corresponding to the nodes, create relationship edges between the nodes; The nodes and relation edges are combined into an attribute graph model. Based on the type of the nodes and relation edges, medical semantic preset graph constraint rules are used to assign corresponding graph constraint rules to each node and each relation edge. The step of invoking an operation transformation function based on the graph constraint rules to modify the operation type or operation object of at least one operation in the concurrent operations when a conflict is detected includes: Determine the type of operation object targeted by each operation in the concurrent operations, wherein the operation object type includes node type and edge type; Match the corresponding graph constraint rules according to the type of the operation object, and determine whether the concurrent operation constitutes a conflict based on the matched graph constraint rules; If a conflict occurs, the operation transformation function is invoked to modify the operation type or operation object of at least one of the concurrent operations, so that the modified operation is compatible with the graph constraint rules.

2. The multi-person collaborative annotation operation transformation method as described in claim 1, characterized in that, The step of creating nodes based on lesion entities and / or anatomical structure entities in medical imaging data includes: The node type is determined based on the entity type attribute of the node; If the entity type attribute indicates that the node corresponds to a lesion entity, then the node is determined to be a lesion node type; If the entity type attribute indicates that the node corresponds to an anatomical structure entity, the node is determined to be a key anatomical structure node type; And, based on the types of the nodes and relation edges, the step of assigning corresponding graph constraint rules to each node and each relation edge using medical semantic preset graph constraint rules includes: Assign mutual exclusion constraints to nodes of the lesion node type; Assign solid protection constraints to nodes of the critical anatomical structure node type.

3. The multi-person collaborative annotation operation transformation method as described in claim 1, characterized in that, The step of creating relationship edges between the nodes based on the clinical semantic relationships of the lesion entities and / or anatomical structure entities corresponding to the nodes includes: Based on the clinical relationship type attribute of the relationship edge, the relationship edge is determined to be of clinical relationship edge type; The step of assigning corresponding graph constraint rules to each node and each relation edge using medical semantic preset graph constraint rules, based on the type of the node and relation edge, includes: Assign existence dependency constraints to the relation edges.

4. The multi-person collaborative annotation operation transformation method as described in claim 1, characterized in that, When the operation object type is a node type, the step of matching the corresponding graph constraint rules according to the operation object type and determining whether the concurrent operations constitute a conflict based on the matched graph constraint rules includes: If the first operation in the concurrent operations is to delete the target node and the second operation is to modify the node attribute of the target node, the modification operation of the node attribute depends on the existence of the target node based on the existence of dependency constraints, and it is determined that the first operation and the second operation constitute a conflict. The step of calling the operation transformation function to modify the operation type or operation object of at least one operation in the concurrent operations includes: changing the operation type of the second operation from modifying node attributes to an invalid operation.

5. The multi-person collaborative annotation operation transformation method as described in claim 1, characterized in that, When the operation object type is an edge type, the step of matching the corresponding graph constraint rules according to the operation object type and determining whether the concurrent operations constitute a conflict based on the matched graph constraint rules includes: If the first operation in the concurrent operation is to delete the target node and the second operation is to create a target edge with the target node as the source node or the target node, the creation operation of the target edge depends on the existence of the target node based on the existence dependency constraint, and it is determined that the first operation and the second operation constitute a conflict. The step of calling the operation transformation function to modify the operation type or operation object of at least one operation in the concurrent operations includes: changing the operation type of the second operation from creating an edge to an invalid operation.

6. The multi-person collaborative annotation operation transformation method as described in claim 1, characterized in that, Before the step of applying the modified operation type or operation object to the attribute graph model, the method further includes: Perform a conflict re-check on the corrected operation type or operation object to determine whether there are any new conflicts between the corrected operation type or operation object and the current state of the attribute graph model; If a new conflict exists, the operation transformation function is called again based on the graph constraint rules to make corrections until the corrected operation does not conflict with the current state of the attribute graph model.

7. A multi-user collaborative annotation and transformation device, characterized in that, The multi-user collaborative annotation operation transformation device stores a computer program, which, when executed by a processor, implements the multi-user collaborative annotation operation transformation method according to any one of claims 1-6.

8. A storage medium, characterized in that, The storage medium stores a computer program, which, when executed by a processor, implements the multi-person collaborative annotation operation transformation method according to any one of claims 1-6.

Images