Control methods, devices and storage media for collaborative editing

Abstract

This application discloses a control method, device, and storage medium for collaborative editing, relating to the field of online collaborative editing technology. The method includes: responding to annotation instructions for a target file, parsing the operation data corresponding to the annotation instructions to obtain an operation object based on an annotation data object; comparing the annotation primary key field of the operation object with the annotation primary keys of the operation to be processed and the applied operations to determine the target annotation primary key in a conflict state; performing a difference operation on the set of difference field keys of the update operation corresponding to the target annotation primary key to obtain a valid update operation; updating the operation object of the target file based on the valid update operation, and broadcasting the updated target file to all clients in the same session. This application solves the technical problem of poor collaborative editing performance through type-independent annotation primary key conflict determination and field-level difference set resolution technology, improves concurrent processing capabilities and system versatility, and achieves lightweight conflict resolution.

Description

Technical Field

[0001] This application relates to the field of online collaborative editing technology, and in particular to a control method, device and storage medium for collaborative editing. Background Technology

[0002] In real-time collaborative annotation of digital pathology slides and clinical teaching and diagnosis scenarios, the concurrent consistency of annotation operations, the ability to uniformly process heterogeneous objects, and the real-time nature of collaborative editing directly affect the efficiency of pathology annotation, the accuracy of annotation results, and the quality of clinical diagnosis and teaching.

[0003] In related technologies, digital pathology slide annotation is carried out by adopting traditional character-level operation transformation, full-coverage operation transformation of general data exchange format, or conflict-free copy data type scheme of non-operation transformation system. This method relies on the design of independent rules for different types, full data transmission, and single data synchronization logic. It is affected by the large number of annotation object types, complex attribute fields, and concurrent editing by multiple users, resulting in poor collaborative editing effect.

