Historical literature version knowledge ontology dynamic collaborative construction method and system
By adopting a multi-node cloud-based collaborative processing architecture and a five-level conflict-based hierarchical processing protocol, the entity mapping conflict between versions of historical documents was resolved, enabling efficient dynamic collaborative construction and automated updates of knowledge ontology, and improving the accuracy and reliability of historical document management.
Patent Information
- Application Number
- CN202511398957.0
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-09-28
- Publication Date
- 2025-11-04
- Estimated Expiration
- 2045-09-28
AI Technical Summary
Existing technologies suffer from coarse-grained processing, low efficiency, and difficulty in achieving multi-node collaborative processing, semantic consistency verification, and automated ontology updates when dealing with entity mapping conflicts and version tracing between historical document versions.
A multi-node cloud-based collaborative processing architecture is adopted. Through a distributed conflict detection mechanism, a five-level conflict hierarchical processing protocol and a context-weighted arbitrator are used to realize the dynamic collaborative construction of historical document version knowledge ontology, including preprocessing, entity feature extraction, similarity calculation, conflict arbitration and ontology updating.
It achieves efficient and accurate conflict identification and intelligent adjudication of entities in multiple versions of historical documents, improves the accuracy, consistency and maintainability of knowledge ontology, and enhances the automation and reliability of knowledge management of multiple versions of documents.
Smart Images