[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 control method, device and storage medium for collaborative editing, which aims to solve the technical problem of poor collaborative editing effect.

[0006] To achieve the above objectives, this application proposes a collaborative editing control method, the method comprising: In response to the annotation instructions of the target file, the operation object is obtained by parsing the operation data corresponding to the annotation instructions based on the annotation data object; Based on the annotation primary key field in the operation object, compare the annotation primary keys of the operation to be processed with those of the applied operation to determine the target annotation primary key in conflict. Perform a difference operation on the set of difference field keys of the update operation corresponding to the target annotation primary key to obtain a valid update operation including non-conflicting attributes; The operation object of the target file is updated based on the valid update operation, and the updated target file is broadcast to all clients in the same session.

[0007] In one embodiment, in response to the annotation instruction for the target file, the session permissions and data validity of the annotation instruction are verified, and the original operation data is obtained after filtering out invalid instruction fields; Extract attribute data associated with the operation from the original operation data to generate an operation metadata set; When the operation type corresponding to the annotation instruction is an update operation, the key-value pairs of the attribute fields that have actually been modified are extracted from the operation metadata set to obtain the difference field dictionary; Based on the same field specification of the general labeled data object, the operation metadata set and the difference field dictionary are mapped to the operation object with the same structure.

[0008] In one embodiment, the base version number and annotation primary key corresponding to the operation object are extracted from the operation object to be processed; Based on the base version number, a list of applied operations after the base version number is retrieved from the global operation history database; Traverse the list of applied operations, extract the annotation primary key of each applied operation, and compare the annotation primary key of each applied operation with the annotation primary key of the operation object to be processed, and obtain the matching result. When the matching result is that the primary key of the applied operation is the same as the primary key of the operation object to be processed, the primary key is marked as the target primary key in a conflict state.

[0009] In one embodiment, the set of difference field keys, including the actual modified attributes, is extracted from the operation to be processed and the corresponding applied operation, respectively. The set of difference field keys of the operation to be processed is used as the subtracted set, and the set of difference field keys of the applied operation is used as the subtracted set. A set difference operation based on field key name is performed to obtain the set of conflicting field keys. The original difference field dictionary of the operation to be processed is filtered by the set of conflict field keys, and all attribute key-value pairs that have been modified by the applied operation are removed to generate a reduced target difference field dictionary. If the target difference field dictionary is not empty, then the target difference field dictionary replaces the original difference field dictionary of the operation to be processed, resulting in the valid update operation including non-conflicting attributes.

[0010] In one embodiment, if the target difference field dictionary is empty, the target difference field dictionary is verified to confirm that the number of valid attribute key-value pairs in the target difference field dictionary is zero and there are no modified fields that have not been covered by the applied operation, and a verification result is obtained. Based on the passed verification results, the operation to be processed is marked as a no-modification operation, and the contents of the difference field dictionary of the operation are cleared to generate a no-modification operation identifier. Based on the no-operation identifier and the current latest version number, generate an operation confirmation message; The operation confirmation message is sent separately to the client that submitted the operation to be processed, completing the entire process of this no-operation, so as to ensure that the client's local version number is consistent with the server's version number.

[0011] In one embodiment, the target difference field dictionary carried by the non-empty valid update operation is applied to the annotation data object corresponding to the target file to obtain the updated annotation data object; Write the updated labeled data object and the valid update operation to persistent storage, and associate the incremented new version number with this operation to obtain the operation record; Based on the operation record, all redundant fields that have not changed are removed, and a synchronous broadcast message including the modified attributes is generated; The synchronous broadcast message is sent in parallel to all online clients in the same session, and an operation confirmation message carrying the latest version number is sent separately to the client that submitted the operation.

[0012] In one embodiment, all attribute fields of all heterogeneous annotation types in the target scene are collected, and duplicate attributes are deduplicated and integrated to obtain a complete set of attributes that covers all annotation requirements; Based on the complete set of attributes, a unified labeled data object is constructed, and common attribute fields are defined; A mapping relationship is constructed between heterogeneous annotation types and the general attribute fields. The heterogeneous annotation types are matched with corresponding attribute subsets, and a unified default value is preset for all inapplicable attribute fields to obtain the initial attribute model. Configure the conflict determination rules of the operation transformation engine for the initial attribute model, and set the engine to only read the annotation primary key and general attribute field key name during the conflict detection and resolution process to obtain the annotation attribute model.

[0013] In one embodiment, the behavioral logic of all annotation operations in the target scene is analyzed, and four basic operation types and two auxiliary operation types are divided into an operation type set that covers all annotation requirements; Based on the base version number and the annotation primary key, a consistent unified message structure framework is designed for all operation types in the set of operation types. Based on the unified message structure framework, a dedicated structure specification for the difference field dictionary is defined separately for update operations, generating an operation structure system with difference field constraints; Based on the aforementioned operation structure system, the type mapping rules of the operation parsing engine are configured, the correspondence between various client annotation instructions and unified operation types and message structures is constructed, and the operation parsing rule configuration is generated.

[0014] In addition, to achieve the above objectives, this application also proposes a collaborative editing control device, which includes: 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 collaborative editing control 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 which, when executed by a processor, implements the steps of the collaborative editing control method described above.

[0016] This application provides a collaborative editing control method, which includes constructing a general annotation attribute model with type erasure capability and a unified operation type system. In response to the annotation instructions of the target file, the corresponding operation data is parsed into operation objects with consistent structure. The conflict state is determined by comparing the annotation primary key field of the operation object with the annotation primary key of the operation to be processed and the applied operation. A pure key-name difference set operation is performed on the difference field key set of the conflict update operation to obtain a valid update operation containing only non-conflicting attributes. Finally, the target file is updated based on the valid update operation and broadcast to all clients in the same session. This solution solves the technical problems in traditional multi-user collaborative annotation systems, such as the exponential growth of conflict determination rules with the number of annotation types due to heterogeneous annotation types, excessive bandwidth consumption for full data transmission, low efficiency in concurrent conflict handling, and poor system scalability. It improves the system's concurrent processing capability and cross-annotation type universality, reduces network transmission bandwidth consumption, achieves lightweight conflict resolution with a single set of rules adaptable to all annotation types, and ensures data consistency and real-time operation during multi-user collaborative annotation.

[0017] In summary, this application solves the technical problem of poor collaborative editing performance by using type-independent annotation primary key conflict determination and field difference set resolution technology, improves concurrent processing capabilities and system versatility, achieves lightweight conflict resolution, ensures data consistency and reduces bandwidth consumption. 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 collaborative editing control method of this application; Figure 2 This is a schematic diagram of the system architecture of this application; Figure 3 This is a field mapping matrix diagram of the general annotation attribute model of this application; Figure 4 This is a diagram showing the message type structure of this application; Figure 5 This is a flowchart of the field difference set operation in this application; Figure 6 This is a flowchart illustrating the fifth embodiment of the collaborative editing control method of this application; Figure 7 This is a schematic diagram of the operation transformation rule matrix of this application; Figure 8 A schematic diagram illustrating the timing interactions of multiple people concurrently editing the same annotation in this application; Figure 9 This is a flowchart illustrating the eighth embodiment of the collaborative editing control method of this application; Figure 10 This is a schematic diagram of the control device that was collaboratively edited for 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 related technologies, digital pathology slide annotation is carried out by adopting traditional character-level operation transformation, full-coverage operation transformation of general data exchange format, or conflict-free copy data type scheme of non-operation transformation system. This method relies on the design of independent rules for different types, full data transmission, and single data synchronization logic. It is affected by the large number of annotation object types, complex attribute fields, and concurrent editing by multiple users, resulting in poor collaborative editing effect.

[0024] This application provides a solution: First, in response to the annotation instructions of the target file, based on the annotation data object, the operation data corresponding to the annotation instructions is parsed to obtain the operation object. Then, based on the annotation primary key field in the operation object, the annotation primary keys of the operation to be processed and the applied operations are compared to determine the target annotation primary key in a conflict state. Then, a difference operation is performed on the difference field key set of the update operation corresponding to the target annotation primary key to obtain a valid update operation including non-conflicting attributes. Finally, the operation object of the target file is updated based on the valid update operation, and the updated target file is broadcast to all clients in the same session.

[0025] It should be noted that the executing entity in this embodiment can be a computing service device with data processing, network communication, and program execution functions, such as a tablet computer, personal computer, or mobile phone, or an electronic device or collaborative editing control device capable of performing the above functions. The following description uses a collaborative editing control device as an example to illustrate this embodiment and the subsequent embodiments.

[0026] 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.

[0027] This application provides a collaborative editing control method, referring to... Figure 1 , Figure 1 This is a flowchart illustrating the first embodiment of the collaborative editing control method of this application.

[0028] In this embodiment, the collaborative editing control method includes steps S10 to S40: Step S10: In response to the annotation instructions of the target file, based on the annotation data object, parse the operation data corresponding to the annotation instructions to obtain the operation object.

[0029] Annotation commands are the core control instructions that trigger collaborative annotation tasks, instructing the system to perform annotation modification operations on target files. Annotation data objects are standardized data structures built upon a universal annotation attribute model, uniformly describing all heterogeneous annotation types. Operation objects are standardized operation data units generated after parsing, with completely consistent structures, containing all the core information required to perform annotation operations. For example, operation objects include a unique operation identifier, operation type identifier, target annotation primary key, base version number, and a dictionary of difference fields.

[0030] In this embodiment, the aforementioned annotation instructions can be triggered in three ways. First, user-initiated triggering: the user performs operations such as drawing annotations, modifying attributes, and deleting annotations through the system's interactive interface. The system captures the user's actions in real time and generates corresponding annotation instructions for immediate annotation modification tasks. Second, batch import triggering: when a user imports external files containing annotation data in batches, the system automatically parses the annotation content in the external files and generates corresponding new annotation instructions line by line for synchronous processing of batch imported annotation data. Third, historical operation replay triggering: when a user performs an undo or redo operation, the system extracts the corresponding operation data from the historical operation record and generates undo annotation instructions in reverse or redo annotation instructions in forward, for the retrospection and restoration of historical operations.

[0031] Once the collaborative editing control device receives the annotation instruction, it begins to parse and process the operation data corresponding to the annotation instruction based on the established general annotation attribute model and unified operation type system.

[0032] For example, there are two methods for parsing operation data. The first is full metadata synchronous parsing. Before the parsing process officially starts, the complete message header of the annotation instruction is read to obtain the operation type identifier and target file identifier. Then, all operation data carried by the instruction is read, and the unique operation identifier, target annotation primary key, base version number, and all attribute data are extracted at once. At the same time, for update operations, the actual modified attribute fields are extracted to generate a dictionary of difference fields. Finally, all extracted information is mapped to standard operation objects. This method has a simple and stable parsing logic, is less prone to data loss or parsing errors, and can provide complete and reliable operation data for subsequent conflict determination.

[0033] The second method is incremental streaming asynchronous parsing. During the transmission of annotation instructions, incremental parsing is performed simultaneously with the received instruction data. First, the message header is parsed to obtain the operation type identifier and target file identifier. Then, the operation data is parsed segment by segment, extracting the unique operation identifier, target annotation primary key, and base version number in sequence. After the attribute data transmission is completed, the actually modified attribute fields are incrementally extracted to generate a dictionary of difference fields. Finally, all parsing results are summarized to generate a standard operation object. This method is executed synchronously with the instruction transmission process, without requiring additional pre-processing time. It can make full use of idle network transmission periods to complete parsing, significantly improving instruction processing efficiency in high-concurrency scenarios.

[0034] Once the original operation data of the annotation instructions is obtained, the corresponding parsing rules can be generated based on the following methods.

[0035] In one alternative approach, a pre-set set of fixed parsing rules is retrieved. This set stores standardized parsing rules applicable to all operation and annotation types. Based on the operation type identifier of the annotation instruction, the corresponding pre-set parsing rule is directly matched and retrieved for subsequent operation data parsing. This method is logically simple and stable, with unified and controllable rules. It requires no additional adaptation calculations, can quickly determine the parsing rules, and is suitable for conventional annotation scenarios with high response speed requirements.

[0036] In another alternative approach, the operation type identifier and target annotation type information of the annotation instruction are first extracted. Simultaneously, the latest field specifications of the general annotation attribute model are extracted. Then, parsing rules optimized based on historical parsing tasks are retrieved from the rule base to dynamically generate customized parsing rules adapted to the current instruction. The feasibility of the generated parsing rules is verified to ensure they can correctly parse all operation data carried by the current instruction. After verification, these rules are used as the parsing rules for parsing the current operation data. This method can flexibly generate customized parsing rules that fit the current instruction and attribute model, without relying on fixed preset templates. It offers higher adaptation accuracy, supports the parsing of newly added annotation types and extended attribute fields, and improves the system's scalability.

[0037] In an exemplary scheme for defining the operation object, the pre-built general annotation attribute model and unified operation type system are first loaded to obtain the latest attribute field specifications and operation structure specifications. Then, instruction validity is validated, checking the session permissions, format integrity, and data validity of the annotation instructions. Invalid instructions are filtered out, and the validated raw operation data is output. Next, from the validated raw operation data, the operation unique identifier, operation type identifier, target annotation primary key, base version number, and operation-related attribute data are extracted to generate a structured operation metadata set. When the operation type is an update operation, only the key-value pairs of attribute fields that have actually been modified are extracted from the operation-related attribute data to generate a difference field dictionary that does not contain unmodified attributes. Finally, based on the unified field specifications of the general annotation data object, the structured operation metadata set and the difference field dictionary are mapped to a standard operation object with a completely consistent structure, completing the parsing of the annotation instructions.

[0038] It should be noted that in some special cases, if the operation data carried by the annotation instruction is empty, a standard operation object marked as empty will be directly generated, and subsequent conflict determination and update operations will not be performed.

[0039] Step S20: Based on the annotation primary key field in the operation object, compare the annotation primary keys of the operation to be processed with those of the applied operation to determine the target annotation primary key that is in conflict.

[0040] The primary key field for annotations is a unique field used to uniquely identify each annotation object and is the sole basis for conflict determination. Pending operations refer to annotation operations currently being processed and submitted by the client. Applied operations refer to annotation operations that have been successfully written to persistent storage and synchronized to the global version. The target annotation primary key is the unique identifier of the annotation object that conflicts with the pending operations.

[0041] In this embodiment, the conflict determination operation can be performed in three ways. First, a single-operation sequential comparison: when a single operation to be processed is received, the conflict determination process is initiated, comparing the labeled primary key of the operation to be processed with the labeled primary keys of all applied operations to determine if a conflict exists. This method has a fast response time and is suitable for real-time processing scenarios of single operations. Second, a batch operation batch comparison: when a batch operation request consisting of multiple operations to be processed is received, the labeled primary keys of all operations to be processed are first extracted to generate a set of primary keys to be compared, and then a batch comparison is performed with the set of labeled primary keys of applied operations to determine all conflicting target labeled primary keys at once. This method has high processing efficiency and is suitable for batch operation scenarios such as batch import and batch modification. Third, an incremental operation stream real-time comparison: the system maintains a continuously updated applied operation stream. When an operation to be processed enters the processing queue, its labeled primary key is compared in real-time with the labeled primary keys of the most recently specified number of applied operations in the operation stream to determine if a conflict exists. This method has low resource consumption and is suitable for high-concurrency continuous operation scenarios.

[0042] For example, there are two methods for comparing primary keys. The first method is fast primary key hash comparison. Before the conflict determination process officially starts, the primary keys of all applied operations are converted into corresponding hash values ​​and stored in a hash table. When an operation to be processed is received, the hash value of the primary key of the operation is calculated, and the search is performed directly in the hash table. If the search is successful, a conflict is determined. This method is extremely fast, with a time complexity of O(1), which can significantly improve the efficiency of conflict determination in high-concurrency scenarios.

[0043] The second method is version range inverted index comparison. The system builds a corresponding labeled primary key inverted index for each version number, recording all labeled primary keys of operations applied under that version number. When an operation to be processed is received, the system determines the version range to be compared based on its underlying version number. Then, it extracts the labeled primary keys of all applied operations within that version range from the inverted index and compares them with the labeled primary key of the operation to be processed. This method eliminates the need to traverse all applied operations; it only compares operations within a specified version range, reducing the amount of data compared and improving the efficiency of conflict detection.

[0044] Once the set of labeled primary keys for the operation to be processed and the set of labeled primary keys for the applied operation are obtained, conflict determination can be performed in the following manner.

[0045] In one alternative approach, a strict exact match rule is employed. A conflict is only identified when the primary key of the annotation to be processed is exactly the same as the primary key of the annotation of an already applied operation, and the original annotation key is then marked as the target annotation key. This method is simple and clear, less prone to misjudgment, ensures data consistency, and is suitable for most common annotation scenarios.

[0046] In another optional approach, a related primary key matching rule is employed. Besides matching the primary keys of the annotations that are exactly the same, it also compares the primary keys of annotations that are related to the primary key of the operation to be processed, such as parent annotation primary keys, child annotation primary keys, and grouping annotation primary keys. If an applied operation with a matching related primary key exists, it is determined that there is a conflict, and the related primary key is also marked as the target annotation primary key. This method can handle annotation conflicts with hierarchical or grouping relationships, avoiding inconsistencies in hierarchical data and adapting to complex structured annotation scenarios.

[0047] In an exemplary scheme for determining the target annotation primary key, the base version number and the target annotation primary key are first extracted from the parsed operation object to be processed, without reading any annotation type-related information. Then, based on the extracted base version number, a list of all persistent applied operations after that base version number is retrieved from the global operation history database. Next, the list of applied operations is traversed, and the annotation primary key of each applied operation is extracted and compared bit-by-bit with the target annotation primary key of the operation to be processed. When an applied operation with a completely matching annotation primary key is detected, the matching annotation primary key is marked as a conflicting target annotation primary key. Finally, all marked target annotation primary keys are aggregated to generate a conflict annotation primary key set, completing the conflict determination.

[0048] It should be noted that in some special cases, if there are no applied operations after the base version number, it is directly determined that there is no conflict, the subsequent difference operation steps are skipped, and the operation to be processed is directly regarded as a valid update operation.

[0049] Step S30: Perform a difference operation on the set of difference field keys of the update operation corresponding to the target annotation primary key to obtain a valid update operation including non-conflicting attributes.

[0050] The set of difference field keys refers to the set of key names of the attribute fields that were actually modified in the update operation. The difference operation is a pure set operation based solely on field key names, used to extract attribute fields in the pending operation that were not modified by the applied operation. A valid update operation is an update operation generated after conflict resolution, containing only non-conflicting attributes, and can be safely applied to the target file.

[0051] In this embodiment, the above-mentioned difference operation can be performed in three ways. The first is a single-field successive difference operation. When a single target label primary key exists, the difference field key sets between the operation to be processed and the applied operation are extracted separately. Each field key name is compared, and the unique field key names in the operation to be processed are extracted to generate a set of non-conflicting field keys. This method is logically simple and suitable for processing single conflicting operations. The second is a multi-field batch difference operation. When multiple target label primary keys exist, the difference field key sets between the operation to be processed and the applied operation corresponding to each target label primary key are extracted separately. Then, the difference operation is performed in batches to generate a set of non-conflicting field keys corresponding to all target label primary keys. This method has high processing efficiency and is suitable for batch processing scenarios with multiple conflicting operations. Thirdly, there is the field dependency chain difference operation. When there is a field dependency relationship, the dependency relationship chain between attribute fields is first constructed. Then, when performing the difference operation, the conflict state of the dependent fields is considered at the same time. If there is a conflict between the dependent fields, the dependent fields are also removed from the set of difference field keys to be processed. This method can handle the conflict of attribute fields with dependency relationships and avoid the problem of inconsistent data logic.

[0052] For example, the difference operation can be performed in two ways. The first is a pure key-name set difference operation. Before the difference operation process officially starts, the difference field key sets containing only the actual modified attributes are extracted from the update operation to be processed and the corresponding applied update operation, respectively, without reading any attribute values ​​or annotation type information. Then, using the difference field key set of the update operation to be processed as the subtracted set and the difference field key set of the applied update operation as the subtracted set, a pure set difference operation based only on field key names is performed to obtain the non-conflicting field key set. This method is extremely fast, independent of annotation type and attribute value, and achieves true type-independent conflict resolution.

[0053] The second method is historical operation backtracking difference operation. When performing the difference operation, it not only compares the set of difference field keys for the currently applied operations, but also backtracks to the set of difference field keys for all applied operations targeting the primary key of this target annotation since the base version number. It merges all modified field key names into a complete set of modified field keys, and then performs the difference operation with the set of difference field keys for the operation to be processed. This method can handle situations where multiple applied operations modify different fields of the same annotation, ensuring that all modified fields are correctly excluded and avoiding data overwriting issues.

[0054] Once the set of non-conflicting field keys is obtained, a valid update operation can be generated based on the following method.

[0055] In one alternative approach, a field filtering generation method is used. This method filters the original difference field dictionary of the update operation to be processed using a set of non-conflicting field keys, removing all attribute key-value pairs modified by applied operations, and generating a reduced difference field dictionary. This reduced difference field dictionary then replaces the original difference field dictionary of the update operation, preserving other metadata such as operation type and target annotation primary key, thus generating a valid update operation containing only non-conflicting attributes. This method has simple generation logic, low computational load, and fast execution speed, making it suitable for most common conflict resolution scenarios.

[0056] In another alternative approach, an operation merging generation method is used. This method merges the non-conflicting attributes of the update operation to be processed with the attributes of the already applied operations, generating a merged update operation that includes all the latest modifications. The validity of the merged update operation is then verified to ensure that the merged attribute data does not have logical conflicts. After verification, it is considered a valid update operation. This method can merge the modifications of multiple operations into one, reducing the number of operation records, improving the efficiency of subsequent data synchronization, and adapting to scenarios where multiple operations modify different fields of the same annotation.

[0057] In an exemplary scheme for determining valid update operations, firstly, from the pending update operations in a conflicting state and their corresponding applied update operations, extract sets of difference field keys containing only the actually modified attributes, without reading any attribute values ​​or annotation type information. Then, using the set of difference field keys for the pending update operations as the subtracted set and the set of difference field keys for the applied update operations as the subtracted set, perform a pure set difference operation based only on field key names to obtain a set of non-conflicting field keys. Next, use the set of non-conflicting field keys to filter the original difference field dictionary of the pending update operations, removing all attribute key-value pairs modified by the applied operations, generating a reduced target difference field dictionary. Finally, verify whether the reduced target difference field dictionary is empty. If it is empty, generate a valid update operation marked as an empty operation; if it is not empty, replace the original difference field dictionary of the pending update operations with this dictionary to generate a valid update operation containing only non-conflicting attributes.

[0058] It should be noted that in some special cases, if the reduced target difference field dictionary is empty, a valid update operation marked as an empty operation will be generated, which will not produce any persistence effect, but will still send a confirmation message back to the committing client and carry the current server version number.

[0059] Step S40: Update the operation object of the target file based on the valid update operation, and broadcast the updated target file to all clients in the same session.

[0060] Synchronous broadcast messages are standardized messages used to synchronize updated annotation data to all clients. All clients in the same session refer to all client devices that simultaneously open the same target file for collaborative editing.

[0061] In this embodiment, the above update and broadcast operations can be performed in three ways. First, atomic full update broadcast: the effective update operation is atomically applied to the operation object of the target file, generating an updated complete annotation data object, which is then broadcast to all clients in the same session. This method is logically simple, has high data consistency, and is suitable for scenarios with small file sizes. Second, incremental difference update broadcast: the effective update operation is atomically applied to the operation object of the target file, generating an updated annotation data object, and then only the attribute fields that changed in this update are extracted to generate incremental difference messages, which are broadcast to all clients in the same session. This method has low network transmission volume and is suitable for scenarios with large file sizes or high concurrency. Third, hierarchical priority broadcast: based on the client's online status and operation permissions, clients are divided into different priority levels. Update messages are sent first to high-priority clients (such as the client that submitted the operation), and then to low-priority clients. This method ensures that the client that submitted the operation receives the fastest response, improving the user experience.

[0062] For example, there are two ways to update the target file operation object. The first is an atomic transaction update. Before the update process officially starts, a database transaction is initiated. Then, the reduced difference field dictionary carried by the valid update operation is applied to the unified annotation data object corresponding to the target file, generating the updated annotation data object. Next, the updated annotation data object and the complete valid update operation are atomically written to persistent storage, and the global version number is incremented synchronously and associated with the new version number of this operation. Finally, the database transaction is committed to complete the update operation. This method can guarantee the atomicity of the update operation and avoid data inconsistency problems caused by partial updates.

[0063] The second method is incremental update via version chain. The system maintains a version chain for the target file, where each version records the incremental changes made by that version relative to the previous version. When a valid update operation is received, it is added to the version chain as a new version, and the global version number is incremented and associated with the new version number. This method does not require modification of historical version data, supports the rollback and recovery of historical versions, and improves the system's data security and traceability.

[0064] Once the target file operation object has been updated, a broadcast operation can be performed in the following manner.

[0065] In one alternative approach, a full synchronous broadcast method is used. A full synchronous broadcast message is generated based on the updated complete labeled data object, and then sent in parallel to all online clients in the same session. Simultaneously, an operation confirmation message carrying the latest global version number is sent individually to the client that submitted the operation. This method is logically simple, eliminates the need for complex incremental merging operations on the client, and is suitable for scenarios with low client performance.

[0066] In another alternative approach, incremental differential broadcasting is employed. Based on the valid update operation and the latest global version number, a lightweight synchronous broadcast message containing only the modified attributes is generated. All redundant fields that have not changed are removed. This lightweight synchronous broadcast message is then sent in parallel to all online clients in the same session. Simultaneously, an operation confirmation message carrying the latest global version number is sent separately to the client that submitted the operation. This method involves minimal network transmission, significantly reducing network bandwidth consumption and improving broadcast efficiency in high-concurrency scenarios.

[0067] In an exemplary scheme for performing updates and broadcasts, a non-empty valid update operation is first received. The reduced difference field dictionary carried by this operation is applied to the unified annotation data object corresponding to the target file, generating an updated annotation data object. Then, a database transaction is initiated, atomically writing the updated annotation data object and the complete valid update operation to persistent storage. The global version number is synchronously incremented, and the new version number is uniquely associated with this operation, resulting in a complete operation record with a version identifier. Next, the database transaction is committed, completing the update of the target file operation object. Then, based on the updated annotation data object and the latest global version number, a lightweight synchronous broadcast message containing only the modified attributes is generated, removing all unchanged redundant fields. Finally, the synchronous broadcast message is sent in parallel to all online clients in the same session, while a separate operation confirmation message carrying the latest global version number is sent to the client that submitted this operation.

[0068] It should be noted that in some special cases, if the valid update operation is empty, the update and broadcast operations on the target file operation object will not be executed. Instead, an operation confirmation message carrying the current global version number will be sent separately to the client that submitted the operation to ensure that the client's local version number is consistent with that of the server.

[0069] Further, please refer to Figure 2 , Figure 2This is a schematic diagram of the system architecture of this application. A multi-user collaborative annotation system based on Operational Transformation (OT) adopts a three-layer architecture: a Vue 3 client, an ASP.NET Core 8 server, and a data storage layer. The client and server establish bidirectional communication via the WebSocket protocol, and the server accesses the data storage layer through read / write (R / W) operations. The client implements drawing and editing of 16 heterogeneous annotation types based on Canvas, submits operations via WebSocket, and manages local state based on Pinia. Upon reconnection, incremental operations are retrieved through Catchup requests to complete the state. The server consists of a WebSocket processor, an OT transformation engine (core, including the OT server state OTServerState and the OT session manager OTSessionManager), an annotation persistence service, and a Ticket authentication middleware. The data storage layer provides JSON file storage, PostgreSQL database storage, V2.1 format compatibility, and operation log persistence capabilities. The system abstracts 16 annotation types into a unified annotation data object (AnnotationData) containing 15+ general attribute fields through a general annotation attribute model, achieving type erasure and rule convergence. Operation transformations only need to handle 16 operation combinations and are independent of the number of annotation types. Adding new annotation types does not require modification of the backend code. The OT transformation engine uses field-level difference operations to ensure that Update operations only transmit the difference fields, reducing data volume by 60%-90% and increasing the retention rate of non-overlapping concurrent editing intents from 0% to 100%. It also integrates batch delete list difference processing, server-side undo / redo inverse operation mapping, and noop (no operation) version number feedback mechanism. The communication protocol stack adopts native WebSocket, JSON message encoding, ticket authentication, sharded reassembly array pool, and parallel broadcast sending lock (Send). Lock's layered design enables lightweight conflict resolution, high-concurrency processing, and cross-platform compatibility. It solves the problems of complex heterogeneous type adaptation, high bandwidth consumption, and inefficient concurrent conflict handling in traditional collaborative annotation systems, providing an efficient and stable solution for multi-person cross-regional collaborative annotation.

[0070] Second Embodiment This embodiment provides an exemplary scheme for generating operation objects based on annotation instructions. In this example, the session permissions and data validity of the annotation instructions corresponding to the target file are first verified, and invalid instruction fields are filtered to obtain the original operation data. Then, attribute data is extracted from the original operation data to generate an operation metadata set. For update operations, modification fields are extracted separately to construct a difference field dictionary. Finally, operation objects with a standard structure are obtained by mapping according to the unified field specification of general annotation data objects. Step S10 includes steps A11 to A14: Step A11: In response to the annotation instruction for the target file, verify the session permissions and data validity of the annotation instruction, filter invalid instruction fields, and obtain the original operation data.

[0071] Step A12: Extract the attribute data associated with the operation from the original operation data to generate an operation metadata set.

[0072] Step A13: When the operation type corresponding to the annotation instruction is an update operation, extract the key-value pairs of the attribute fields that have actually been modified from the operation metadata set to obtain the difference field dictionary.

[0073] Step A14: Based on the same field specification of the general labeled data object, map the operation metadata set and the difference field dictionary to the operation object with the same structure.

[0074] Session permissions are the access verification criteria used to determine whether the current client has the qualification to collaboratively edit the target file, and are used to intercept illegal operation requests across sessions or without proper permissions. Data validity is the verification standard used to determine whether the instruction format, field integrity, and data values ​​conform to the system's preset rules, and is used to remove invalid data with distorted formats or missing fields. Raw operation data is the valid instruction data remaining after permission and validity verification and the removal of invalid fields; it is the basic data unit for extracting various operation information. The operation metadata set is a structured data set extracted from the raw operation data, containing the core identifier and basic attributes of the operation, and carrying key information such as operation type, primary key, and version number.

[0075] The difference field dictionary is a data set that only includes key-value pairs of attribute fields that have actually changed during the update operation. Unlike the full attribute data, it effectively reduces the amount of data transmitted. Operation objects are operation data units generated according to a unified specification and with a completely standardized structure, compatible with all heterogeneous annotation types and various operation behaviors. The general annotation data object is a standardized data model built based on the type erasure approach, abstracting sixteen types of heterogeneous annotations into fifteen general attribute fields. It serves as the unified reference standard for mapping all operation objects. For example, session permissions include session identity, file editing permissions, and operation scope permissions; data validity includes message format verification, field value range verification, and annotation primary key uniqueness verification; the operation metadata set includes operation unique identifier, operation type identifier, target annotation primary key, and base version number; the difference field dictionary includes key-value pairs of modified attribute fields such as line color, font size, and fill transparency; and the general annotation data object covers fifteen general attribute fields such as annotation type identifier, coordinate point sequence, rotation angle, and annotation description.

[0076] In this example, when responding to annotation instructions and performing validation filtering to obtain the original operation data, the method of synchronous validation of full metadata can be referenced. Alternatively, a streaming incremental validation method can be used to complete permission verification and legality determination segment by segment during the network transmission of annotation instructions, filtering invalid fields while outputting valid content, accumulating to obtain complete original operation data, thereby completing the collection of original operation data.

[0077] After collecting the original operation data, the attribute data extraction process is initiated. Various attribute data associated with the operation are extracted one by one from the original operation data, and after being summarized and organized, an operation metadata set is generated. Then, the corresponding operation type is identified based on the operation metadata set. If it is determined to be an update operation, the attribute field key-value pairs that were actually modified in this operation are further filtered out and a difference field dictionary is generated. Finally, based on the unified field specification of the general annotation data object, the operation metadata set and the difference field dictionary are format-mapped and structure-aligned to generate a standardized operation object that can be used by all annotation types and all operation types. In this way, through the layered processing logic of pre-permission verification, difference field extraction, and unified model mapping, the type erasure of heterogeneous annotation types is achieved, reducing the computational complexity of subsequent conflict determination and operation transformation, while reducing invalid data transmission and improving the overall efficiency of instruction parsing in high-concurrency scenarios.

[0078] For example, there are two ways to generate operation objects from the operation metadata set and the difference field dictionary mapping. The first method, based on the transmission sequence and field arrangement order of the original operation data, starts with the first field of the operation metadata set and compares each metadata field with the standard fields of the general annotation data object one by one. After completing a single field mapping, it proceeds to the next field sequentially until all metadata fields are matched. If the current operation type is an update operation, each key-value pair in the difference field dictionary is synchronously mapped to the corresponding position in the general attribute field, maintaining the serial execution logic of field parsing, matching, and mapping throughout. After all field mapping is completed, all mapping results are integrated to generate a final operation object with a consistent structure. This method uses a time-locked, field-by-field serial matching and step-by-step mapping execution logic, strictly following the data arrangement order of the original instruction to complete the parsing transformation. The field matching logic is simple and controllable, and problems such as field misalignment and data omission are less likely to occur, making it suitable for parsing scenarios of conventional single annotation instructions.

[0079] The second approach is a categorized, layered, parallel parsing method. First, the operation metadata set is divided into several independent data layers based on data usage: operation identifier layer, version information layer, and basic annotation attribute layer. Simultaneously, the difference field dictionary is divided into a separate change attribute layer. There are no parsing dependencies between the layers. Then, parallel parsing and field matching are initiated synchronously for all divided data layers. Within each data layer, fields are quickly matched and format-converted with corresponding standard fields of the general annotation data object. After all parallel parsing and matching work for all data layers is completed, the mapping results of each layer are summarized and the overall structure is assembled to form a complete operation object. This method employs a data layering and fully layered parallel parsing execution logic. By separating the relationships between different types of fields through pre-layering, it fully utilizes parallel computing capabilities to improve parsing speed, reduces the time consumption caused by single-field serial processing, and adapts to complex application scenarios such as batch annotation commands and high-concurrency simultaneous parsing of multiple operations.

[0080] Further, please refer to Figure 3 , Figure 3This is a field mapping matrix diagram of the general annotation attribute model in this application. A unified annotation attribute model construction and application scheme is proposed. This scheme constructs a set of 15+ general attribute fields, including annotation type identifier (Type), name / text content (Name), hierarchical grouping (Part Of Group), coordinate point sequence (Coordinates), line color (Line Color), line width / point radius (Line Width), font size (FontSize), font color (Font Color), fill background color (Fill Background Color), fill opacity (Opacity), rotation angle (Rotate Angle), area (Area), description (Description), extended tag (Tag), and associated image (Image Id). This enables unified modeling of 16 heterogeneous annotation types, such as rectangles, ellipses, polygons, arrows, scale bars, text, lines, circles, angles, concentric circles, flags, polylines, closed curves, free curves, wands, solid circles, and points. Each annotation type selects appropriate attribute fields as needed (e.g., text annotations use font size and font color fields, filled annotations use fill background color fields). The model uses fields such as Color and Opacity for annotations, Rotation Angle for rotation annotations, and Area for area calculation annotations. All annotations share common fields such as Description, Tag, and Image ID. Inapplicable attribute fields retain default values ​​and are omitted during serialization, achieving type erasure and rule convergence. Operation transformation rules only need to handle fixed operation combinations unrelated to the number of annotation types. When adding a new annotation type, the backend transformation code does not need to be modified. Furthermore, based on this model, conflict determination and operation transformation are processed only based on the annotation primary key and common attribute field key names, without reading the annotation type identifier (Type) field. This ensures the preservation of concurrent editing intent and data consistency between different annotation types, solving the problems of complex heterogeneous annotation type adaptation and conflict rules growing with the number of types in traditional collaborative annotation systems. It provides a highly scalable and loosely coupled basic data model support for multi-person collaborative annotation.

[0081] Third Embodiment This embodiment provides an exemplary scheme for identifying conflicting annotation primary keys. In this example, the base version number and annotation primary key are first extracted from the operation object to be processed. Based on the base version number, the list of applied operations within the corresponding version range is retrieved. Then, the annotation primary keys of the operations in the list are extracted item by item, and a bit-by-bit comparison is performed to obtain the matching result. Finally, the target annotation primary key in a conflicting state is accurately marked based on the matching result. Step S20 includes steps B11 to B14: Step B11: Extract the base version number and annotation primary key corresponding to the operation object from the operation object to be processed.

[0082] Step B12: Based on the base version number, retrieve the list of applied operations after the base version number from the global operation history database.

[0083] Step B13: Traverse the list of applied operations, extract the primary key of each applied operation, and compare the primary key of each applied operation with the primary key of the operation object to be processed, and obtain the matching result.

[0084] Step B14: When the matching result is that the primary key of the applied operation is the same as the primary key of the operation object to be processed, mark the primary key as the target primary key in a conflict state.

[0085] The base version number is the version identifier carried by the client when submitting annotation operations. It is used to define the last node where the client's local data and the server have completed data synchronization, and is the core basis for limiting the scope of operation retrieval and narrowing the comparison interval. The global operation history database is a storage unit used by the server to uniformly store all executed and persisted annotation operation records, completely retaining the version information, primary key information, and operation content of all operations throughout the session. The applied operation list is an ordered data list composed of all committed operations with version numbers later than the base version number, and is the data source for primary key comparison. The matching result is the consistency judgment conclusion obtained after comparing the two sets of annotation primary keys character by character, used to distinguish between primary key overlap and primary key differences. The target annotation primary key is the identifier of the annotation object confirmed by comparison to have conflicts caused by multiple concurrent editing, and is the core processing object for subsequent field difference operations and conflict resolution. For example, the base version number is a numerical code that increments sequentially according to the order of operation execution; the annotation primary key is a globally unique string code, with each annotation corresponding to a unique primary key; the global operation history database uniformly stores all types of operation records, including addition, deletion, update, batch deletion, undo, and redo; the list of applied operations is arranged sequentially according to the actual execution time of the operations; the matching results are divided into two categories: those with completely identical primary keys and those with inconsistent primary keys; the target annotation primary key will be extracted separately and entered into the subsequent conflict handling process.

[0086] In this example, when retrieving the list of applied operations based on the base version number, the method of searching the entire version range can be used. Alternatively, a streaming incremental search method can be used, reading data from the global operation history database segment by segment in ascending order of version number, filtering operation records with version numbers greater than the base version number as it reads, and gradually summarizing and piecing together to form a complete list of applied operations, thereby completing the collection of the list of applied operations.

[0087] After collecting the list of applied operations, the annotation primary key comparison process is initiated. For each operation in the list of applied operations, the corresponding annotation primary key is extracted sequentially. This primary key is then compared character by character with the annotation primary key of the operation to be processed, and a matching result is generated. The matching result is then judged. If two sets of annotation primary keys are completely identical, the primary key is marked as the target annotation primary key. In this way, through the layered processing logic of version range limitation, ordered traversal, and precise character-by-character comparison, conflict screening is carried out only for operations within the valid version range, avoiding the resource waste caused by full database traversal. At the same time, character-by-character comparison ensures the accuracy of conflict identification and avoids the problems of missed or false judgments.

[0088] For example, there are two ways to identify the target labeled primary key through primary key comparison results. The first method extracts the labeled primary key of each applied operation sequentially from the beginning of the list, based on the execution sequence of the operations bound to the list of applied operations, and performs a character-by-character comparison with the labeled primary key of the operation to be processed. After each set of primary key comparisons is completed, it is simultaneously determined whether the current matching result is completely consistent with the primary key. If the determination condition is met, the corresponding labeled primary key is marked as the target labeled primary key, and the remaining operation entries are traversed. If it is determined that the primary keys are inconsistent, the current operation is skipped, and the primary key comparison of the next operation is performed. After all entries in the list of applied operations have been compared and determined, all marked target labeled primary keys are summarized to generate the final set of conflicting primary keys. This method adopts the execution logic of sequential traversal and character-by-character comparison with time-locked execution, strictly follows the actual execution order of operations to complete conflict screening, and has simple and stable overall logic, low debugging and maintenance difficulty, and is suitable for conventional collaborative editing scenarios with single operations and small data volumes.

[0089] The second method is version partition parallel comparison. The list of applied operations is divided into regions based on consecutive version intervals. Operations corresponding to multiple adjacent versions are divided into independent comparison partitions, with no traversal dependencies between partitions and each partition can be processed independently. Then, parallel traversal processing is simultaneously initiated for all divided comparison partitions. Within each comparison partition, the labeled primary keys of applied operations are extracted one by one and compared character by character with the labeled primary keys of the operations to be processed to verify whether the primary keys are completely consistent. The identified target labeled primary keys within the partition are simultaneously marked. After all parallel traversal and marking work for all comparison partitions is completed, the target labeled primary keys output from each partition are aggregated to form a complete set of conflicting primary keys. This method employs the computational logic of version partitioning and full partition parallel traversal. By splitting massive amounts of operation data through pre-partitioning, it fully utilizes the system's parallel computing power to distribute the traversal pressure, significantly reducing the overall traversal time of large-scale operation lists. It is suitable for complex collaborative annotation scenarios with high concurrency, multiple users editing online simultaneously, and a large number of operation records.

[0090] Further, please refer to Figure 4 , Figure 4This is a message type structure diagram for this application. A unified operation message structure construction and application scheme is proposed, which constructs a standardized message structure including six operation types: Add, Delete, Update, BatchDelete, Undo, and Redo. The Add operation carries a complete annotation object containing 15+ common attribute fields, including OperationID, Operation Type, Annotation, and Base Revision fields. The Delete operation carries the Annotation ID, including the Operation ID, Operation Type, Annotation ID, and Base Revision fields. The Update operation only carries the Annotation ID and Update Fields, including the Operation ID, Operation Type, Annotation ID, Update Fields, and Base Revision fields. The Update Fields only include the attribute key-value pairs actually modified in this operation, reducing the data volume by 60%–90% compared to a full snapshot. The BatchDel operation carries a list of Annotation IDs, including the Operation ID, Operation Type, Annotation ID list, and Base Revision fields. Undo and redo operations only carry the OperationID, Operation Type, and Base Revision fields; the Annotation ID is filled in by the server. The message structure for the six operations is compatible with all 16 annotation types, and the structure is completely uniform. This achieves complete decoupling between operation types and annotation types; adding a new annotation type requires no modification to the operation message structure. Furthermore, by updating the difference fields of the operation, network data transmission volume is reduced, improving the efficiency and processing performance of operation transmission in high-concurrency collaborative editing scenarios. This provides a unified, efficient, and highly scalable operational interaction foundation for multi-user collaborative annotation.

[0091] Fourth embodiment This embodiment provides an exemplary scheme for generating valid update operations based on the difference of field key sets. In this example, the difference field key sets are first extracted from the operation to be processed and the operation that has been applied, respectively. Based on these two sets, a difference operation based on the field key names is performed to obtain a conflicting field key set. Then, the conflicting field key set is used to filter the original difference field dictionary to generate a target difference field dictionary. Finally, the original content is replaced with the dictionary, provided it is not empty, to obtain a valid update operation that retains only non-conflicting attributes. Step S30 includes steps C11~C14: Step C11: Extract the set of difference field keys, including the actual modified attributes, from the operation to be processed and the corresponding applied operation.

[0092] Step C12: Take the set of difference field keys of the operation to be processed as the subtracted set and the set of difference field keys of the applied operation as the subtracted set, and perform a set difference operation based on the field key name to obtain the set of conflicting field keys.

[0093] Step C13: Filter the original difference field dictionary of the operation to be processed through the conflict field key set, remove all attribute key-value pairs that have been modified by the applied operation, and generate a reduced target difference field dictionary.

[0094] Step C14: If the target difference field dictionary is not empty, replace the original difference field dictionary of the operation to be processed with the target difference field dictionary to obtain the valid update operation including non-conflicting attributes.

[0095] The subtraction set is the reference set used to remove duplicates during the operation. In this scheme, it refers to the set of difference field keys corresponding to the applied operation. The set difference operation is a pure logical set operation based solely on field key names, without reading the specific attribute values ​​or annotation type information, thus achieving type-independent conflict handling. The conflict field key set is the set remaining after the difference operation, containing only the unique, non-conflicting field key names of the operation to be processed. The original difference field dictionary is the structured dictionary data initially carried and stored by the operation to be processed, containing the modified attribute key-value pairs. The target difference field dictionary is a simplified dictionary data formed after field filtering and removal of conflicting content. For example, both the subtracted set and the subtracted set are composed of the aforementioned attribute key names; the set difference operation only compares the key name characters and does not parse the corresponding field values; the conflict field key set stores field key names that have not been modified by other clients; the original difference field dictionary stores the combination data of field key names and corresponding attribute values; the target difference field dictionary only retains the key-value pairs of non-conflicting fields.

[0096] In this example, when extracting the set of difference field keys from the pending operation and the applied operation, a global one-time extraction method can be used. Alternatively, a streaming incremental extraction method can be used, reading the modified attribute key names within the operation field by field. While reading the field content, the read field content is organized to generate a field set, which is then gradually pieced together to form a complete set of difference field keys, thus completing the collection of two sets of difference field keys.

[0097] After collecting two sets of difference field key sets, the field key name set difference operation process is initiated. The difference field key set corresponding to the operation to be processed is set as the subtracted set, and the difference field key set corresponding to the applied operation is set as the subtracted set. The pure key name dimension set difference operation is performed to obtain the conflict field key set. Then, this set is used to filter the original difference field dictionary of the operation to be processed, removing all conflicting attribute key-value pairs, generating a reduced target difference field dictionary. Finally, it is determined whether the target difference field dictionary has valid content. If the dictionary is not empty, dictionary replacement is performed, and finally, a valid update operation containing non-conflicting attributes is generated. In this way, through fine-grained difference and filtering at the field level, the independent editing intentions of multiple users are fully preserved. At the same time, pure key name operation is used to decouple from the annotation type, reduce computational overhead, and improve the accuracy of concurrent conflict resolution.

[0098] For example, there are two ways to implement the operation of generating a valid update operation from the set of difference field keys. The first method is to compare and verify each field key name in the subtracted set with all other field keys in the subtracted set, starting from the first field key name in the subtracted set, according to the original arrangement order of the key names within the set. After each comparison of a single key name is completed, it is simultaneously determined whether the field belongs to a non-conflicting field. If it is determined to be a non-conflicting field, the key name is added to the set of conflicting field keys. If it is determined to be conflicting, the field key name is directly discarded. After all field keys in both sets have been compared and filtered, a complete set of conflicting field keys is obtained. Then, the original difference field dictionary is traversed line by line according to this set, and the key-value pairs corresponding to the conflicts are removed to obtain the target difference field dictionary. Finally, the dictionary replacement is completed to generate a valid update operation. This method adopts the execution logic of sequential comparison and filtering of key names one by one with key name time-locking. The operation process is intuitive and the logic is controllable. It is not prone to field omission or incorrect filtering problems and is suitable for conventional collaborative editing scenarios with a single conflict update operation and a small number of fields.

[0099] The second method is field-grouped parallel difference operation. First, the field keys within both the subtracted and minuend sets are grouped according to their attribute functions, such as style, position, and text fields, into independent groups with no operational dependencies between them. Then, parallel difference comparison processing is initiated synchronously for all grouped fields. Within each group, conflict determinations for all keys are performed in batches, generating a set of locally conflicting fields for each group. After all parallel operations for all field groups are completed, all locally conflicting field sets are integrated to obtain a global set of conflicting field keys. The original difference field dictionary is then filtered in batches to generate the target difference field dictionary. After dictionary replacement, a valid update operation is obtained. This method employs a computational logic of field function grouping and full grouping parallel operation. By splitting the computational burden through pre-grouping, it fully utilizes parallel computing power to improve processing speed in scenarios with large numbers of fields and multiple conflicting operations, effectively shortening the overall time consumption of difference operation and data filtering. It is suitable for complex collaborative annotation scenarios involving multiple concurrent editors and a large number of fields modified in a single operation.

[0100] Further, please refer to Figure 5 , Figure 5This is a flowchart of the field difference set operation in this application. A field difference set conflict resolution scheme for concurrent update operations is proposed. The process first receives a client update operation. It then uses an annotation ID comparison function (SameTarget(clientOp, serverOp)) to determine whether the client operation (clientOp, Client Operation) and the server operation (serverOp, Server Operation) target the same annotation object. If the annotation IDs are different, there is no conflict, and the client operation (clientOp, ClientOperation) is returned directly. If the annotation IDs are the same, the field difference set operation is performed, using the client's updated fields (Update Fields) set as the subtracted set and the server's updated fields (Update Fields) set as the subtracted set. The new fields (New Fields) are calculated as: New Fields = Client Update Fields \\ Server Update Fields. Finally, it is checked whether the number of new fields (New Fields) is zero. If it is empty, an empty operation (is NoOperation) is marked as true, indicating that all fields have been processed by the server. If not empty, retain the non-conflicting fields, update the client's update fields to the new fields, apply the reduced operation, perform broadcast and persistence processing, and send back an ACK (Acknowledgement) message carrying the server version number. Even a no-operation scenario will send back a server version number to ensure client version synchronization. A typical example is a client operation modifying the line color and font size fields, and a server operation modifying the line color and line width fields. After the difference operation, the new fields only retain the non-conflicting font size fields. The Size field reflects the conflict resolution logic that "the operation of modifying color and line width has been written to disk first, and the color field is removed and the font size field is retained in the subsequent operation". Through field difference set operation, the non-overlapping editing intent is fully preserved in concurrent update operation, which improves the editing intent retention rate of the traditional full coverage method to 100%, solves the concurrent conflict problem in multi-person collaborative editing scenarios, and reduces the amount of data transmission and server processing overhead.

[0101] Fifth embodiment This embodiment provides an exemplary scheme for determining no-operation and synchronizing client versions. In this example, the generated target difference field dictionary is first validated. If no valid modified fields are found within the dictionary, the operation to be processed is marked as a no-operation and a corresponding identifier is generated. Then, an operation confirmation message is assembled by combining the current latest system version number. Finally, the confirmation message is sent to the client that submitted the operation, thereby ensuring that the client's local version number and the server's version number remain completely consistent. Please refer to... Figure 6 , Figure 6 This is a flowchart illustrating the fifth embodiment of the collaborative editing control method of this application. Following step C13, steps D11-D14 are also included: Step D11: If the target difference field dictionary is empty, then verify the target difference field dictionary to confirm that the number of valid attribute key-value pairs in the target difference field dictionary is zero and there are no modified fields that have not been covered by the applied operation, and obtain a passing verification result.

[0102] Step D12: Based on the passed verification results, mark the operation to be processed as a no-modification operation, clear the dictionary contents of the difference field of the operation, and generate a no-modification operation identifier.

[0103] Step D13: Generate an operation confirmation message based on the no-operation identifier and the current latest version number.

[0104] Step D14: Send the operation confirmation message separately to the client that submitted the operation to be processed, complete the entire process of this no-operation, and ensure that the client's local version number is consistent with the server's version number.

[0105] Valid attribute key-value pairs are the key-value combinations of records in the dictionary that document the modified attribute content, representing the edited content that can actually take effect in this operation. The validation result is a judgment conclusion output after verifying the data quantity and content validity of the target difference field dictionary, categorized as either "valid" or "failed." A null operation refers to an invalid update operation that, after conflict resolution, produces no executable modifications and cannot change the annotated data in the target file. The null operation identifier is a dedicated marker field appended to the operation data, used to distinguish between regular valid operations and null operations. The latest version number is a version code maintained globally on the server and continuously incremented with valid operations; it serves as the data version benchmark for all clients within the collaborative session. The operation confirmation message is an acknowledgment message returned by the server to the client that initiated the operation, used to synchronize the operation processing status with the latest version information on the server. For example, valid attribute key-value pairs correspond to specific annotation parameter modifications; the verification result is considered valid when there is no data in the dictionary; no-operation will not trigger target file updates or full client broadcasts; no-operation identifiers are marked using a dedicated boolean field; the latest version number is a globally auto-incrementing numeric code; the operation confirmation message encapsulates core information such as no-operation identifier, version number, and operation serial number.

[0106] In this example, when performing validity checks on an empty target difference field dictionary to obtain the validation results, a full traversal validation approach can be used. Alternatively, streaming sampling validation can be employed, randomly selecting dictionary storage indexes and data nodes for rapid verification. This, combined with the precondition that the dictionary is empty, comprehensively determines the number of valid attribute key-value pairs and quickly outputs the validation results, thus completing the validity validation of the target difference field dictionary.

[0107] After validating the target difference field dictionary and obtaining a passing validation result, the no-operation marking process is initiated. Based on the validation result, the original pending operation is marked as a no-operation that has no actual modification effect. At the same time, the contents of the difference field dictionary associated with the operation are cleared and a unique no-operation identifier is generated. Then, the latest global version number on the server is retrieved and combined with the no-operation identifier to form a standardized operation confirmation message. Finally, this message is pushed to the client that submitted the pending operation, thus completing the entire no-operation process. Through the layered processing logic of precise pre-validation, unified marking, and targeted receipt, version synchronization between the two ends can be completed even if the operation has no actual modification effect. This effectively avoids version gaps between the client and the server and subsequent operation execution anomalies, ensuring the continuous and stable operation of multi-user collaborative editing sessions.

[0108] For example, there are two implementation methods for empty operation marking, message generation, and message delivery. The first method executes a serial full-process processing according to the original time sequence of operation processing. Starting from the storage entry of the target difference field dictionary, it iterates and verifies the internal indexes and data nodes of the dictionary one by one, counts the number of valid attribute key-value pairs one by one, and outputs the verification result after confirming that the number is zero. Then, it executes the operation marking, dictionary clearing, and empty operation mark generation steps in sequence. Then, it extracts the empty operation mark and the current latest version number in sequence, assembles them into an operation confirmation message field by field, and finally retrieves the target client according to the client's unique connection identifier and pushes the operation confirmation message one by one. After the entire process of a single empty operation is completed, the next operation to be processed is connected. This method adopts a time-locked, step-by-step serial execution logic. Each processing link is promoted sequentially and there is a strong dependency between the steps. The overall process is simple and clear, and fault location is convenient. It is suitable for conventional collaborative annotation scenarios where single operations are connected sequentially and the concurrency pressure is relatively low.

[0109] The second approach involves batch operation parallel verification and message distribution. When the system simultaneously receives multiple pending operations with empty target difference field dictionaries, all pending operations are first grouped according to the collaborative session to which the client belongs, forming multiple independent operation groups with no execution dependencies between them. Then, validity verification is performed synchronously on all divided operation groups, batch verifying the number of valid attribute key-value pairs in the target difference field dictionary within each group, and outputting the verification results for each group. After verification, the empty operation marking, dictionary clearing, and empty operation identifier generation for each group are completed in parallel, while the latest global version number is retrieved to batch generate operation confirmation messages for each group. Finally, all operation confirmation messages are asynchronously distributed in parallel using a message queue and pushed to the corresponding clients. This method employs session grouping and full group parallel processing execution logic, leveraging group splitting and parallel computation to alleviate the processing pressure of batch empty operations, and combining message queues for asynchronous distribution. This improves the overall processing efficiency in high-concurrency scenarios with multiple clients simultaneously generating empty operations, making it suitable for complex application scenarios involving large-scale multi-user collaborative annotation and high-concurrency access.

[0110] Further, please refer to Figure 7 , Figure 7This is a schematic diagram of the operation transformation rule matrix of this application. A type-independent collaborative annotation conflict resolution scheme based on a complete OT transformation rule matrix uses the annotation ID as the unique conflict determination criterion, completely independent of the annotation type. It constructs a 4×4 matrix of 16 transformation rules, including client-side operations (clientOp, ClientOperation) and server-side operations (Server Operation). The total number of rules is independent of the number of annotation types N, and the backend transformation code does not need to be modified when adding any new annotation type. Specifically, the client-side Add operation does not conflict with any concurrent server-side operation (add / delete / update / batch delete), and the newly added annotation ID is unique and unrelated to other operation targets. The client-side Delete operation does not conflict with server-side Add or Update operations, and when it conflicts with the same annotation ID as a server-side Delete or Batch Delete operation, it is marked as a noop (no operation). Client-side update operations do not conflict with server-side add operations. When client-side delete or batch delete operations are performed on the same primary key of a label, they are marked as noop (no operation). When concurrent with server-side update operations, field-level difference operations are performed. When a pair of update fields are performed, only the attribute fields that have not been modified by the server-side operation are retained. Client-side batch delete operations do not conflict with server-side add operations. When concurrent with server-side delete and update operations, the corresponding label ID is removed from the deletion list. When concurrent with server-side batch delete operations, list difference operations are performed. After the intersection of the two lists, each removes the label ID that has been deleted by the other. Meanwhile, consistency is ensured through a convergence guarantee mechanism. TP1: The difference operation results of the same pair of operations satisfy the commutative law under different arrival orders. TP2: The final result of any pairwise transformation of the three operations is independent of the transformation order. It is proved that based on the symmetric mutual exclusion property of the difference sets A\B and B\A of the Update Fields, the intersection part is retained by each, and all clients eventually observe the same field reference set. This achieves type-independent, scalable, and convergent consistency in resolving conflicts in multi-person collaborative annotation, solving the problems of conflict rules growing with annotation type, loss of concurrent update intention, and difficulty in guaranteeing consistency in traditional collaborative annotation systems.

[0111] Sixth Embodiment This embodiment provides an exemplary scheme for file update and collaborative synchronization based on valid update operations. In this example, the target difference field dictionary carried by the non-empty valid update operation is first applied to the labeled data object corresponding to the target file. Then, the updated data and operation are atomically written to persistent storage and associated with an incrementing new version number to generate an operation record. Next, redundant fields are removed to generate a synchronization broadcast message containing only the modified attributes. Finally, the message is sent in parallel to all online clients in the same session, and a version confirmation message is sent individually to the submitting client. Step S40 includes steps E11 to E14: Step E11: Apply the target difference field dictionary carried by the non-empty valid update operation to the annotation data object corresponding to the target file to obtain the updated annotation data object.

[0112] Step E12: Write the updated labeled data object and the valid update operation to persistent storage, and associate the incremented new version number with this operation to obtain the operation record.

[0113] Step E13: Based on the operation record, remove all redundant fields that have not changed, and generate a synchronous broadcast message including the modified attributes.

[0114] Step E14: Send the synchronous broadcast message in parallel to all online clients in the same session, and send an operation confirmation message carrying the latest version number separately to the client that submitted this operation.

[0115] The target difference field dictionary is a core component of effective update operations. It stores only the attribute key-value pairs that are actually effective in this operation, without containing any conflicting or unmodified field content. The updated annotation data object is a standardized data structure generated after applying the target difference field dictionary, containing the latest annotation status. Persistent storage is a storage system used to permanently store annotation data and operation records, supporting atomic writes and transaction processing. The new version number is a globally maintained integer code on the server that automatically increments with each effective operation, used to uniquely identify the version of each data update. Operation records are complete historical records generated by associating updated data, effective operations, and the new version number, used for data backtracking and version management. Redundant fields refer to attribute fields in the operation records that have not changed; removing them can significantly reduce message transmission volume. Synchronous broadcast messages are standardized messages used to synchronize the latest modifications to all collaborative clients, containing only the modified attributes of this update. Online clients refer to client devices that are currently maintaining a WebSocket connection with the server and participating in the same session for collaborative editing. An operation confirmation message is a separate acknowledgement message sent by the server to the client that submitted the operation. It is used to notify the client of the operation processing result and synchronize the latest version number. For example, persistent storage uses a hybrid storage of a PostgreSQL database and JSON files; the new version number starts from 1 and increments sequentially; the operation record includes information such as the operation ID, version number, operation content, and update time; redundant fields include unmodified line colors and coordinate point sequences; the synchronization broadcast message only contains modified attribute fields; online clients maintain connection status through a heartbeat mechanism; and the operation confirmation message carries the latest version number and an operation success indicator.

[0116] In this example, when applying the target difference field dictionary to the labeled data object to obtain the updated labeled data object, it can be done by fully covering all fields. Alternatively, it can be done through streaming incremental application, reading the key-value pairs in the target difference field dictionary field by field, updating the corresponding attributes in the labeled data object as it is read, and gradually applying all modified fields to complete the update of the labeled data object.

[0117] After updating the labeled data objects, the persistence and synchronization process is initiated. First, a database transaction is started, and the updated labeled data objects and the complete and valid update operation are atomically written to persistent storage. At the same time, the global version number is incremented, and the new version number is uniquely associated with this operation to generate an operation record. After the transaction is committed, all unchanged redundant fields are removed based on the operation record, and a lightweight synchronization broadcast message is generated. Finally, the synchronization broadcast message is sent in parallel to all online clients in the same session, and an operation confirmation message carrying the latest version number is sent separately to the client that submitted this operation. In this way, atomic persistence ensures data consistency, incremental message transmission reduces bandwidth consumption, and parallel broadcasting improves synchronization efficiency, ensuring that all clients can quickly and accurately obtain the latest labeling status.

[0118] For example, there are two ways to implement file updates and collaborative synchronization through effective update operations. The first method adopts a serial atomic full-process processing. Starting from the application of the target difference field dictionary, it sequentially executes steps such as updating the labeled data object, starting the database transaction, writing data and operations, incrementing the version number, generating operation records, committing the transaction, removing redundant fields, generating synchronous broadcast messages, sending messages in parallel, and sending operation confirmation messages. After each step is completed, the next step is executed, and the entire process is completed within a single transaction. This method uses a strongly transactional serial execution logic, which can strictly guarantee the atomicity and consistency of data updates, and will not cause partial updates or data loss. It is suitable for conventional collaborative annotation scenarios where single operations are processed sequentially and data consistency requirements are high.

[0119] The second approach is batch parallel processing. When the system receives multiple valid update operations simultaneously, it first groups all operations according to their respective collaborative sessions, forming multiple independent operation groups. Operations within each group are arranged in version number order. Then, parallel processing is synchronously initiated for all the divided operation groups. Within each group, batch execution of annotation data object updates, atomic persistent writes, version number increments, and operation record generation is performed. After the persistence operations of all groups are completed, synchronous broadcast messages corresponding to each group are generated in batches and sent in parallel to all online clients in the corresponding session via message queues. Simultaneously, operation confirmation messages are generated and sent in batches. This method, employing session grouping and parallel processing execution logic, can fully utilize the system's multi-core computing power and database connection pool resources, significantly improving the overall processing throughput in high-concurrency scenarios and adapting to large-scale collaborative annotation scenarios with multiple users editing online simultaneously and intensive operation requests.

[0120] Further, please refer to Figure 8 , Figure 8This is a schematic diagram illustrating the timing interaction of multiple people concurrently editing the same annotation in this application. A method for resolving concurrent editing conflicts among multiple users based on field-level difference set operations is presented, taking the time-series interaction between client A, client B, and the server (OT engine, Operational Transformation) as an example. Initially, the server stores the status of label #101 as [green, 1, 14, 0.5], with a global version number of 10. At time T1, client A submits an update operation, changing the line color to red and the line width to 3, carrying a base version number of 10. Upon receiving this, the server applies the operation, incrementing the global version number to 11, updating the label status to [red, 3, 14, 0.5], and then returns an acknowledgment message (ACK) carrying version number 11 to client A. Simultaneously, it broadcasts a remote operation carrying version number 11 to client B. At time T2, client B, without receiving the update broadcast from client A, submits an update operation, changing the line color to blue and the font size... The size is 24, carrying a base version number of 10. After receiving the data, the server performs a field difference operation, subtracting the difference field set {Line Color, Font Size} from client B and the difference field set {Line Color, Line Width} from client A. The result is a set of non-conflicting fields containing only Font Size, removing the conflicting Line Color field. The server applies the reduced client B operation, increments the global version number to 12, updates the status to [Red, 3, 24, 0.5], and then broadcasts a remote operation carrying version number 12 to both client A and client B. The operation and acknowledgment messages (ACK, Acknowledgement) ultimately lead to a unified state [Red(A), 3(A), 24(B), 0.5], version number 12, where all non-overlapping modifications by both parties are fully preserved. This timing interaction verifies the core logic of "the operation arrives first, the server writes to disk and obtains disk protection, the subsequent operation removes conflicting fields after OT transformation, and non-conflicting fields are preserved." Among them, the line color was removed from the operation of client B because client A had modified it first, the font size was fully preserved because client A had not modified it, and the line width was also preserved even though it was modified only by client A. This achieves maximum preservation of concurrent editing intentions and final data consistency.

[0121] Seventh Embodiment This embodiment provides an exemplary scheme for constructing a general annotation attribute model with type erasure capability. In this example, firstly, all attribute fields of all heterogeneous annotation types in the target scene are collected, deduplicated, and integrated to obtain a complete set of attributes covering all requirements; then, a unified annotation data object is constructed based on the complete set of attributes, and general attribute fields are defined; next, a mapping relationship between heterogeneous annotation types and general attribute fields is established, and default values ​​are preset for inapplicable fields to obtain an initial attribute model; finally, the conflict judgment rules of the operation transformation engine are configured so that it only reads the annotation primary key and field key name to obtain the final annotation attribute model. Before step S10, steps F11~F14 are also included: Step F11: Collect all attribute fields of all heterogeneous annotation types in the target scene, remove duplicate attributes and integrate them to obtain a complete set of attributes that covers all annotation requirements.

[0122] Step F12: Construct a unified labeled data object based on the complete set of attributes, and define common attribute fields.

[0123] Step F13: Construct a mapping relationship between heterogeneous annotation types and the general attribute fields. The heterogeneous annotation types match the corresponding attribute subsets, and a unified default value is preset for all inapplicable attribute fields to obtain the initial attribute model.

[0124] Step F14: Configure the conflict determination rules of the operation transformation engine for the initial attribute model, and set the engine to only read the annotation primary key and general attribute field key name during the conflict detection and resolution process to obtain the annotation attribute model.

[0125] Heterogeneous annotation types refer to various annotation formats used to annotate different content and possessing different semantic and structural features in the target scenario. They are the source objects for attribute field collection. Attribute fields are the smallest data units used to describe a certain dimension of a labeled object and are the basic elements constituting labeled data. The attribute set is a complete set containing all attribute fields of all annotation types in the target scenario after deduplication and integration, and is the foundation for constructing a unified labeled data object. The unified labeled data object is a standardized data structure built on the attribute set, capable of uniformly describing all heterogeneous annotation types, and is the core carrier for achieving type erasure. Common attribute fields are standardized fields extracted from the attribute set that are shared by all annotation types or applicable to some annotation types, and are components of the unified labeled data object. Mapping relationships refer to the correspondence between heterogeneous annotation types and common attribute fields, used to determine the attribute subset applicable to each annotation type. Attribute subsets refer to the set of common attribute fields actually used by a specific heterogeneous annotation type. Default values ​​are unified initial values ​​preset for inapplicable common attribute fields, used to ensure the structural integrity of the unified labeled data object. The initial attribute model is the attribute model after completing the mapping relationship and default value configuration, possessing basic type unification capabilities. The Operational Transformation (OT) engine is the core conflict resolution engine of this system, responsible for handling conflict detection and resolution in concurrent annotation operations. Conflict determination rules are the set of rules used by the OT engine to determine whether conflicts exist in concurrent operations. The annotation primary key (annotationId, Annotation ID) is a unique field used to uniquely identify each annotation object and is the sole basis for conflict determination. The annotation attribute model is the final attribute model after the conflict determination rules are configured, possessing complete type erasure and conflict support capabilities. For example, heterogeneous annotation types include 16 types: rectangle, ellipse, polygon, arrow, scale bar, text, line, circle, included angle, concentric circle, flag, polyline, closed curve, free curve, magic wand, solid circle, and point. Attribute fields include annotation type identifier, name, coordinate point sequence, line color, line width, font size, font color, fill background color, fill transparency, rotation angle, area, description, extended label, and associated image. The attribute set contains all of the above attribute fields. There are 15+ common attribute fields, and all annotation types include annotation type identifier, name, description, extended label, and associated image fields. In the mapping relationship, text annotations match the font size and font color fields, and fill annotations match the fill background color and fill transparency fields. Default values ​​are uniformly set to empty strings or zero values. The initial attribute model supports a unified representation of 16 annotation types. The operation transformation engine performs conflict determination based on the annotation primary key and field key name. The annotation primary key is a globally unique string encoding. The annotation attribute model provides basic support for subsequent unified operation parsing and field difference set operations.

[0126] In this example, when collecting attribute fields from all heterogeneous annotation types to obtain the complete attribute set, a global full-scale collection approach can be used. This involves traversing the definition files of all 16 heterogeneous annotation types in the target scene at once, extracting all attribute fields for each annotation type, merging and deduplicating duplicate attributes with the same name and semantics, and standardizing and integrating semantically similar attributes to ultimately generate a complete attribute set covering all annotation requirements. Alternatively, an incremental iterative collection approach can be used. First, the core attribute fields of the core annotation types are collected to generate an initial attribute set. When adding new annotation types, only the attribute fields unique to the new type are extracted and added to the attribute set, without needing to re-collect existing attributes, thus completing the dynamic construction and expansion of the attribute set.

[0127] After completing the collection of the complete attribute set, the construction process of the unified labeled data object is initiated. Based on the complete attribute set, the names, data types, and value ranges of all common attribute fields are defined to construct a unified labeled data object with a fixed structure. Subsequently, a mapping relationship between each heterogeneous label type and the common attribute fields is established, the corresponding attribute subsets are matched, and a unified default value is preset for all inapplicable attribute fields to generate an initial attribute model. Finally, the conflict judgment rules of the operation transformation engine are configured for the initial attribute model, which clearly stipulates that the engine only reads the label primary key and the key name of the common attribute field during the conflict detection and resolution process, and does not read the label type identifier and the specific value of the attribute, to obtain the final labeled attribute model. In this way, through the hierarchical processing logic of attribute unification, mapping configuration, and rule limitation, the complete type erasure of heterogeneous label types is achieved, so that the subsequent operation parsing, conflict judgment, and transformation processing are completely independent of the label type, providing highly scalable and loosely coupled basic data support for the entire collaborative labeling system.

[0128] For example, there are two methods for constructing and configuring the general annotation attribute model. The first method uses a static mapping table-driven model construction approach. The mapping relationships between all 16 heterogeneous annotation types and general attribute fields are pre-stored in a static mapping table. The mapping table explicitly marks the applicable attribute fields and default values ​​for inapplicable fields for each annotation type. The static mapping table is loaded once at system startup to construct the initial attribute model. Subsequently, the conflict determination rules of the operation transformation engine are configured to process only based on the annotation primary key and field key name. This method uses predefined static mapping and fixed rule execution logic, resulting in fast model loading, stable operation, simple debugging and maintenance, and a lower likelihood of mapping errors. It is suitable for conventional collaborative annotation scenarios with fixed annotation types and stable requirements.

[0129] The second approach employs a dynamic metadata-driven model building method, storing the definitions of all heterogeneous annotation types, common attribute fields, and their mapping relationships in a dynamic metadata database. Upon system startup, the latest metadata is loaded from the metadata database, dynamically constructing a unified annotation data object and an initial attribute model. When a new annotation type is added subsequently, only the definition and corresponding mapping relationship need to be added to the metadata database; no modification to the backend code is required. Upon system restart, the new metadata is automatically loaded and the attribute model is updated. Simultaneously, the conflict determination rules of the transformation engine remain unchanged, still processing only based on the annotation primary key and field key name. This method, using dynamic metadata loading and no-code extension execution logic, possesses strong scalability and flexibility, enabling rapid response to the need for new annotation types. It truly achieves "zero modification to backend transformation code when adding any annotation type," adapting to complex collaborative annotation scenarios with frequent changes in annotation types and rapid iteration of requirements.

[0130] It should be noted that the 16 heterogeneous annotation types are uniformly abstracted into 15+ general attribute fields through this general annotation attribute model. All annotation instructions submitted by clients are parsed into operation objects with completely consistent structures based on this model. During the conflict determination and field difference set calculation, the operation transformation engine only reads the annotation primary key and the key name of the general attribute field, without relying on annotation type information throughout the process. This achieves lightweight collaborative editing control that is independent of the number of annotation types.

[0131] Eighth embodiment This embodiment provides an exemplary scheme for constructing a type-independent unified operation type system and message structure. In this example, the behavioral logic of all labeled operations in the target scenario is first analyzed, and basic and auxiliary operation types are divided to obtain a complete set of operations. Then, a consistent unified message structure framework is designed for all operations based on the basic version number and the labeled primary key. Next, a dedicated specification for defining a dictionary of difference fields is defined separately for update operations to generate a complete operation structure system. Finally, the type mapping rules of the operation parsing engine are configured to establish the correspondence between client commands and the unified structure, resulting in a standardized operation parsing rule configuration. Please refer to... Figure 9 , Figure 9 This is a flowchart illustrating the eighth embodiment of the collaborative editing control method of this application. Before step S10, steps G11-G14 are also included: Step G11: Analyze the behavioral logic of all annotation operations in the target scenario, and divide them into four basic operation types and two auxiliary operation types to obtain a set of operation types that cover all annotation requirements.

[0132] Step G12: Based on the base version number and the annotation primary key, design a consistent unified message structure framework for all operation types in the operation type set.

[0133] Step G13: Based on the unified message structure framework, define a dedicated structure specification for the difference field dictionary for update operations, and generate an operation structure system with difference field constraints.

[0134] Step G14: Based on the operation structure system, configure the type mapping rules of the operation parsing engine, construct the correspondence between various client annotation instructions and unified operation types and message structures, and generate operation parsing rule configuration.

[0135] The behavioral logic of annotation operations refers to the inherent rules governing the execution flow, target objects, and effects of various operations performed by users during the annotation process. It is the core basis for classifying operation types. Basic operation types are core operation types capable of independently adding, deleting, and modifying annotation data; they are the basic units constituting all annotation behaviors. Auxiliary operation types are supplementary operation types used to assist in the execution of basic operations and improve user experience; they do not directly cause permanent changes to annotation data. The operation type set is a complete set composed of all basic and auxiliary operation types, covering all annotation operation requirements in the target scenario. The unified message structure framework is a message carrier framework designed for all operation types with a completely consistent structure, containing common core fields shared by all operations. The operation structure system is a complete operation message definition system composed of the unified message structure framework and the specific structure specifications for each operation type. The operation parsing engine is the core component on the server side used to parse the raw annotation instructions submitted by the client into standardized operation objects. Type mapping rules are a set of rules used to establish the correspondence between the client's raw instructions and the unified operation type and message structure. The operation parsing rule configuration is a complete set of rules that has been configured and can be directly used for operation parsing. For example, basic operation types include four types: Add, Delete, Update, and BatchDel; auxiliary operation types include two types: Undo and Redo; the operation type set includes all six operation types mentioned above; the unified message structure framework includes four common core fields: operation unique identifier, operation type identifier, target annotation primary key, and base version number; the difference field dictionary only stores the attribute key-value pairs that are actually modified, such as line color and font size; the operation structure system supports all operations of 16 annotation types; the operation parsing engine can convert client Canvas operations into unified operation objects; the type mapping rules map the client's "modify line color" command to the update operation type; the operation parsing rule configuration can be directly loaded into the parsing engine for use.

[0136] In this example, when analyzing the behavioral logic of all annotation operations to obtain the set of operation types, a global full-scale analysis approach can be used. This involves iterating through all 16 annotation types and their corresponding operations in the target scenario, analyzing the execution logic, target objects, and data change scope of each operation. Adding, deleting, and modifying actions affecting a single annotation object are categorized as add, delete, and update operations, respectively. Batch deletion actions affecting multiple annotation objects are categorized as batch delete operations, and undo and redo actions used to revisit historical operations are categorized as auxiliary operation types. This ultimately generates a set of operation types covering all annotation requirements. Alternatively, an incremental iterative analysis approach can be used. First, the core annotation operations are analyzed to generate an initial set of operation types. When new operation requirements are added later, only the behavioral logic of the new operations is analyzed and added to the operation type set, without needing to re-analyze existing operations. This allows for the dynamic construction and expansion of the operation type set.

[0137] After constructing the set of operation types, the design process for a unified message structure was initiated. Based on the two core fields common to all operations—the base version number and the annotation primary key—a unified message structure framework with completely consistent structure was designed for all operation types in the set. This ensures that all operation messages contain the same common core fields. Next, based on the unified message structure framework, a dedicated structural specification for the difference field dictionary was defined separately for update operations. This explicitly stipulates that update operations only transmit the attribute fields that have actually been modified in this operation and prohibits the transmission of the full annotation data. This generates a complete operation structure system with difference field constraints. Finally, based on this operation structure system, the type mapping rules of the operation parsing engine were configured to establish a one-to-one correspondence between various client annotation instructions and the unified operation type and message structure. This generates standardized operation parsing rule configurations. Through unified structure design and difference field constraints, standardized transmission and parsing of all operations are achieved, providing a foundation for subsequent type-independent conflict determination and field difference set operations.

[0138] For example, there are two methods for constructing and configuring the unified operation type system and message structure. The first method uses a static configuration file-driven approach, where the message structure definitions, field specifications, and mapping relationships between client commands and unified operations for all six operation types are pre-stored in a static configuration file. The static configuration file is loaded once at system startup to construct the complete operation structure system and operation parsing rule configuration, and then the configuration is loaded into the operation parsing engine. This method uses predefined static configuration and fixed rule execution logic, resulting in stable message structures, fast parsing speed, simple debugging and maintenance, and reduced likelihood of parsing errors. It is suitable for typical collaborative annotation scenarios with fixed operation types and stable requirements.

[0139] The second approach employs a dynamic metadata-driven construction method, storing all operation type definitions, message structure specifications, and type mapping relationships in a dynamic metadata database. Upon system startup, the latest metadata is loaded from the metadata database, dynamically constructing a unified message structure framework and operation structure system. Simultaneously, corresponding operation parsing rule configurations are generated and loaded into the operation parsing engine. When new operation types are added subsequently, only the definition and corresponding mapping relationship of that operation type need to be added to the metadata database; no modification to any backend code is required. Upon system restart, the new metadata is automatically loaded, and the operation structure system and parsing rules are updated. Meanwhile, the conflict handling logic of the operation transformation engine remains unchanged, still processing only based on the annotation primary key and field key name. This method, employing dynamic metadata loading and no-code extension execution logic, possesses strong scalability and flexibility, enabling rapid response to the need for new operation types. Together with the general annotation attribute model in the seventh embodiment, it constitutes the core capability of "two-dimensional no-code extension," adapting to complex collaborative annotation scenarios with frequently changing and rapidly iterating operation requirements.

[0140] It should be noted that after receiving various annotation instructions submitted by the client, the operation parsing engine automatically loads the operation parsing rule configuration, and uniformly parses client instructions of different formats and annotation types into standardized operation objects with completely consistent structures, providing unified input data for subsequent type-independent conflict determination and field difference set operations.

[0141] This application provides a collaborative editing control 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 collaborative editing control method in Embodiment 1 above.

[0142] The following is for reference. Figure 10 The diagram illustrates a structural schematic of a control device suitable for implementing collaborative editing in the embodiments of this application. The control device for collaborative editing in the embodiments of this application may include, but is not limited to, mobile terminals such as smart interactive whiteboards and video conferencing terminals, as well as fixed terminals such as laptops, desktop computers, and tablets. Figure 10 The control device for collaborative editing shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0143] like Figure 10As shown, the control device for collaborative editing 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 read-only memory (ROM) 1002 or a program loaded from storage device 1003 into random access memory (RAM) 1004. The random access memory 1004 also stores various programs and data required for the operation of the control device for collaborative editing. 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 systems can be connected to I / O interface 1006: input devices 1007 including, for example, touchscreens, touchpads, keyboards, mice, image sensors, microphones, accelerometers, gyroscopes, etc.; output devices 1008 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 1003 including, for example, magnetic tapes, hard disks, etc.; and communication devices 1009. Communication device 1009 allows the collaborative editing control device to communicate wirelessly or wiredly with other devices to exchange data. Although a collaborative editing control device with various systems is shown in the figure, it should be understood that it is not required to implement or possess all the systems shown. More or fewer systems can be implemented alternatively.

[0144] 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 read-only memory 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.

[0145] The collaborative editing control device provided in this application, employing the collaborative editing control method in the above embodiments, can solve the technical problem of poor collaborative editing effect. Compared with the prior art, the beneficial effects of the collaborative editing control device provided in this application are the same as those of the collaborative editing control method provided in the above embodiments, and other technical features in the collaborative editing control device are the same as those disclosed in the previous embodiment method, and will not be repeated here.

[0146] 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.

[0147] 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.

[0148] This application provides a computer-readable storage medium having computer-readable program instructions (i.e., a computer program) stored thereon, the computer-readable program instructions being used to execute the collaborative editing control method in the above embodiments.

[0149] 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 systems, 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 fibers, 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 used by or in conjunction with an instruction execution system, system, or device. 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, radio frequency (RF), etc., or any suitable combination thereof.

[0150] The aforementioned computer-readable storage medium may be included in the control device for collaborative editing; or it may exist independently and not assembled into the control device for collaborative editing.

[0151] The aforementioned computer-readable storage medium carries one or more programs. When these programs are executed by a collaborative editing control device, the collaborative editing control device: responds to a labeling instruction for a target file, parses the operation data corresponding to the labeling instruction based on a labeling data object to obtain an operation object; compares the labeling primary key field of the operation object with the labeling primary key of the operation to be processed and the applied operation to determine the target labeling primary key in a conflicting state; performs a difference operation on the set of difference field keys of the update operation corresponding to the target labeling primary key to obtain a valid update operation including non-conflicting attributes; updates the operation object of the target file based on the valid update operation, and broadcasts the updated target file to all clients in the same session.