Figure CN120893547A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of humanities knowledge graph technology, and in particular to a method and system for dynamic collaborative construction of historical document version knowledge ontology. Background Technology
[0002] Against the backdrop of the continuous development of digital humanities research and historical document information engineering, achieving structured modeling and semantic unification among different versions of historical documents has become an important research direction at the intersection of knowledge engineering and semantic computing. In recent years, knowledge graph and ontology construction technologies have been widely applied to semantic extraction, relation modeling, and semantic reasoning of document resources, demonstrating strong knowledge fusion capabilities, especially in handling large-scale heterogeneous text resources. In the context of historical documents, scholars have proposed some preliminary solutions based on ontology alignment, entity mapping, or version comparison to address issues such as differences in entity naming, information addition / deletion evolution, and semantic drift between different versions of documents.
[0003] Existing technologies often employ simple merging rules or manual verification methods when dealing with complex semantic issues such as entity mapping conflicts and version tracing. This results in coarse-grained processing and low efficiency in version consistency assessment and semantic change tracking. In contrast, when constructing a knowledge ontology with traceability, dynamic evolution, and conflict self-handling capabilities from multiple versions of historical documents, existing solutions still have room for optimization in areas such as multi-node collaborative processing, semantic consistency verification, and automated ontology update expression. Summary of the Invention
[0004] In view of the aforementioned existing problems, the present invention is proposed.
[0005] Therefore, this invention provides a method for dynamic collaborative construction of historical document version knowledge ontology to solve the problems of automatic arbitration of conflicts between multiple versions of entities and efficient collaboration in dynamic ontology updates.
[0006] To solve the above-mentioned technical problems, the present invention provides the following technical solution: In a first aspect, the present invention provides a method for dynamic collaborative construction of a knowledge ontology of historical document versions, which includes collecting digital versions of historical documents from multiple sources, performing preprocessing, and generating a set of version-structured documents. From the version-structured document set, extract the knowledge entity features of each version of the document to construct a version feature set; Input the version feature set into the multi-node cloud collaborative processing architecture, calculate the local similarity scores between versions, and output the version similarity matrix; A distributed conflict detection mechanism is used to evaluate the consistency of the version similarity matrix, mark entity mapping pairs with confidence scores below the confidence threshold, and generate conflict transaction logs. Input the conflict log into the five-level conflict hierarchical processing protocol, output the arbitration result into the corresponding OWL ontology update statement, attach version tracing annotations, and output historical document update instructions; Based on the historical document update instructions, the entity relationship network of the historical document knowledge ontology is dynamically expanded, and the historical document version knowledge ontology is output through a three-layer intelligent analysis framework.
[0007] As a preferred embodiment of the dynamic collaborative construction method for historical document version knowledge ontology described in this invention, the preprocessing to generate a version structured document set involves the following specific steps. A standardized document input dataset is obtained by converting the digitized versions of historical documents from multiple sources into a unified format, and then performing character recognition operations to obtain initial recognition results. The initial identification results are processed for text correction and layout restoration to obtain a text information set. Metadata information is then extracted and annotated to obtain a version structured document set.
[0008] As a preferred embodiment of the dynamic collaborative construction method for historical document version knowledge ontology described in this invention, the specific steps for constructing the version feature set are as follows: Named entity recognition is performed on each historical document in the version structured document set. Five types of knowledge entities are extracted and normalized to form a normalized entity set. Combined with semantic role labeling and dependency parsing, subject-predicate-object triplet is constructed. The subject-predicate-object triples are used to match and associate the same five types of knowledge entities in different versions, outputting an aligned entity relationship graph. Multidimensional feature vectors of the five types of knowledge entities are extracted, and standardized processing is performed to output a standardized feature vector set. The standardized feature vector set is aggregated by entity feature weighting average according to document version to construct a version-level feature matrix. The row vectors in the version-level feature matrix are mapped to the corresponding version identifiers, and the version feature set is output.
[0009] As a preferred embodiment of the dynamic collaborative construction method for historical document version knowledge ontology described in this invention, the specific steps for outputting the version similarity matrix are as follows: The version feature set is input into the multi-node cloud collaborative processing architecture. The master node in the multi-node cloud collaborative processing architecture receives the version feature set, distributes it evenly to the collaborative node cluster according to the version identifier, calculates the Euclidean distance of the feature vector of each historical document version, and generates local similarity scores through nonlinear transformation. Confidence weight labels are added to generate a local similarity matrix. All local similarity matrices are aggregated by confidence weight through distributed reduction operations to generate a global version similarity matrix. The version identifier is then mapped inversely to the row and column indices of the global version similarity matrix to output the version similarity matrix.
[0010] As a preferred embodiment of the dynamic collaborative construction method for historical document version knowledge ontology described in this invention, the specific steps for generating conflict transaction logs are as follows: Using the master node, the version similarity matrix is divided into multiple entity mapping pairs and distributed to each collaborating node; After receiving the entity mapping pair, each collaborative node performs version consistency verification based on the adjacent version entity consistency strategy, performs semantic consistency analysis in combination with entity context semantic information, identifies semantic conflict candidate entity pairs, and forms a structural conflict candidate set and a semantic conflict candidate set. The intersection of the structural conflict candidate set and the semantic conflict candidate set is processed to obtain the intersection entity mapping pairs. The corresponding confidence scores are extracted for judgment. When the confidence score is lower than the confidence score threshold, it is marked as a conflict entity mapping pair. Deduplication and integration with the mapping relationship are performed to generate a conflict transaction log.
[0011] As a preferred embodiment of the dynamic collaborative construction method for historical document version knowledge ontology described in this invention, the specific steps for outputting historical document update instructions are as follows: The conflict transaction log is parsed into a conflict evolution graph, and the input of the five-level contradiction layering processing protocol is mapped according to the five-level conflict types of syntax, structure, version, semantics and value. Under the five-level conflict resolution protocol, conflict adjudication is carried out through a context-weighted arbitrator based on entity context semantic trajectory and semantic stability index, and a list of adjudication results is output. Based on the list of rulings, convert different ruling types into corresponding OWL ontology update statements; Add processing node information, version identifiers, and conflict level annotations to the OWL ontology update statements, and integrate them to form historical document update instructions.
[0012] As a preferred embodiment of the dynamic collaborative construction method for historical document version knowledge ontology described in this invention, the specific steps for outputting the historical document version knowledge ontology are as follows: The historical document update instructions are parsed into incremental update events for entities and relationships; Incremental update events are prioritized according to conflict level annotations and version identifiers to generate a queue of pending update events. Based on the queue of pending update events, the entity relationship network of the historical document knowledge ontology is updated by inserting, deleting and updating the attributes of entities and relationships through each collaborative node. The system utilizes an entity-level semantic verification layer to perform consistency verification on the updated entity relationship network, a version-level association reasoning layer to perform deep semantic reasoning and version difference analysis, and an overall structure optimization layer to perform global structure optimization, outputting a historical document version knowledge ontology.
[0013] Secondly, the present invention provides a dynamic collaborative construction system for historical document version knowledge ontology, including a document acquisition module for acquiring digital versions of historical documents from multiple sources, performing preprocessing, and generating a version structured document set. The entity extraction module is used to extract knowledge entity features from each version of the document in the version structured document collection and construct a version feature set. The similarity calculation module is used to input the version feature set into the multi-node cloud collaborative processing architecture, calculate the local similarity score between versions, and output the version similarity matrix. The conflict detection module is used to perform consistency evaluation on the version similarity matrix using a distributed conflict detection mechanism, mark entity mapping pairs with confidence scores below the confidence threshold, and generate conflict transaction logs. The conflict resolution module is used to input the conflict transaction log into the five-level conflict hierarchical resolution protocol, output the arbitration result into the corresponding OWL ontology update statement, attach version traceability annotations, and output historical document update instructions. The ontology construction module is used to dynamically expand the entity relationship network of the historical document knowledge ontology according to the historical document update instructions, and output the historical document version knowledge ontology through a three-layer intelligent analysis framework.
[0014] Thirdly, the present invention provides a computer device including a memory and a processor, wherein the memory stores a computer program, wherein when the computer program is executed by the processor, it implements any step of the dynamic collaborative construction method for historical document version knowledge ontology as described in the first aspect of the present invention.
[0015] Fourthly, the present invention provides a computer-readable storage medium having a computer program stored thereon, wherein: when the computer program is executed by a processor, it implements any step of the dynamic collaborative construction method for historical document version knowledge ontology as described in the first aspect of the present invention.
[0016] The beneficial effects of this invention are as follows: Through a multi-node distributed conflict detection mechanism, efficient and accurate conflict identification of multiple versions of historical documents is achieved. Combined with a five-level conflict hierarchical processing protocol and a context-weighted arbitrator, intelligent adjudication and standardized dynamic updates of complex conflicts are realized, and the additional version tracing ensures the transparency of updates. At the same time, with the help of unified preprocessing, multi-dimensional semantic feature extraction and weighted aggregation, parallel calculation of multi-version similarity, and a three-layer intelligent analysis framework, dynamic collaborative construction and deep semantic reasoning of historical document knowledge ontology are completed, effectively improving the accuracy, consistency, and maintainability of the knowledge system, and significantly enhancing the automation and reliability of multi-version document knowledge management. Attached Figure Description
[0017] To more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings used in the following description of the embodiments will be briefly introduced. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.
[0018] Figure 1 A flowchart for a method of dynamically and collaboratively constructing a knowledge ontology for historical document versions.
[0019] Figure 2 A schematic diagram of a dynamic collaborative construction system for historical document version knowledge ontology.
[0020] Figure 3 Flowchart for generating a version-structured document collection.
[0021] Figure 4 A flowchart for generating a knowledge ontology of historical document versions. Detailed Implementation
[0022] To make the above-mentioned objects, features and advantages of the present invention more apparent and understandable, the specific embodiments of the present invention will be described in detail below with reference to the accompanying drawings.
[0023] Many specific details are set forth in the following description in order to provide a full understanding of the invention. However, the invention may also be practiced in other ways different from those described herein, and those skilled in the art can make similar extensions without departing from the spirit of the invention. Therefore, the invention is not limited to the specific embodiments disclosed below.
[0024] Secondly, the term "one embodiment" or "embodiment" as used herein refers to a specific feature, structure, or characteristic that may be included in at least one implementation of the present invention. The phrase "in one embodiment" appearing in different places in this specification does not necessarily refer to the same embodiment, nor is it a single or selective embodiment that is mutually exclusive with other embodiments.
[0025] Reference Figures 1-4 As one embodiment of the present invention, this embodiment provides a method for dynamic collaborative construction of a knowledge ontology of historical document versions, including the following steps: S1. Collect digital versions of historical documents from multiple sources, preprocess them, and generate a structured collection of documents.
[0026] It should be noted that digital versions of multi-source historical documents include scanned images, OCR text, structured data, and metadata information from different institutions, media, and periods.
[0027] S1.1. Perform a unified format conversion on the digitized versions of multi-source historical documents to obtain a standardized document input dataset, and perform character recognition operations to obtain initial recognition results.
[0028] It should be noted that the format of each document file in the digital versions of the collected multi-source historical documents is identified, and different formats such as document image data, structured text files or PDFs are uniformly converted into a unified image + text composite format. The documents are then numbered and labeled by page to obtain a standardized document input dataset. Each page in the standardized document input dataset contains document image content of uniform size and corresponding metadata framework.
[0029] After format conversion, image preprocessing operations are performed on the document images in the standardized document input dataset. These operations include image denoising, tilt correction, contrast enhancement, and edge sharpening to improve the accuracy of subsequent character recognition and the clarity of image structure. Optical character recognition methods are then used to detect and recognize characters line by line in the preprocessed document image regions, extracting the text information contained in the document images. Finally, preliminary text region aggregation and sequential reconstruction are performed in conjunction with the document image structure to obtain initial recognition results.
[0030] S1.2. Perform text correction and layout structure restoration on the initial recognition results to obtain a text information set, and extract and annotate metadata information to obtain a version structured document set.
[0031] It should be noted that text correction processing based on dictionary comparison and language context is performed on the character content in the initial recognition results. By correcting the spelling and semantic matching of incorrectly identified words, the accuracy of the text content is improved. Based on the position information of each text line in the standardized historical document image page in the initial recognition results, combined with line spacing, paragraph alignment, page layout clues and differences between title and body text fonts, the page structure is restored to reconstruct the original chapter structure, paragraph hierarchy and title hierarchy of the historical document, and output a text information set containing the complete document hierarchy structure.
[0032] After obtaining the text information set, according to the six types of metadata information in the document content, including keywords, paragraph tags, page number marks, author information, time marks, and document source identifiers, the text information set is subjected to metadata information extraction. The six types of metadata elements are extracted and structured using a rule-based and positional relationship-based entity localization method. Each type of metadata information is semantically annotated through a tag system to complete the metadata information extraction and annotation. Finally, a version structured document set containing three types of structures, including text content, structural information, and metadata, is output.
[0033] S2. Extract the knowledge entity features from each version of the structured document set and construct a version feature set.
[0034] S2.1. Named entity recognition is performed on each historical document in the version structured document set. Five types of knowledge entities are extracted and standardized to form a standardized entity set. Combined with semantic role labeling and dependency parsing, subject-predicate-object triplet is constructed.
[0035] It should be noted that named entity recognition was performed on each historical document text in the version structured document set. The named entity recognition adopted a recognition method based on part-of-speech tagging and context feature rules. The semantically independent continuous word groups in the historical document text were scanned and labeled to identify five types of knowledge entities. The five types of knowledge entities include people entities, event entities, location entities, institution entities, and time entities. The five types of knowledge entities have multiple expressions in the original text. Therefore, the five types of knowledge entities initially identified are normalized. Through word form restoration, thesaurus mapping, and entity alias matching, expressions with the same semantic orientation are unified into standardized expressions to generate a standardized entity set.
[0036] After constructing a standardized entity set, semantic role labeling is used to identify the semantic functions of each component in the sentence, such as agent, patient, instrument, and target roles. Furthermore, based on dependency syntax, the sentence's syntax tree structure is parsed to identify syntactic relations between words, such as subject-predicate relations (e.g., "meeting-held"), verb-object relations (e.g., "passed-resolved"), and adverbial-head relations (e.g., "rapidly-developed"), obtaining dependency syntax path similarity. By jointly matching the semantic role labeling results with the dependency syntax path similarity, subject-predicate-object triples composed of entity and action relations are extracted. Each subject-predicate-object triple consists of a standardized entity as the subject, a semantic action word as the predicate, and another standardized entity as the object, comprehensively depicting the semantic relations between entities in historical documents.
[0037] S2.2. Use subject-predicate-object triples to match and associate the same five types of knowledge entities in different versions, output an aligned entity relationship graph, extract multi-dimensional feature vectors of the five types of knowledge entities, perform standardization processing, and output a standardized feature vector set.
[0038] It should be noted that the subject-predicate-object triples in each version are grouped into five categories of knowledge entities. The expression methods and semantic context features of each type of entity in different historical document versions are extracted. The five types of knowledge entities of the same kind in different versions are compared one by one. For the five types of knowledge entities of the same kind in different historical document versions, matching judgment is performed pairwise based on the similarity of normative expression, semantic context features, subject-predicate-object triples and dependency syntax paths. When the matching conditions are met, they are identified as semantically equivalent entities, and a corresponding relationship is established between versions. An aligned entity relationship graph composed of entity nodes and matching edges is constructed.
[0039] For each of the five knowledge entities, based on information such as semantic context, word frequency statistics, word vector representation, syntactic dependency structure, and role in the subject-predicate-object triplet in different versions, multi-dimensional semantic, syntactic, structural, and contextual features are extracted to construct multi-dimensional feature vectors. To improve the consistency of subsequent calculations, all multi-dimensional feature vectors of the five knowledge entities are uniformly standardized, including value range normalization, distribution transformation, and feature compression, to finally obtain a standardized feature vector set with consistent format and unified dimensions.
[0040] It should also be noted that the matching criteria refer to the consistency or high similarity of the normalized expressions, as well as the similarity of the contextual semantics, the same or similar predicate relations, and the similarity of the dependency syntax path structure.
[0041] S2.3. Perform entity feature weighted average aggregation on the standardized feature vector set according to document version to construct a version-level feature matrix, and establish a mapping relationship between the row vectors in the version-level feature matrix and the corresponding version identifier to output the version feature set.
[0042] It should be noted that the five types of knowledge entities in the standardized feature vector set are grouped according to the document version, ensuring that each group corresponds to all five types of knowledge entities in a historical document version. Within each group, the standardized feature vectors of all five types of knowledge entities are weighted. The weights are allocated based on the frequency of occurrence of the five types of knowledge entities in the document version, the importance of their semantic roles, or their structural positions in the subject-predicate-object triple. For example, entities with higher frequency of occurrence or those that play the role of subject can be given higher weights. The standardized feature vectors of all five types of knowledge entities within the version are then weighted and averaged to obtain the version-level feature vector representing the overall semantic features of the version.
[0043] The version-level feature vectors of each historical document version are arranged sequentially to form a version-level feature matrix. Each row of version-level feature vectors is bound to the corresponding version identifier, so that each row in the version-level feature matrix has a clear version orientation, and finally the version feature set is output.
[0044] S3. Input the version feature set into the multi-node cloud collaborative processing architecture, calculate the local similarity scores between versions, and output the version similarity matrix.
[0045] It should be noted that the "multi-node cloud collaborative processing architecture" is an existing technology in the field of distributed computing. Its general components include: one master node (responsible for task scheduling and result aggregation) and multiple collaborative nodes (performing parallel computing). Data interaction between nodes is realized through distributed communication middleware (such as gRPC / MPI), and computing resources are dynamically allocated using resource managers (such as YARN / Kubernetes).
[0046] S3.1 Input the version feature set into the multi-node cloud collaborative processing architecture. The master node in the multi-node cloud collaborative processing architecture receives the version feature set, distributes it evenly to the collaborative node cluster according to the version identifier, calculates the Euclidean distance of the feature vector of each historical document version, and generates local similarity scores through nonlinear transformation. Confidence weight labels are added to generate a local similarity matrix.
[0047] It should be noted that the master node receives the complete version feature set, divides each version-level feature vector in the version feature set evenly according to the version identifier, and distributes the divided version-level feature vectors evenly to the collaborative node cluster.
[0048] After receiving version-level feature vectors from different historical document versions, the collaborative nodes calculate the Euclidean distance between the version feature vectors to quantify the degree of feature differences between versions. The expression is as follows: ; In the formula, It is the first The eigenvector of the reference version and the eigenvector of the _th reference version Euclidean distance between the feature vectors of each target version It is the first The first reference version feature vector of the feature vector Each version-level feature vector dimension feature value, It is the first The first target version feature vector Each version-level feature vector dimension feature value, It is an index variable of the version-level feature vector dimension. It is the number of dimensions of the version-level feature vector. It is the index variable of the reference version feature vector. It is the index variable of the target version feature vector.
[0049] After calculation, the collaborative nodes use a nonlinear transformation function, such as a transformation method based on exponential decay or Gaussian kernel function, to convert the Euclidean distance into a local similarity score, expressed as: ; In the formula, It is the first The eigenvector of the reference version and the eigenvector of the _th reference version Local similarity scores between the feature vectors of each target version It is an adjustment parameter for nonlinear transformation, used to control the similarity decay rate.
[0050] Based on the quality indicators and data integrity of the version-level feature vectors, a corresponding confidence weight label is added to each local similarity score to reflect the reliability of the similarity score. Finally, each collaborative node outputs a local similarity matrix containing local similarity scores and confidence weight labels.
[0051] It should also be noted that the confidence weight is calculated by comprehensively evaluating indicators such as the completeness of the version feature vector, data quality, and text recognition accuracy. It reflects the reliability of the local similarity score and is used to enhance the credibility labeling of each element in the similarity matrix.
[0052] The quality index of version-level feature vectors is obtained by checking the completeness of the content of version-level feature vectors. It mainly evaluates whether the feature vectors fully contain the dimensional information of five types of knowledge entities (people, events, places, institutions, and time), and examines the rationality of the distribution of features in each dimension and their correspondence with the semantics of the original text.
[0053] The data integrity of version-level feature vectors is determined through integrity checks on the original document data. This primarily assesses the completeness of the document metadata fields, the accuracy of text recognition, and the coverage of five knowledge entity matching across different versions. These checks verify the integrity and reliability of the data source from different perspectives.
[0054] S3.2 Aggregate all local similarity matrices by confidence weight through distributed reduction operation to generate a global version similarity matrix, and back-map the version identifier to the row and column indices of the global version similarity matrix to output the version similarity matrix.
[0055] It should be noted that the local similarity matrices output by multiple collaborative nodes are aggregated according to their corresponding version identifiers. The local similarity scores between the same version pairs are then weighted by confidence, with the weights determined based on the confidence level of each local similarity score. This ensures that high-confidence similarity scores have a greater influence in the aggregation.
[0056] Through distributed reduction operations, the local similarity matrix data on all collaborative nodes are aggregated into a unified global version similarity matrix. Each element in the global version similarity matrix represents the global similarity score between two corresponding historical document versions. Based on the mapping relationship between version identifiers and matrix indices, the version identifiers are accurately mapped to the row and column index positions of the global version similarity matrix, ensuring that the version identifiers corresponding to the matrix rows and columns are unique and correct. Finally, a version similarity matrix containing the global similarity scores and version identifier mapping information between all historical document versions is output.
[0057] S4. Using a distributed conflict detection mechanism, perform consistency evaluation on the version similarity matrix, mark entity mapping pairs with confidence scores below the confidence threshold, and generate conflict transaction logs.
[0058] S4.1 Using the master node, the version similarity matrix is divided into multiple entity mapping pairs and distributed to each cooperating node.
[0059] It should be noted that the master node receives the complete version similarity matrix, parses the version pair relationship corresponding to each element in the version similarity matrix into an entity mapping pair, that is, a five-category knowledge entity matching pair between two historical document versions, and reasonably divides all entity mapping pairs according to the task allocation strategy to ensure that the divided entity mapping pair set is evenly distributed and easy to process collaboratively.
[0060] After the partitioning is completed, the master node will distribute the entity mapping pairs of different batches to multiple collaborating nodes according to the partitioning results, ensuring that the entity mapping pairs received by each collaborating node can support subsequent version consistency verification and semantic analysis.
[0061] It should also be noted that the task allocation strategy is an intelligent scheduling mechanism in which the master node dynamically selects the optimal allocation scheme (uniform allocation or load balancing) based on the real-time load status (CPU / memory / network) of the cooperating nodes and the task characteristics (computational complexity / data volume / dependencies).
[0062] S4.2 After receiving the entity mapping pair, each collaborative node performs version consistency verification based on the adjacent version entity consistency strategy, performs semantic consistency analysis in combination with entity context semantic information, identifies semantic conflict candidate entity pairs, and forms a structural conflict candidate set and a semantic conflict candidate set.
[0063] It should be noted that each collaborative node adopts an adjacency version entity consistency strategy for the received entity mapping pairs, compares the adjacency relationships and attribute consistency of the five types of knowledge entities in different historical document versions, verifies the structural consistency of the five types of knowledge entities between versions, and performs semantic consistency analysis by combining the contextual semantic information extracted from the version structured document set of the five types of knowledge entities, assesses the similarity of entity semantic content and potential contradictions, and identifies candidate entity pairs with semantic conflicts.
[0064] The structural consistency check compares whether the directly related entities (such as the subject-object relationship in triples) of the five types of knowledge entities remain consistent in different versions, and checks whether the attributes of the five types of knowledge entities (such as the person's position, the event time, etc.) are recorded in different versions. When it is found that the relationship between the five types of knowledge entities is broken between versions (such as a version missing a key predicate connection) or the core attributes are inconsistent (such as conflicting records of the participants in the same event), the semantic conflict candidate entity pairs are classified into the structural conflict candidate set.
[0065] Semantic consistency analysis is used to compare the contextual descriptions (such as co-occurring words and modifiers) of five types of knowledge entities in different versions of text to identify logical contradictions in semantic expression (such as entity A being the superior of entity B in one version, but becoming a peer in another version). When there is an irreconcilable conflict in the semantic roles of the five types of knowledge entities in different versions, they are included in the semantic conflict candidate set.
[0066] It should also be noted that potential contradictions include contradictions in attributes (such as inconsistent records of a person's position in different versions), contradictions in relationships (such as contradictory descriptions of the causal relationship of an event in different versions), and contradictions in time sequence (such as differences in the time records of the same event in different versions).
[0067] S4.3 Perform intersection processing on the candidate sets of structural conflicts and the candidate sets of semantic conflicts to obtain the intersection entity mapping pairs, and extract the corresponding confidence scores for judgment. If the confidence score is lower than the confidence score threshold, it is marked as a conflict entity mapping pair.
[0068] It should be noted that all entity mapping pairs in the structural conflict candidate set and the semantic conflict candidate set are uniformly encoded using the encoding rule of "entity type + version ID + entity ID" (e.g., "person_V1_E005"). A hash table is constructed based on the encoding index to quickly locate the entity mapping pairs that match completely in the two sets. A dual verification mechanism is used to ensure the accuracy of the intersection result—requiring both strict matching of entity IDs and complementary conflict types (e.g., "inconsistent time attributes" in structural conflicts must correspond to "contradictory time descriptions" in semantic conflicts). Finally, a list of intersection entity mapping pairs that simultaneously satisfy both structural and semantic conflict conditions is output.
[0069] For each intersection entity mapping pair, local similarity scores and corresponding confidence weights are extracted from the version similarity matrix. Combined with the performance of the intersection entity mapping pair in the conflict detection stage (such as structural conflict intensity level 1-3, semantic conflict severity score 0.1-1.0), the output confidence is dynamically adjusted through a weighted formula as a judgment criterion. The confidence scores are compared, and if the confidence score is lower than the confidence threshold, the intersection entity mapping pair is marked as a conflict entity mapping pair.
[0070] It should also be noted that confidence thresholds are set by analyzing indicators such as the completeness of version feature vectors, text recognition accuracy, and the stability of similarity calculation, combined with historical data experience and actual task requirements.
[0071] S4.4. Using the master node, deduplication of conflict entity mappings is performed and integrated with the mapping relationship to generate conflict transaction logs.
[0072] It should be noted that the master node receives conflicting entity mappings from multiple cooperating nodes, performs deduplication on the conflicting entity mappings, merges duplicate entity mapping pairs, eliminates redundant information, and then integrates the mapping relationships of the deduplicated entity mapping pairs according to the corresponding version identifiers and entity identifiers to ensure that the version correspondence of all conflicting entity mapping pairs is complete and without conflict or duplication.
[0073] During the integration process, the attribute information and confidence values in the mapping relationship are updated uniformly to ensure the consistency and accuracy of the mapping relationship. Finally, the set of conflict entity mappings that have been deduplicated and have complete mapping relationships is organized to generate a structured conflict transaction log.
[0074] S5. Input the conflict log into the five-level conflict layering processing protocol, output the arbitration result into the corresponding OWL ontology update statement, attach version tracing annotations, and output historical document update instructions.
[0075] It should be noted that the five-level conflict resolution protocol is a conflict resolution mechanism in the construction of historical document knowledge graphs. Its core components include five levels: the syntactic layer (L1) handles surface issues such as character encoding and spelling errors; the structural layer (L2) repairs triple breaks or attribute contradictions; the version layer (L3) calibrates time or content deviations caused by document revisions; the semantic layer (L4) adjudicates contextual logical contradictions (such as inconsistencies in wording or narrative perspective); and the value layer (L5) conducts the final review of core disputes involving the sensitivity of historical evaluation.
[0076] Technical implementation of the five-level conflict stratification agreement: Conflict detection: Based on the version identifier, confidence level, and evolutionary features (such as contextual semantic vectors) of entity mapping pairs, it automatically classifies them into five levels.
[0077] Layered arbitration: L1-L3 are automatically processed by algorithms (such as Neo4j graph alignment), L4 adopts a mixed scoring of "semantic similarity + historical attribute weight", and L5 is automatically adjudicated by a historical value decision engine (based on an authoritative historical data rule base).
[0078] Closed-loop feedback: When the adjudication result is converted into an OWL statement, a conflict level annotation is attached (such as "L4 semantic conflict confidence 0.72"), and it passes through a test case generator (such as timing consistency verification).
[0079] The role of the five-level conflict resolution agreement: Precise disambiguation: Through a five-level hierarchical approach, contradictions across the entire spectrum from the grammatical layer (L1) to the value layer (L5) are resolved, ensuring the historical compliance and academic rigor of the knowledge ontology.
[0080] Dynamic source tracing: All adjudication results carry version identifiers and processing node information, supporting end-to-end tracing of "entity-conflict-correction" and providing an audit baseline for subsequent ontology expansion. Its innovation lies in incorporating the sensitivity assessment of historical materials, unique to historical documents, into the standardized processing flow.
[0081] S5.1 Parse the conflict transaction log into a conflict evolution graph, and map the input to the five-level contradiction layering processing protocol according to the five-level conflict types of syntax, structure, version, semantics and value.
[0082] It should be noted that each conflict entity mapping pair in the conflict transaction log is used as the basic unit. Based on the version identifier, entity content, conflict type and confidence information, each item is parsed to extract relevant content including conflict source, conflict relationship, conflict entity pair and evolution path, and to construct the evolution relationship chain of conflict entities in multiple historical document versions.
[0083] Each pair of conflicting entities with historical evolution characteristics is used as a conflict evolution node. The version evolution information, structural changes, semantic changes or context transfer relationships connected on the timeline form a conflict evolution map that includes the structural changes and semantic evolution processes between entities.
[0084] The conflict evolution graph is mapped to conflict entity mapping pairs based on the information marked in the conflict transaction log, according to five dimensions: syntactic differences, structural changes, version divergence, semantic conflicts, and historical value. Based on this, the corresponding conflict evolution graph is divided into the conflict type level in the five-level conflict layering protocol.
[0085] It should also be noted that grammatical differences are identified by comparing the lexical forms (such as traditional / simplified Chinese conversion) and syntactic structures (such as passive / active voice differences) of the five types of knowledge entities in different versions, thus identifying surface-level linguistic contradictions such as spelling and word order.
[0086] Structural Changes: Analyze the role changes (e.g., subject becomes object) and attribute field additions / reductions (e.g., version differences in character positions) of five types of knowledge entities in cross-version triples to detect inconsistencies in the knowledge graph structure.
[0087] Version discrepancies: Based on the timeline and revision background of the document versions, identify the differences in the description of five types of knowledge entities caused by version changes (such as the 1951 version deleting the description of a specific event in the 1935 version).
[0088] Semantic conflict: By comparing the emotional tendencies (such as positive and negative modifiers) and behavioral logic (such as "support" vs. "oppose") of the context of five types of knowledge entities, deep-seated semantic contradictions are determined.
[0089] Historical value: Based on historical evaluation systems (such as the authority of historical materials and social impact), assess the extent to which conflicting entities damage or lose the core value of the documents.
[0090] S5.2 Under the five-level conflict layering protocol, based on the entity context semantic trajectory and semantic stability index, a context-weighted arbitrator is used to adjudicate conflicts and output a list of adjudication results.
[0091] It should be noted that, under the five-level conflict hierarchical processing protocol, for the input conflict evolution map, the contextual semantic trajectory of conflict entity mapping pairs in historical document versions is first extracted. This includes the semantic change paths, contextual collocations, and syntactic dependency features of the five types of knowledge entities in different historical document versions. Combined with the version evolution order and semantic change trend of the five types of knowledge entities in the time dimension, a complete semantic trajectory expression is formed. Simultaneously, based on the confidence information and semantic change magnitude attached to the aforementioned conflict transaction log, a semantic stability index for each conflict entity mapping pair is calculated to measure the consistency of the semantic direction of conflict entities in different historical document versions. The expression is: ; In the formula, Represents conflicting entity mapping pairs semantic stability index Represents conflicting entity mapping pairs in the 1st... Contextual semantic vectors extracted from various historical document versions Represents conflicting entity mapping pairs in the 1st... Contextual semantic vectors extracted from historical document versions, Index variables representing historical document versions, This indicates the total number of versions of historical documents.
[0092] After obtaining the semantic trajectory and semantic stability index of the entity context, a context-weighted arbitrator is used to make a decision. The context-weighted arbitrator scores the conflicting entity mapping pairs based on dimensions such as the frequency of occurrence of the conflicting entity mapping pairs in different contexts, version semantic continuity, semantic stability index, and semantic evolution direction. Based on the scoring results, the arbitrator determines the retention priority and version orientation of the conflicting entity mapping pairs in the historical document knowledge ontology, and finally outputs a list of decision results containing the decision results of all conflicting entity mapping pairs.
[0093] S5.3. Based on the list of adjudication results, convert different adjudication types into corresponding OWL ontology update statements.
[0094] It should be noted that each conflict entity mapping pair in the list of adjudication results is classified, and the adjudication type output by the five-level conflict hierarchical processing protocol will correspond to the specific type of ontology update operation, including five basic ontology operations: adding entities, deleting entities, updating attributes, adding relationships, and deleting relationships.
[0095] For rulings that identify newly added entities, construct new descriptive statements that have clear category labels and unique identifiers in semantics.
[0096] For rulings that require the deletion of an entity, an invalidation statement with a flagged status is generated to indicate that the entity is no longer in use.
[0097] For adjudication results that require attribute modification, generate corresponding updated expression content based on the attribute type, and indicate the new attribute value and format description.
[0098] For adjudication results that require the addition of new relationships, a structural description representing the relationship between the entities is generated based on the behavior or logical connection between the two entities involved.
[0099] For rulings requiring the deletion of a relationship, construct descriptive statements reflecting the cancellation of the original relationship.
[0100] After all transformation operations are completed, each transformation result is represented as an ontology update statement with complete semantic structure and syntax conforming to the OWL 2 specification.
[0101] S5.4. Add processing node information, version identifiers and conflict level annotations to the OWL ontology update statements, and integrate them to form historical document update instructions.
[0102] It should be noted that each OWL ontology update statement generated in the previous refinement step is used as the basic content, with three dimensions of auxiliary annotation information added. Among them, the processing node information is used to indicate the identifier of the collaborating node that specifically performs the ontology update operation, the version identifier is used to record the historical document version number corresponding to the current ontology update statement, and the conflict level annotation is used to mark the conflict level type of the conflict entity mapping pair involved in the current update statement in the five-level conflict layering processing protocol.
[0103] Based on all OWL ontology update statements with attached information, each update statement is merged and integrated according to entity structure consistency and temporal continuity to generate historical document update instructions with complete attribute annotations and traceable version information.
[0104] It should also be noted that, based on the collaborative node allocation table recorded during task distribution, the master node automatically extracts the node identifier for performing the update operation during the OWL statement generation phase, binds it with the operation timestamp, and obtains the processing node information.
[0105] S6. Based on the historical document update instructions, dynamically expand the entity relationship network of the historical document knowledge ontology, and output the historical document version knowledge ontology through a three-layer intelligent analysis framework.
[0106] It should be noted that the three-layer intelligent analysis framework consists of an entity-level semantic verification layer, a version-level association reasoning layer, and an overall structure optimization layer.
[0107] Entity-level semantic verification layer: Based on existing ontology verification tools (such as the Pellet inference engine), attribute consistency checks are achieved by extending the historical document-specific rule base (such as logical constraints on the positions of persons).
[0108] Version-level association reasoning layer: Utilizing temporal knowledge graph technology combined with cross-version semantic trajectory analysis, we can uncover the evolutionary patterns of five types of knowledge entities across different versions.
[0109] Overall structure optimization layer: The topology structure is adjusted using complex network optimization algorithms (such as community detection), and new historical document specificity indicators are added to guide the optimization.
[0110] S6.1 Parse historical document update instructions into incremental update events of entities and relations.
[0111] It should be noted that the entity description structure, attribute update content, or entity relationship expression content contained in each OWL ontology update statement are extracted from the historical document update instructions. The subject, predicate, and object triple elements in the statement are identified, and the update operation type is distinguished, including adding, modifying, or deleting entities, updating attribute values, or adding relationships between entities. Based on the processing node information, version identifier, and conflict level annotations attached to the update statement, the version sequence position and semantic conflict intensity involved in the update operation are determined to guide the priority determination of subsequent incremental update events. Multiple update statements parsed from the same historical document update instruction are aggregated into structural units according to entity identifiers, and multiple attribute update or relationship update operations belonging to the same subject entity are integrated to generate a set of entity and relationship incremental update events with a clear structure and semantics.
[0112] S6.2. Prioritize incremental update events according to conflict level annotations and version identifiers to generate a queue of pending update events.
[0113] It should be noted that the conflict level annotation and version identifier information attached to each incremental update event are read. Secondly, based on the hierarchical relationship of the conflict level annotations, the incremental update events are sorted from highest to lowest conflict severity to ensure that high-conflict-level update events are processed first. Simultaneously, combined with the version identifier, incremental update events at the same conflict level are sorted according to version chronological order to ensure that the time sequence of version updates is respected. The sorted incremental update events are then arranged sequentially to form a queue of update events to be processed.
[0114] S6.3. Based on the queue of pending update events, insert, delete, and update the entity and relation relationships of the historical document knowledge ontology through each collaborative node to obtain the updated entity and relation network.
[0115] It should be noted that the entity and relation change information in the incremental update event is read one by one. Each collaborative node performs corresponding operations on the entity relation network of the historical document knowledge ontology according to the operation type described in the incremental update event: for newly added entities or relations, an insertion operation is performed to add them to the entity relation network; for entities or relations that need to be deleted, a deletion operation is performed to remove the corresponding node or edge from the entity relation network; for attribute update content, replacement or supplementation is performed according to the attribute type and the new attribute value to ensure the accuracy and completeness of the attribute information.
[0116] Each operation is executed strictly in the order of the update event queue to ensure the orderliness and version consistency of the update process. After all incremental update events are processed in sequence, an updated entity relationship network containing the latest entity, relationship and attribute information is generated.
[0117] S6.4. The entity-level semantic verification layer is used to perform consistency verification on the updated entity relationship network. The version-level association reasoning layer is used to perform deep semantic reasoning and version difference analysis. The overall structure optimization layer is used to perform global structure optimization and output the historical document version knowledge ontology.
[0118] It should be noted that the entity-level semantic verification layer checks each entity and its corresponding attribute in the updated entity relationship network one by one. It verifies whether the attribute values of the entity conform to the predefined semantic standards through semantic rules and constraints, identifies contradictions or unreasonable phenomena between the structured field contents of the five types of knowledge entities, eliminates duplicate or conflicting entity information, and ensures that the semantic expression of the five types of knowledge entities is complete and accurate, thereby improving the overall consistency and credibility of knowledge expression.
[0119] The version-level association reasoning layer combines the evolution of entity relationships between different versions in historical documents. By constructing semantic association chains between versions, it infers and identifies the semantic evolution paths between mapped entities based on rules such as semantic hierarchy, attribute value changes, and relational structure adjustments. These paths include attribute value replacements, additions or deletions of relationships. Then, based on semantic constraints, it judges whether these changes have logical conflicts or semantic deviations, thereby identifying semantic differences and potential conflicts between versions, mining knowledge increments or corrections brought about by version updates, and supporting a deeper understanding of historical document versions and ensuring semantic consistency.
[0120] The overall structure optimization layer analyzes the structural characteristics of the entity relationship network from a global perspective, and uses network topology optimization methods to adjust the connection relationships between entities, eliminate redundant relationships, balance the connectivity of entity nodes, optimize the hierarchical structure and path length of the knowledge ontology, improve query efficiency and inference performance, and finally generate a historical document version knowledge ontology with reasonable structure and excellent performance.
[0121] It should also be noted that by analyzing existing entity types, attribute structures, and hierarchical semantic relationships in historical documents, and combining them with field definition rules, attribute value ranges, and inter-entity constraints in the version ontology, a unified semantic standard is formed.
[0122] This embodiment also provides a dynamic collaborative construction system for historical document version knowledge ontology, including: a document acquisition module, used to acquire digital versions of historical documents from multiple sources, perform preprocessing, and generate a version structured document set; The entity extraction module is used to extract knowledge entity features from each version of the document in the version structured document collection and construct a version feature set. The similarity calculation module is used to input the version feature set into the multi-node cloud collaborative processing architecture, calculate the local similarity score between versions, and output the version similarity matrix. The conflict detection module is used to perform consistency evaluation on the version similarity matrix using a distributed conflict detection mechanism, mark entity mapping pairs with confidence scores below the confidence threshold, and generate conflict transaction logs. The conflict resolution module is used to input the conflict transaction log into the five-level conflict hierarchical resolution protocol, output the arbitration result into the corresponding OWL ontology update statement, attach version traceability annotations, and output historical document update instructions. The ontology construction module is used to dynamically expand the entity relationship network of the historical document knowledge ontology according to the historical document update instructions, and output the historical document version knowledge ontology through a three-layer intelligent analysis framework.
[0123] This embodiment also provides a computer device applicable to the dynamic collaborative construction method of historical document version knowledge ontology, including: a memory and a processor; the memory is used to store computer-executable instructions, and the processor is used to execute the computer-executable instructions to realize the dynamic collaborative construction method of historical document version knowledge ontology proposed in the above embodiment.
[0124] The computer device can be a terminal, comprising a processor, memory, communication interface, display screen, and input devices connected via a system bus. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The communication interface is used for wired or wireless communication with external terminals; wireless communication can be achieved through Wi-Fi, carrier networks, NFC (Near Field Communication), or other technologies. The display screen can be an LCD screen or an e-ink screen. The input devices can be a touch layer covering the display screen, buttons, a trackball, or a touchpad on the computer device's casing, or an external keyboard, touchpad, or mouse.
[0125] This embodiment also provides a storage medium storing a computer program. When executed by a processor, the program implements the dynamic collaborative construction method for historical document version knowledge ontology proposed in the above embodiments. The storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as Static Random Access Memory (SRAM), Electrically Erasable Programmable Read-Only Memory (EEPROM), Erasable Programmable Read Only Memory (EPROM), Programmable Red-Only Memory (PROM), Read-Only Memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk.
[0126] In summary, this invention achieves efficient and accurate conflict identification of multiple versions of historical documents through a multi-node distributed conflict detection mechanism. Combined with a five-level conflict hierarchical processing protocol and a context-weighted arbitrator, it enables intelligent adjudication and standardized dynamic updates of complex conflicts. Version tracing ensures update transparency. Furthermore, by leveraging unified preprocessing, multi-dimensional semantic feature extraction and weighted aggregation, parallel calculation of multi-version similarity, and a three-layer intelligent analysis framework, it completes the dynamic collaborative construction and deep semantic reasoning of historical document knowledge ontology. This effectively improves the accuracy, consistency, and maintainability of the knowledge system, significantly enhancing the automation and reliability of multi-version document knowledge management.
[0127] It should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and are not intended to limit it. Although the present invention has been described in detail with reference to preferred embodiments, those skilled in the art should understand that modifications or equivalent substitutions can be made to the technical solutions of the present invention without departing from the spirit and scope of the technical solutions of the present invention, and all such modifications or substitutions should be covered within the scope of the claims of the present invention.
Claims
1. A method for dynamic collaborative construction of a knowledge ontology of historical document versions, characterized in that: include, Collect digitized versions of historical documents from multiple sources, preprocess them, and generate a structured collection of documents based on the versions. From the version structured document set, extract the knowledge entity features of each version of the document to construct a version feature set; Input the version feature set into the multi-node cloud collaborative processing architecture, calculate the local similarity scores between versions, and output the version similarity matrix; A distributed conflict detection mechanism is used to evaluate the consistency of the version similarity matrix, mark entity mapping pairs with confidence scores below the confidence threshold, and generate conflict transaction logs. Input the conflict log into the five-level conflict hierarchical processing protocol, output the arbitration result into the corresponding OWL ontology update statement, attach version tracing annotations, and output historical document update instructions; Based on the historical document update instructions, the entity relationship network of the historical document knowledge ontology is dynamically expanded, and the historical document version knowledge ontology is output through a three-layer intelligent analysis framework.
2. The method for dynamic collaborative construction of historical document version knowledge ontology as described in claim 1, characterized in that: The preprocessing process to generate a version-structured document set involves the following steps. A standardized document input dataset is obtained by converting the digitized versions of historical documents from multiple sources into a unified format, and then performing character recognition operations to obtain initial recognition results. The initial identification results are processed for text correction and layout restoration to obtain a text information set. Metadata information is then extracted and annotated to obtain a version structured document set.
3. The method for dynamic collaborative construction of historical document version knowledge ontology as described in claim 1, characterized in that: The specific steps for constructing the version feature set are as follows: Named entity recognition is performed on each historical document in the version structured document set. Five types of knowledge entities are extracted and normalized to form a normalized entity set. Combined with semantic role labeling and dependency parsing, subject-predicate-object triplet is constructed. The subject-predicate-object triples are used to match and associate the same five types of knowledge entities in different versions, outputting an aligned entity relationship graph. Multidimensional feature vectors of the five types of knowledge entities are extracted, and standardized processing is performed to output a standardized feature vector set. The standardized feature vector set is aggregated by entity feature weighting average according to document version to construct a version-level feature matrix. The row vectors in the version-level feature matrix are mapped to the corresponding version identifiers, and the version feature set is output.
4. The method for dynamic collaborative construction of historical document version knowledge ontology as described in claim 1, characterized in that: The specific steps for generating the output version of the similarity matrix are as follows. The version feature set is input into the multi-node cloud collaborative processing architecture. The master node in the multi-node cloud collaborative processing architecture receives the version feature set, distributes it evenly to the collaborative node cluster according to the version identifier, calculates the Euclidean distance of the feature vector of each historical document version, and generates local similarity scores through nonlinear transformation. Confidence weight labels are added to generate a local similarity matrix. All local similarity matrices are aggregated by confidence weight through distributed reduction operations to generate a global version similarity matrix. The version identifier is then mapped inversely to the row and column indices of the global version similarity matrix to output the version similarity matrix.
5. The method for dynamic collaborative construction of historical document version knowledge ontology as described in claim 1, characterized in that: The specific steps for generating the conflict transaction log are as follows. Using the master node, the version similarity matrix is divided into multiple entity mapping pairs and distributed to each collaborating node; After receiving the entity mapping pair, each collaborative node performs version consistency verification based on the adjacent version entity consistency strategy, performs semantic consistency analysis in combination with entity context semantic information, identifies semantic conflict candidate entity pairs, and forms a structural conflict candidate set and a semantic conflict candidate set. The intersection of the structural conflict candidate set and the semantic conflict candidate set is processed to obtain the intersection entity mapping pairs. The corresponding confidence scores are extracted for judgment. When the confidence score is lower than the confidence score threshold, it is marked as a conflict entity mapping pair. Deduplication and integration with the mapping relationship are performed to generate a conflict transaction log.
6. The method for dynamic collaborative construction of historical document version knowledge ontology as described in claim 1, characterized in that: The specific steps for outputting the historical document update instruction are as follows: The conflict transaction log is parsed into a conflict evolution graph, and the input of the five-level contradiction layering processing protocol is mapped according to the five-level conflict types of syntax, structure, version, semantics and value. Under the five-level conflict resolution protocol, conflict adjudication is carried out through a context-weighted arbitrator based on entity context semantic trajectory and semantic stability index, and a list of adjudication results is output. Based on the list of rulings, convert different ruling types into corresponding OWL ontology update statements; Add processing node information, version identifiers, and conflict level annotations to the OWL ontology update statements, and integrate them to form historical document update instructions.
7. The method for dynamic collaborative construction of historical document version knowledge ontology as described in claim 1, characterized in that: The specific steps for outputting the historical document version knowledge ontology are as follows: The historical document update instructions are parsed into incremental update events for entities and relationships; Incremental update events are prioritized according to conflict level annotations and version identifiers to generate a queue of pending update events. Based on the queue of pending update events, the entity relationship network of the historical document knowledge ontology is updated by inserting, deleting and updating the attributes of entities and relationships through each collaborative node. The system utilizes an entity-level semantic verification layer to perform consistency verification on the updated entity relationship network, a version-level association reasoning layer to perform deep semantic reasoning and version difference analysis, and an overall structure optimization layer to perform global structure optimization, outputting a historical document version knowledge ontology.
8. A dynamic collaborative construction system for historical document version knowledge ontology, based on the dynamic collaborative construction method for historical document version knowledge ontology as described in any one of claims 1 to 7, characterized in that: include, The document acquisition module is used to collect digital versions of historical documents from multiple sources, perform preprocessing, and generate a structured document collection. The entity extraction module is used to extract knowledge entity features from each version of the document in the version structured document collection and construct a version feature set. The similarity calculation module is used to input the version feature set into the multi-node cloud collaborative processing architecture, calculate the local similarity score between versions, and output the version similarity matrix. The conflict detection module is used to perform consistency evaluation on the version similarity matrix using a distributed conflict detection mechanism, mark entity mapping pairs with confidence scores below the confidence threshold, and generate conflict transaction logs. The conflict resolution module is used to input the conflict transaction log into the five-level conflict hierarchical resolution protocol, output the arbitration result into the corresponding OWL ontology update statement, attach version traceability annotations, and output historical document update instructions. The ontology construction module is used to dynamically expand the entity relationship network of the historical document knowledge ontology according to the historical document update instructions, and output the historical document version knowledge ontology through a three-layer intelligent analysis framework.
9. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that: When the processor executes the computer program, it implements the steps of the dynamic collaborative construction method for historical document version knowledge ontology as described in any one of claims 1 to 7.
10. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by the processor, it implements the steps of the dynamic collaborative construction method for historical document version knowledge ontology as described in any one of claims 1 to 7.
Citation Information
Patent Citations
Knowledge graph fusion method based on adaptive hybrid ontology mapping
CN112328810A
Standard document conflict detection method and system based on standard knowledge graph
CN113449118A
Entity matching method and device for multi-version mapping knowledge domain and medium
CN116306933A
Non-residual knowledge graph construction method and system based on multiple modes
CN119397036A
Intangible cultural heritage multi-modal knowledge graph construction method and system based on big data
CN120354927A
Cited By
Knowledge entry updating and tracing method based on change association analysis and user feedback
CN121615745A