[0152] 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++, as well as 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).

[0153] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation that may be implemented in systems, 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, may be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0154] 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.

[0155] 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 collaborative editing control method, thereby solving the technical problem of poor collaborative editing performance. 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 collaborative editing control method provided in the above embodiments, and will not be repeated here.

[0156] The above description is only a part of the embodiments of this application and does not limit the patent scope of this application. All equivalent structural transformations made under the technical concept of this application and using the contents of the specification and drawings of this application, or direct / indirect applications in other related technical fields, are included in the patent protection scope of this application.

Claims

1. A collaborative editing control method, characterized in that, The method includes: In response to the annotation instructions of the target file, the operation object is obtained by parsing the operation data corresponding to the annotation instructions based on the annotation data object; Based on the annotation primary key field in the operation object, compare the annotation primary keys of the operation to be processed with those of the applied operations to determine the target annotation primary key in a conflict state, including: Extract the base version number and annotation primary key corresponding to the operation object from the operation object to be processed; Based on the base version number, a list of applied operations after the base version number is retrieved from the global operation history database; Traverse the list of applied operations, extract the annotation primary key of each applied operation, and compare the annotation primary key of each applied operation with the annotation primary key of the operation object to be processed, and obtain the matching result. When the matching result is that the primary key of the applied operation is the same as the primary key of the operation object to be processed, the primary key is marked as the target primary key in a conflict state; Perform a difference operation on the set of difference field keys of the update operation corresponding to the target annotation primary key to obtain a valid update operation including non-conflicting attributes; The operation object of the target file is updated based on the valid update operation, and the updated target file is broadcast to all clients in the same session.

2. The collaborative editing control method as described in claim 1, characterized in that, The step of responding to the annotation instructions of the target file and obtaining the operation object by parsing the operation data corresponding to the annotation instructions based on the annotation data object includes: In response to the annotation instructions for the target file, the session permissions and data validity of the annotation instructions are verified, and the original operation data is obtained after filtering out invalid instruction fields; Extract attribute data associated with the operation from the original operation data to generate an operation metadata set; When the operation type corresponding to the annotation instruction is an update operation, the key-value pairs of the attribute fields that have actually been modified are extracted from the operation metadata set to obtain the difference field dictionary; Based on the same field specification of the general labeled data object, the operation metadata set and the difference field dictionary are mapped to the operation object with the same structure.

3. The collaborative editing control method as described in claim 1, characterized in that, The step of performing a difference operation on the set of difference field keys corresponding to the update operation of the target annotation primary key to obtain a valid update operation including non-conflicting attributes includes: Extract the set of difference field keys, including the actual modified attributes, from the pending operation and the corresponding applied operation, respectively; The set of difference field keys of the operation to be processed is used as the subtracted set, and the set of difference field keys of the applied operation is used as the subtracted set. A set difference operation based on field key name is performed to obtain the set of conflicting field keys. The original difference field dictionary of the operation to be processed is filtered by the set of conflict field keys, and all attribute key-value pairs that have been modified by the applied operation are removed to generate a reduced target difference field dictionary. If the target difference field dictionary is not empty, then the target difference field dictionary replaces the original difference field dictionary of the operation to be processed, resulting in the valid update operation including non-conflicting attributes.

4. The collaborative editing control method as described in claim 3, characterized in that, After the steps of filtering the original difference field dictionary of the operation to be processed through the conflict field key set, removing all attribute key-value pairs that have been modified by the applied operation, and generating a reduced target difference field dictionary, the collaborative editing control method further includes: If the target difference field dictionary is empty, then the target difference field dictionary is verified to confirm that the number of valid attribute key-value pairs in the target difference field dictionary is zero and there are no modified fields that have not been covered by the applied operation, and a verification result of passing is obtained; Based on the passed verification results, the operation to be processed is marked as a no-modification operation, and the contents of the difference field dictionary of the operation are cleared to generate a no-modification operation identifier. Based on the no-operation identifier and the current latest version number, generate an operation confirmation message; The operation confirmation message is sent separately to the client that submitted the operation to be processed, completing the entire process of this no-operation, so as to ensure that the client's local version number is consistent with the server's version number.

5. The collaborative editing control method as described in claim 1, characterized in that, The step of updating the target file based on the valid update operation and broadcasting the updated target file to all clients in the same session includes: The target difference field dictionary carried by the valid update operation (which is not empty) is applied to the annotation data object corresponding to the target file to obtain the updated annotation data object; Write the updated labeled data object and the valid update operation to persistent storage, and associate the incremented new version number with this operation to obtain the operation record; Based on the operation record, all redundant fields that have not changed are removed, and a synchronous broadcast message including the modified attributes is generated; The synchronous broadcast message is sent in parallel to all online clients in the same session, and an operation confirmation message carrying the latest version number is sent separately to the client that submitted the operation.

6. The collaborative editing control method as described in claim 1, characterized in that, Before the step of responding to the annotation instructions of the target file and obtaining the operation object by parsing the operation data corresponding to the annotation instructions based on the annotation data object, the collaborative editing control method further includes: Collect all attribute fields of all heterogeneous annotation types in the target scene, remove duplicate attributes and integrate them to obtain a complete set of attributes that covers all annotation requirements; Based on the complete set of attributes, a unified labeled data object is constructed, and common attribute fields are defined; A mapping relationship is constructed between heterogeneous annotation types and the general attribute fields. The heterogeneous annotation types are matched with corresponding attribute subsets, and a unified default value is preset for all inapplicable attribute fields to obtain the initial attribute model. Configure the conflict determination rules of the operation transformation engine for the initial attribute model, and set the engine to only read the annotation primary key and general attribute field key name during the conflict detection and resolution process to obtain the annotation attribute model.

7. The collaborative editing control method as described in claim 1, characterized in that, Before the step of responding to the annotation instructions of the target file and obtaining the operation object by parsing the operation data corresponding to the annotation instructions based on the annotation data object, the collaborative editing control method further includes: By analyzing the behavioral logic of all annotation operations in the target scenario, four basic operation types and two auxiliary operation types are identified, resulting in a set of operation types that cover all annotation requirements. Based on the base version number and the annotation primary key, a consistent unified message structure framework is designed for all operation types in the set of operation types. Based on the unified message structure framework, a dedicated structure specification for the difference field dictionary is defined separately for update operations, generating an operation structure system with difference field constraints; Based on the aforementioned operation structure system, the type mapping rules of the operation parsing engine are configured, the correspondence between various client annotation instructions and unified operation types and message structures is constructed, and the operation parsing rule configuration is generated.

8. A control device for collaborative editing, characterized in that, The control device for collaborative editing includes: 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 control method for collaborative editing as described in any one of claims 1 to 7.

9. A storage medium, characterized in that, The storage medium is a computer-readable storage medium, and a computer program is stored on the storage medium. When the computer program is executed by a processor, it implements the steps of the collaborative editing control method as described in any one of claims 1 to 7.

Images