A Blockchain-Based Method and System for Multi-User Collaborative Construction of Knowledge Graphs

Abstract

The present invention discloses a method and system for multi-person collaborative construction of a knowledge graph based on blockchain. The method includes: creating ontology data of the knowledge graph and storing it in IPFS, generating a knowledge graph summary record and uploading it to the blockchain release chain; obtaining the knowledge graph ontology data from IPFS for design; fusing all Cypher update statements in this cycle into knowledge graph ontology data fusion design information through a semantic fusion algorithm, generating a data fusion record and uploading it to the blockchain design chain; obtaining the data fusion record from the blockchain design chain, performing a consistency check, and uploading the data that passes the check to the blockchain release chain.

Description

Technical Field

[0001] This invention relates to the field of blockchain technology, and in particular to a method and system for collaborative construction of a knowledge graph based on blockchain. Background Art

[0002] The concept of "knowledge graph" was formally proposed by Google in 2012. Since 2013, with the continuous development of intelligent information services and applications, knowledge graphs, big data, and deep learning have become core driving forces for the development of the internet and artificial intelligence. In the production process, the construction of knowledge graphs often requires collaborative processing among multiple departments and roles. Traditional collaboration methods are singular, and information communication barriers exist between collaborating users, easily leading to poor data exchange and affecting the efficiency of multi-user collaborative knowledge graph construction. Storing data directly on the blockchain poses a significant challenge to the storage performance of the blockchain network; simultaneously, the poor interaction performance of the blockchain significantly impacts information exchange between collaborative users. Existing technologies have designed corresponding on-chain and off-chain collaborative storage schemes and attribute encryption schemes to address these issues. However, because they generally use a single blockchain for data management, the throughput performance of the blockchain is insufficient to meet the concurrent processing requirements of multi-user collaborative knowledge graph scenarios. Furthermore, existing technologies are prone to duplicate and conflicting data when storing knowledge data using existing methods, increasing the storage pressure on the blockchain and affecting the system's collaborative capabilities.

[0003] Meanwhile, concurrent transactions involving multiple users are difficult to monitor, easily leading to data conflicts and redundancy, resulting in slow collaborative progress. Furthermore, the system management mechanism is inadequate, lacking a unified verification version and failing to reasonably constrain the work progress and responsibilities of each collaborating user. Therefore, proposing a system and method that can effectively break down data privacy barriers between collaborating users and ensure the efficient operation of collaborative transactions has become an urgent problem to solve.

[0004] To address the aforementioned issues, Huajun Chen proposed the OpenKG Chain concept based on blockchain, utilizing the ONTID and OpenKG token mechanism to resolve trust issues among users and data value traceability problems in traditional knowledge graph crowdsourcing platforms. Timotej Knez proposed using blockchain to record updated knowledge graph data after each creation process during multi-user collaborative creation. Leveraging the tamper-proof and traceable properties of blockchain, data security and sharing during multi-user collaborative creation can be guaranteed. However, these studies failed to effectively manage concurrent data, easily leading to inconsistencies between on-chain and off-chain data, unequal user information, and data redundancy. Summary of the Invention

[0005] This invention addresses the technical problems of inconsistency between on-chain and off-chain data, version conflicts in multi-user collaboration, and data redundancy in the existing technologies, and proposes a multi-user collaborative construction method and system for knowledge graphs based on blockchain.

[0006] In a first aspect, embodiments of this application provide a blockchain-based multi-person collaborative construction method for knowledge graphs, including:

[0007] Initial data upload steps: The collaborative task publisher creates knowledge graph ontology data for reference by graph designers, stores the knowledge graph ontology data in IPFS, generates a knowledge graph summary record based on the returned hash storage address and the hash value of the knowledge graph ontology data, and uploads it to the blockchain publishing chain;

[0008] Task publishing steps: The collaborative task publisher creates knowledge graph collaborative task information, selects the knowledge graph version to be collaborated on, obtains the corresponding knowledge graph summary record from the blockchain publishing chain, obtains the hash storage address of the knowledge graph and the hash value of the knowledge graph ontology data through the knowledge graph summary record, generates knowledge graph collaborative task information based on the hash address, the task information and the hash value of the knowledge graph ontology data, and uploads it to the blockchain design chain, which is used as the initial data for multi-person collaboration and the standard data for consistency checks during the graph update cycle;

[0009] Data design steps: The knowledge graph designer obtains knowledge graph collaboration task information from the blockchain design chain, retrieves knowledge graph ontology data from IPFS based on the hash storage address in the knowledge graph collaboration task information, combines knowledge graph triple data in the local database to design the knowledge graph, and forms personal update data from the Cypher statements during the knowledge graph design.

[0010] Collaborative data upload steps: Before multiple graph designers upload data to the blockchain collaboration chain, they only need to use the ontology inference engine to check whether the standard data in the knowledge graph collaboration task information is consistent with the personal update data in the local database. If they are consistent, the personal update data and the corresponding hash value in the local database are used to generate a knowledge graph design record and upload it to the blockchain collaboration chain; otherwise, the upload is abandoned.

[0011] Update data fusion and upload steps: At the end of the graph update cycle, the smart contract automatically collects the knowledge graph design records uploaded to the blockchain collaborative chain during this cycle, and calls the semantic fusion algorithm to merge all the Cypher update statements involved in this cycle into Cypher statement fusion information. Based on the Cypher statement fusion information and the corresponding hash value, a data fusion record is generated and uploaded to the blockchain design chain.

[0012] Data publishing steps: The collaborative task publisher obtains the data fusion record from the blockchain design chain, applies it to the local database to form complete knowledge graph data, and uses the ontology inference engine to perform consistency verification. The complete knowledge graph data that passes the verification is then uploaded to the blockchain publishing chain.

[0013] Secondly, embodiments of this application provide a blockchain-based knowledge graph multi-user collaborative construction system for implementing the knowledge graph multi-user collaborative construction method described in the first aspect, characterized in that it includes:

[0014] Environment Deployment Unit: Deploys the blockchain multi-chain network environment and IPFS environment, calls the multi-chain partitioning rules to partition the blockchain network, and builds IPFS; among them, the blockchain release chain is partitioned as the main chain, and the blockchain design chain and blockchain collaboration chain are partitioned as side chains;

[0015] Initial data upload unit: The collaborative task publisher creates knowledge graph ontology data for reference by graph designers, stores the knowledge graph ontology data in IPFS, generates a knowledge graph summary record based on the returned hash storage address and the hash value of the knowledge graph ontology data, and uploads it to the blockchain publishing chain;

[0016] Task Publishing Unit: The collaborative task publisher creates knowledge graph collaborative task information, selects the knowledge graph version to be collaborated on, obtains the corresponding knowledge graph summary record from the blockchain publishing chain, obtains the hash storage address of the knowledge graph and the hash value of the knowledge graph ontology data through the knowledge graph summary record, and generates knowledge graph collaborative task information based on the hash address, the task information and the hash value of the knowledge graph ontology data and uploads it to the blockchain design chain. This information is used as initial data for multi-person collaboration and standard data for consistency checks during the graph update cycle.

[0017] Data Design Unit: Knowledge graph designers obtain knowledge graph collaboration task information from the blockchain design chain, retrieve knowledge graph ontology data from IPFS based on the hash storage address in the knowledge graph collaboration task information, design the knowledge graph based on the architecture of the ontology data and the knowledge graph triple data in the local database, and form personal update data from the Cypher statements during the knowledge graph design.

[0018] Collaborative Data Upload Unit: Before multiple graph designers upload data to the blockchain collaborative chain, they only need to use the ontology inference engine to check whether the standard data in the knowledge graph collaborative task information is consistent with the personal update data in the local database. If they are consistent, the personal update data and the corresponding hash value in the local database are used to generate a knowledge graph design record and upload it to the blockchain collaborative chain; otherwise, the upload is abandoned.

[0019] Update Data Fusion Upload Unit: At the end of the graph update cycle, the smart contract automatically collects the knowledge graph design records uploaded to the blockchain collaborative chain during this cycle, and calls the semantic fusion algorithm to merge all the Cypher update statements involved in this cycle into Cypher statement fusion information. Based on the Cypher statement fusion information and the corresponding hash value, a data fusion record is generated and uploaded to the blockchain design chain.

[0020] Data publishing unit: The collaborative task publisher obtains the data fusion record from the blockchain design chain, applies it to the local database to form complete knowledge graph data, and uses the ontology inference engine to perform consistency verification. The complete knowledge graph data that passes the verification is then uploaded to the blockchain publishing chain.

[0021] Compared with the prior art, the advantages and positive effects of the present invention are as follows:

[0022] 1. To address the high time-sequential execution constraints and the inability to synchronize user messages in a timely manner due to system message delays in existing blockchain-based knowledge graph collaborative construction systems and methods, this invention adopts a clock cycle division approach. By rationally analyzing the knowledge graph construction process, the entire collaborative construction cycle is divided into an ontology upload cycle, an ontology design cycle, and an ontology fusion cycle, effectively reducing the blockchain's requirement for sequential execution.

[0023] 2. To address the issue of data inconsistency caused by low concurrency in existing blockchain networks, which leads to collaborative construction by multiple users, and considering the inherent limitations of existing single-chain storage methods for collaborative construction of knowledge graphs, this invention designs a multi-chain storage structure. Based on user usage cycles and the usage patterns of knowledge graph data types, system data is distributed to different sub-chains for maintenance, making the knowledge graph data processed by each sub-chain more consistent. This fully utilizes the computing resources of each node and improves the concurrent processing capability of the blockchain network.

[0024] 3. To address the issues of redundancy and conflict in existing technologies for managing user-submitted knowledge graph data, this invention proposes a semantic fusion algorithm. Based on the existing knowledge graph Cypher, it reduces data redundancy and improves storage efficiency by extracting and comparing node attribute relationships. Attached Figure Description

[0025] Figure 1 A schematic diagram illustrating the steps of a blockchain-based multi-person collaborative knowledge graph construction method provided by this invention;

[0026] Figure 2 The present invention provides a basis for Figure 1 A flowchart illustrating step S3;

[0027] Figure 3The present invention provides a basis for Figure 1 A flowchart illustrating step S6 in the middle section;

[0028] Figure 4 The present invention provides a basis for Figure 3 A flowchart illustrating step S62;

[0029] Figure 5 The present invention provides a basis for Figure 1 A flowchart illustrating step S7;

[0030] Figure 6 A schematic flowchart of an embodiment of a blockchain-based knowledge graph multi-person collaborative construction system provided by the present invention;

[0031] Figure 7 A schematic flowchart of an embodiment of a blockchain-based knowledge graph collaborative construction method provided by the present invention;

[0032] Figure 8 A flowchart illustrating the semantic fusion algorithm provided by this invention;

[0033] Figure 9 This invention provides an operation flowchart for the collaborative task publisher.

[0034] Figure 10 The flowchart for the operation of the atlas designer provided by this invention;

[0035] Figure 11 The sequence diagram for multi-person collaborative construction of a knowledge graph based on blockchain provided by this invention;

[0036] Figure 12 A schematic diagram of a multi-person collaborative construction model based on a blockchain knowledge graph provided by this invention;

[0037] Figure 13 This invention provides a blockchain-based knowledge graph multi-user collaborative construction system architecture diagram. Detailed Implementation

[0038] To make the objectives, technical solutions, and advantages of this application clearer, the application is described and illustrated below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application. All other embodiments obtained by those skilled in the art based on the embodiments provided in this application without inventive effort are within the scope of protection of this application.

[0039] Obviously, the accompanying drawings described below are merely some examples or embodiments of this application. Those skilled in the art can apply this application to other similar scenarios based on these drawings without any inventive effort. Furthermore, it is understood that although the efforts made in this development process may be complex and lengthy, for those skilled in the art related to the content disclosed in this application, any changes to design, manufacturing, or production based on the technical content disclosed in this application are merely conventional technical means and should not be construed as insufficient disclosure of the content of this application.

[0040] In this application, the reference to "embodiment" means that a specific feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of this application. The appearance of this phrase in various places in the specification does not necessarily refer to the same embodiment, nor is it a separate or alternative embodiment that is mutually exclusive with other embodiments. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described in this application may be combined with other embodiments without conflict.

[0041] Unless otherwise defined, the technical or scientific terms used in this application shall have the ordinary meaning understood by one of ordinary skill in the art to which this application pertains. The terms “a,” “an,” “an,” “the,” and similar words used in this application do not indicate quantity limitation and may indicate singular or plural. The terms “comprising,” “including,” “having,” and any variations thereof used in this application are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or device that includes a series of steps or modules (units) is not limited to the listed steps or units, but may also include steps or units not listed, or may include other steps or units inherent to these processes, methods, products, or devices. The terms “connected,” “linked,” “coupled,” and similar words used in this application are not limited to physical or mechanical connections, but may include electrical connections, whether direct or indirect. “Multiple” used in this application refers to two or more. “And / or” describes the relationship between related objects, indicating that three relationships may exist; for example, “A and / or B” can represent: A alone, A and B simultaneously, and B alone. The character " / " generally indicates that the preceding and following objects are in an "or" relationship. The terms "first," "second," and "third" used in this application are merely to distinguish similar objects and do not represent a specific ordering of the objects.

[0042] The present invention will now be described in detail with reference to the embodiments shown in the accompanying drawings. However, it should be noted that these embodiments are not intended to limit the present invention. Equivalent changes or substitutions in function, method, or structure made by those skilled in the art based on these embodiments are all within the scope of protection of the present invention.

[0043] Example 1:

[0044] Figure 1 This invention provides a schematic diagram illustrating the steps of a blockchain-based collaborative knowledge graph construction method. Figure 1 As shown in the figure, this embodiment discloses a specific implementation method for a blockchain-based knowledge graph collaborative construction method (hereinafter referred to as the "method").

[0045] To address the issues of "data silos" and information synchronization delays in collaborative knowledge graph construction, this embodiment provides a blockchain-based collaborative knowledge graph construction method. Utilizing the multi-chain collaborative working principle of blockchain, it cleverly separates user operations from system verification, providing a unified standard for user and system verification. With the coordination of clock cycles, fully high-concurrency operations can be achieved. Furthermore, through semantic fusion algorithms, newly added data is retained, duplicate data is filtered, and conflicting data is deleted. While ensuring normal system operation, incremental updates of data are achieved, reducing the data storage pressure on the blockchain.

[0046] Specifically, the method disclosed in this embodiment mainly includes the following steps:

[0047] Environment Deployment Step S1: Deploy the blockchain multi-chain network environment and IPFS environment, call the multi-chain partitioning rules to partition the blockchain network, and build IPFS; among them, the blockchain publishing chain is partitioned as the main chain, and the blockchain design chain and blockchain collaboration chain are partitioned as side chains.

[0048] Specifically, a multi-chain blockchain network environment and an interplanetary file system (IPFS) environment are deployed. The multi-chain partitioning rules are called to divide the blockchain network into multiple sub-chains. The correspondence between the sub-chains and the intelligent subsystems is written into the configuration file and stored on the gateway and the local server. Then, the cloud server is used as a node to build an IPFS private network.

[0049] IPFS, mentioned above, is a novel hypermedia text transfer protocol based on distributed storage technology, offering significant data storage capacity. This method utilizes IPFS for storing all large file data. The multi-chain partitioning rules include the following:

[0050] The release chain is designated as the main chain, serving as the stable version of the knowledge graph, corresponding to the official version of the software development. Ontology data on the release chain is published by administrators and remains in a stable state long-term; collaborative submissions by other users are not permitted.

[0051] In the above embodiments, the publishing chain serves as the system's main chain, responsible for the main functions of user registration, ontology data management, and ontology permission management.

[0052] The user registration process includes the introduction of a user management mechanism, which allows administrators to grant users on-the-spot management permissions.

[0053] The ontology data management includes managing ontology data, enabling dynamic updates and queries of ontology data, and providing off-chain SDK functions (receiving / responding to user requests, storing non-text data in IPFS, interacting with sub-chains, listening to main chain linkage events, processing and providing feedback).

[0054] The ontology permission management includes the function of managing ontology data permissions and setting which users can collaboratively manage ontology data.

[0055] In the above embodiments, the design chain is divided into branch chains, which serve as the branch chains for the knowledge graph design version and contain the latest updated data of the knowledge graph. The design chain collects update data from each collaborating user on the collaboration chain every T time interval, and this data serves as the initial data and consistency check data for the collaborating users at the start of the next T time interval. As the main branch for knowledge graph updates, collaborating users are generally not allowed to directly submit update data. Once the data on the design chain is basically complete, a smart contract is invoked to activate the semantic fusion algorithm, and the administrator verifies and publishes it to the release chain.

[0056] In the above embodiments, the design chain, as a sub-chain of the system, is responsible for the main functions of updating data management and updating data fusion.

[0057] Specifically, the update data management includes managing update data, enabling dynamic updating and querying of update data, and linking the release chain contract (initiating chain linkage requests, recording sub-chain linkage logs, and responding to other chain linkage requests).

[0058] Specifically, the updated data fusion includes the design of a fusion mechanism that periodically pulls data from the Cypher collaborative chain and performs updated data fusion operations.

[0059] The semantic fusion algorithm is used to integrate the updated data submitted by the graph designers during the current period after the graph update cycle T ends. The blockchain will use a smart contract to call the semantic fusion algorithm to integrate the updated data during the current period and upload the integrated updated data during the current period to the design chain.

[0060] In the above embodiments, the collaborative chain is divided into a branch chain, which serves as the main branch chain for collaborative users to publish and update data, and receives collaborative update data of the knowledge graph uploaded by collaborative users.

[0061] In the above embodiments, the collaborative chain, as a sub-chain of the system, includes the function of updating data management.

[0062] Specifically, the update data management includes managing update data, enabling dynamic updating and querying of update data, linking design chain contracts (initiating design chain linkage requests, recording sub-chain linkage logs, and responding to other chain linkage requests), and off-chain SDK (receiving / responding to user requests, storing non-text data in IPFS, interacting with sub-chains, listening to main chain linkage events, processing and responding).

[0063] In some embodiments, collaborative users initiate data access requests to the backend server of the knowledge graph multi-person collaborative construction system through their terminals. Considering the entire lifecycle of knowledge graph construction, the collaborative methods of each user are used as a reference to divide the entire lifecycle of the knowledge graph multi-person collaborative construction system. The relevant users participating in collaborative construction can participate in the collaborative construction tasks of the knowledge graph in the running phase of their respective lifecycles.

[0064] Initial data upload step S2: The collaborative task publisher creates knowledge graph ontology data for reference by graph designers, stores the ontology data of the knowledge graph in IPFS, generates a knowledge graph summary record based on the returned hash storage address and the hash value of the ontology data of the knowledge graph, and uploads it to the blockchain publishing chain;

[0065] Specifically, the ontology data of the knowledge graph is created and stored in IPFS, the corresponding hash storage address is returned, and a knowledge graph summary record is generated based on the hash storage address and the hash value of the ontology data of the knowledge graph and uploaded to the blockchain publishing chain.

[0066] Among them, such as Figure 2 As shown, the initial data upload step S2 includes:

[0067] Graph ontology data creation step S21: During the ontology upload cycle, the collaborative task publisher creates the ontology data of the knowledge graph and performs a consistency check. After the consistency check passes, the ontology data of the knowledge graph is stored in IPFS, and the returned hash storage address is obtained.

[0068] Graph ontology data step S22: Calculate the hash value of the ontology data of the knowledge graph using a hash algorithm, generate a knowledge graph summary record based on the hash storage address and hash value of the ontology data, and upload it to the blockchain publishing chain through the summary chaincode;

[0069] Standard data acquisition step S23: Obtain the knowledge graph summary record that needs to be coordinated from the blockchain publishing chain, obtain the hash storage address corresponding to the knowledge graph and the hash value of the ontology data of the knowledge graph, and create task information. Generate knowledge graph coordination task information based on the hash address, the task information and the hash value of the ontology data of the knowledge graph and upload it to the blockchain design chain as standard data.

[0070] Task release step S3: The collaborative task publisher creates knowledge graph collaborative task information, selects the knowledge graph version to be collaborated on, obtains the corresponding knowledge graph summary record from the blockchain release chain, obtains the hash storage address of the knowledge graph and the hash value of the knowledge graph ontology data through the knowledge graph summary record, generates knowledge graph collaborative task information based on the hash address, the task information and the hash value of the knowledge graph ontology data, and uploads it to the blockchain design chain. This information is used as initial data for multi-person collaboration and standard data for consistency checks during the graph update cycle.

[0071] Data design step S4: The graph designer obtains knowledge graph collaboration task information from the blockchain design chain, retrieves knowledge graph ontology data from IPFS based on the hash storage address in the knowledge graph collaboration task information, designs the knowledge graph based on the architecture of the ontology data and the knowledge graph triple data in the local database, and forms personal update data from the Cypher statements during the knowledge graph design.

[0072] Specifically, the latest knowledge graph collaborative task information is obtained from the blockchain design chain, and the corresponding hash storage address is obtained. Based on the hash storage address, the latest knowledge graph ontology data is obtained from IPFS and applied to the local design to form personal update data.

[0073] Specifically, data design step S4 includes: during the graph update cycle, the graph designer obtains the latest knowledge graph summary record from the blockchain design chain and determines whether the hash value in the knowledge graph summary record is consistent with the hash value stored locally; if so, the knowledge graph data is designed and updated locally; if not, the corresponding hash storage address is obtained from the blockchain design chain through the knowledge graph summary record, and the latest knowledge graph ontology data is obtained from IPFS according to the hash storage address and stored in the local knowledge graph database, and the knowledge graph data is designed and updated locally.

[0074] Collaborative data upload step S5: Before multiple graph designers upload data to the blockchain collaboration chain, they only need to use the ontology inference engine to check whether the standard data in the knowledge graph collaboration task information is consistent with the personal update data in the local database. If they are consistent, the personal update data and the corresponding hash value in the local database are used to generate a knowledge graph design record and upload it to the blockchain collaboration chain; otherwise, the upload is abandoned.

[0075] Specifically, the consistency between standard data and personal updated data is checked through the ontology inference engine, knowledge graph ontology design information is generated through personal updated data and corresponding hash values, and knowledge graph design records are generated and uploaded to the blockchain collaborative chain based on the knowledge graph ontology design information.

[0076] Update data fusion and upload step S6: When the graph update cycle ends, the smart contract automatically collects the knowledge graph design records uploaded to the blockchain collaborative chain during this cycle, and calls the semantic fusion algorithm to merge all the Cypher update statements involved in this cycle into Cypher statement fusion information. Based on the Cypher statement fusion information and the corresponding hash value, a data fusion record is generated and uploaded to the blockchain design chain.

[0077] Specifically, all knowledge graph ontology design information within this cycle is fused into Cypher statement fusion information through a semantic fusion algorithm. Data fusion records are generated based on the Cypher statement fusion information and the corresponding hash values ​​and uploaded to the blockchain design chain.

[0078] Among them, such as Figure 3 As shown, step S6 includes:

[0079] Hash value verification step S61: After the graph update cycle ends, obtain all knowledge graph design records in this cycle by downloading chaincode through knowledge design, and verify whether the hash value has been tampered with;

[0080] Semantic fusion step S62: If it has not been tampered with, use the semantic fusion algorithm to merge all Cypher update statements involved in the blockchain collaborative chain within this period into Cypher statement fusion information, and calculate the hash value;

[0081] Data fusion upload step S63: Generate a data fusion record based on the Cypher statement fusion information and the corresponding hash value, and upload the data fusion record to the blockchain design chain by calling the merge upload chaincode.

[0082] Furthermore, such as Figure 4 As shown, the semantic fusion step S62 includes:

[0083] First difference calculation step S621: Initialize all Cypher update statements involved in this period, calculate the intersection of the initialized Cypher update statements, and calculate the difference between the initialized Cypher update statements and the intersection as the first difference.

[0084] Data filtering step S622: Filter out conflicting and inconsistent data in the first difference;

[0085] Step S623 for obtaining fused data: Calculate the difference between the first difference and the conflicting data and inconsistent data as the second difference, and merge the intersection of the second difference and the initialized Cypher update statement to form Cypher statement fusion information;

[0086] Data fusion return step S624: If the Cypher statement fusion information is not empty, then return the Cypher statement fusion information; if the Cypher statement fusion information is empty, then return an error message.

[0087] In step S63, the data fusion record is generated based on the hash value of the Cypher statement fusion information, and then uploaded to the blockchain design chain by calling the merge upload chaincode.

[0088] Data publishing step S7: The collaborative task publisher obtains the data fusion record from the blockchain design chain, applies it to the local database to form complete knowledge graph data, and uses the ontology inference engine to perform consistency verification. The complete knowledge graph data that passes the verification is then uploaded to the blockchain publishing chain.

[0089] Specifically, the data fusion record is obtained from the blockchain design chain, and consistency verification is performed using the ontology inference engine. The verified data is then uploaded to the blockchain publishing chain.

[0090] Among them, such as Figure 5 As shown, step S7 includes:

[0091] Fusion data verification step S71: Obtain the data fusion record from the blockchain design chain by downloading the chaincode through the fusion record, and verify whether the hash value has been tampered with;

[0092] Data fusion release step S72: If the data has not been tampered with, the collaborative task publisher uses a semantic fusion algorithm to apply the Cypher statement fusion information to the local Cypher database for synchronization, obtain updated knowledge graph data, and upload it to the blockchain release chain.

[0093] Please refer to the following. Figure 6 , Figure 7 The specific application process of this method is explained as follows:

[0094] It should be noted that the roles and their corresponding Chinese standard interpretations in this embodiment are shown in Table 1:

[0095] Table 1

[0096]

[0097] The symbol names and their Chinese standard explanations in this embodiment are shown in Table 2:

[0098] Table 2

[0099]

[0100] like Figure 6 As shown, the system consists of an S1 user module, S2-S4 data processing modules, an S5 blockchain multi-chain storage module, an S6 information communication module, an S7 cycle control module, and an S8 large-file InterPlanetary File System (IPFS) storage module. The specific implementation steps of this method are as follows: Figure 7 As shown, the detailed steps are as follows:

[0101] S1: New user registration, global configuration. Executed by the CA module. When a new collaborative task publisher or ontology designer joins the system, the system automatically generates a public-private key pair for them.

[0102] S2: Knowledge Graph Data Initialization. This belongs to the ontology upload cycle. The collaborative task publisher creates a Minit and stores it in IPFS, retrieving the returned IPFS_Addr. The system calculates the HM based on the Minit, sends the HM and IPFS_Addr to MAI_Cupload, and combines them with other relevant information to generate an MAI_record, which is then uploaded to the BC publishing chain.

[0103] Specifically, the periodic division includes the ontology upload period, the graph update period, and the semantic fusion period.

[0104] The ontology upload cycle is as follows: the knowledge graph collaborative task publisher releases the knowledge graph ontology data, generates a graph summary file using a hash encryption algorithm, and uploads the summary information to the blockchain main chain for storage.

[0105] The graph update cycle refers to the process whereby the knowledge graph ontology designer uploads the updated ontology data, uses a semantic fusion algorithm to fuse the updated ontology data with the knowledge graph ontology data, generates fusion information and IPFS storage address information, and then uploads the information to the blockchain side chain collaborative chain for storage.

[0106] The semantic fusion cycle refers to the process where, after each graph update cycle ends, the smart contract deployed in the blockchain automatically uses a semantic fusion algorithm to fuse the data uploaded during the current graph update cycle, generate knowledge graph fusion information and IPFS storage address information, and then uploads the information to the blockchain branch design chain for storage.

[0107] Specifically, in step S2, the collaborative task publisher's operation process is as follows: Figure 9 As shown, the following steps are included:

[0108] a) The collaborative task publisher creates a Minit and stores it in IPFS, then retrieves the returned IPFS_Addr. Based on the Minit, the system calculates the HM, sends the HM and IPFS_Addr to MAI_Cupload, and combines them with other relevant information to generate an MAI_record, which is then uploaded to the BC publishing chain.

[0109] It should be noted that Minit represents knowledge graph ontology data. When there is no knowledge graph data in the system, the collaborative task publisher needs to upload knowledge graph ontology data. This data will only be retained once in the system. Subsequent modifications will only retain the modification steps and will not directly modify the knowledge graph ontology data.

[0110] b) Determine whether the current cycle is in the stage of subject upload or subject update. If yes, proceed to step c); otherwise, proceed to step d).

[0111] c) The collaborative task issuer uses smart contracts to obtain the latest updated data on the blockchain design chain;

[0112] It should be added that the data on the blockchain design chain is automatically generated by smart contracts using semantic fusion algorithms from the blockchain collaborative chain after the graph update cycle ends.

[0113] d) Waiting to enter the ontology upload and ontology update stage;

[0114] e) Verify whether the hash in the newly acquired data is consistent with the hash stored locally. If it is, loop back to step b); otherwise, proceed to step f.

[0115] Specifically, the newly acquired data in step e) refers to the latest updated data on the blockchain design chain obtained by the collaborative task issuer using a smart contract in step c).

[0116] It should be noted that the main step in this process is to verify whether the data has been modified. If the data has been modified, the party issuing the collaborative task needs to apply the data on the blockchain collaborative chain to the local knowledge graph database to synchronize the local data with the on-chain data. If the data has not been modified, no synchronization is required.

[0117] f) Update the local knowledge graph data using semantic fusion methods and update the locally stored hash;

[0118] Specifically, in step f), updating the local knowledge graph data requires applying the newly acquired data from step e) to the existing local knowledge graph data.

[0119] g) Upload local knowledge graph data to IPFS, and upload the returned address information and other information to the BC publishing chain;

[0120] It should be noted that, similar to step a), step g) requires the collaborative task publisher to upload the knowledge graph ontology data, replacing the knowledge graph ontology data as the latest publicly available version, but the knowledge graph ontology data in step a) will not be deleted.

[0121] h) Determine if the knowledge graph design is complete. If yes, the program is complete and exits; otherwise, proceed to step b).

[0122] Specifically, in step S2, the knowledge graph ontology data is a construction statement containing complete triple information of the knowledge graph. Users can directly pull this data to build a complete knowledge graph in the local knowledge graph database.

[0123] Specifically, IPFS is a distributed file storage system that stores data in the form of files and identifies files by generating unique hash values ​​through file content. IPFS is used to store knowledge graph ontology data, thereby reducing the storage and bandwidth pressure on blockchain networks.

[0124] S3: Before the start of the map update cycle, the collaborative task publisher uploads the standard data that needs to be collaboratively designed within this cycle to the design chain.

[0125] Specifically, in step S3, standard data refers to the construction statements for complete triple information of the knowledge graph.

[0126] S4: Knowledge Graph Data Acquisition and Design. This belongs to the knowledge graph update cycle. The graph designer acquires the latest knowledge graph data for design. The graph designer obtains the latest MAI_record from the BC design chain and verifies whether MD is unique. If the verification passes, the graph designer obtains Mnew from IPFS based on IPFS_Addr and designs Mnew.

[0127] Specifically, in step S4, the flowchart for the map designer's operation is as follows: Figure 10 As shown, the following steps are included:

[0128] a) Determine if it is in a map update cycle. If yes, proceed to step c); otherwise, proceed to step b).

[0129] b) Waiting for the map update cycle to begin;

[0130] c) The graph designer obtains the latest MAI_record from the BC design chain and verifies the hash;

[0131] It should be added that the map update cycle is executed sequentially. Before designing the ontology data update, the map designer needs to verify that their local data is the latest data of the current map update cycle.

[0132] d) Determine if the hash in the newly acquired data is consistent with the hash stored locally. If yes, proceed to step f); otherwise, proceed to step e.

[0133] e) The map designer uses MAI_record to obtain IPFS_Addr, and retrieves the latest data information from IPFS to apply locally, forming a hash and saving it locally;

[0134] It should be added that MAI_record is data that exists on the blockchain. The graph designer needs to use smart contracts to query the latest MAI_record data and parse out the IPFS_Addr data information.

[0135] f) Knowledge graph designers design and update knowledge graph data locally;

[0136] It should be added that when knowledge graph designers design and update knowledge graph data locally, it is a completely offline operation that will not affect the existing data in the system, nor will it change the existing data.

[0137] g) Graph designers use semantic fusion algorithms to obtain MDI and calculate HMDI;

[0138] h) Determine whether the map designer needs to upload local data to the system. If yes, proceed to step r); otherwise, proceed to step j.

[0139] r) The system sends the HMDI to MDI_Cupload and combines it with other relevant information to generate an MDIrecord, which is then uploaded to the BC collaboration chain;

[0140] j) Determine whether the design of knowledge graph data needs to continue. If yes, proceed to step a); otherwise, the program completes and exits.

[0141] S5: Before the end of this graph update cycle, the graph designer can use the semantic fusion algorithm to obtain the MDI and calculate the HMDI. The system will send the HMDI to MDI_Cupload and combine it with other relevant information to generate an MDI record and upload it to the BC collaborative chain.

[0142] Specifically, in step S5, the graph designer does not need to upload the complete triplet information of the knowledge graph; they only need to upload their own updated data for this stage to the system.

[0143] S6: Knowledge Graph Ontology Update Data Fusion. This belongs to the semantic fusion cycle. After each graph update cycle ends, BC automatically uses MDI_Cdownload to retrieve all MDI records within this cycle and verifies whether the hash values ​​have been tampered with. If they have not been tampered with, the semantic fusion algorithm is used to fuse all MDIs into MFDI and calculate HMFDI. The HMFDI is combined with other relevant information to generate MFDI_record. Finally, the system calls MFDI_Cupload to upload the MFDI_record to the BC design chain.

[0144] Specifically, the flowchart of the semantic fusion algorithm mentioned in step S6 is as follows: Figure 8 As shown, the specific steps include the following:

[0145] Step 1: Receive knowledge graph Cypher ontology update data from multiple users: kg0, kg1;

[0146] Step 2: Initialize the user-input ontology update data kg0 and kg1, standardize the statement format and simplify the query statement to form k0 and k1;

[0147] Step 3: Calculate the intersection k of the updated ontology data k0 and k1 after user initialization. * If k * If ! = null, then k will be... * Set partitioning and storage;

[0148] Step 4: Calculate the updated ontology data k0, k1 and set k after user initialization. * The differences g0 and g1 are used as input parameters for knowledge data conflict verification;

[0149] Step 5: Filter out conflicting and inconsistent data s in g0 and g1. * ;

[0150] Step 6: Connect g0, g1, and inconsistent data s * Calculate the difference and then compare the difference with k. * Merge to form integrated data Δ * ;

[0151] Step 7; If Δ * If not empty, then return k. * Δ * If Δ * If empty, an error message will be returned.

[0152] Specifically, the aforementioned knowledge graph Cypher is a declarative graph query language. Cypher borrows the structure of SQL, allowing for expressive and efficient querying, updating, and management of graphs, and can easily express highly complex database queries.

[0153] S7-S8: Knowledge Graph Data Publication. This belongs to the ontology upload cycle. The collaborative task publisher uses MFDI_Cdownload to obtain MFDI_record from the BC design chain and verifies its hash value to ensure it has not been tampered with. The collaborative task publisher uses a semantic fusion algorithm to apply MFDI to the local Cypher database for synchronization, and then uploads the Knowledge Graph to IPFS.

[0154] It should be noted that, considering system availability, steps S7 and S8 can be combined into one step for execution.

[0155] It should be noted that the participating users and servers must have the necessary memory and hard disk space to deploy the Hyperledger Fabric blockchain and IPFS runtime environment; otherwise, the blockchain multi-chain network and / or IPFS network will not be able to run properly.

[0156] The following is for reference Figure 11 , Figure 12 The present invention will be further described in detail with reference to the embodiments.

[0157] The data gateway and server have a blockchain operating environment deployed internally, and have implemented a multi-chain partitioning method to construct one main chain and two sub-chains. The relevant configuration information for the multi-chain network has been saved within the gateway and server. An IPFS private network has been deployed and is running on the server, capable of storing encrypted data and retrieving encrypted data content based on the IPFS storage address. The key generation mechanism has been initialized. This application embodiment includes the following steps:

[0158] S1: Global configuration. Executed by the CA module. When UserA, the publisher of collaborative tasks, and UserB and UserC, the ontology designers, join the system, the system will automatically generate public-private key pairs for them.

[0159] S2: UserA initializes the knowledge graph data. During the ontology upload cycle, UserA creates knowledge graph ontology data α_1. After the consistency check passes, the ontology data α_1 is stored in IPFS, and the returned IPFS_Addr is obtained. HM is calculated according to the hash algorithm. The system sends HM and IPFS_Addr to MAI_Cupload and combines them with other relevant information to generate MAI_record, which is then uploaded to the BC release chain, forming the public version data V0.1.

[0160] S3: When entering the graph update cycle, the publicly available version data V0.1 on the release chain will be pulled to the design chain as the initial version data for this design cycle;

[0161] S4: UserA modifies the ontology data α_1 to A_1 locally;

[0162] S5: UserA queries the latest data on the design chain, compares the hash with the local hash, and uses the ontology inference engine to perform a consistency check.

[0163] S6: If the hashes are different and the consistency check passes, store the ontology data A_1 in IPFS, obtain the returned IPFS_Addr, calculate the HMDI, send the HMDI to MDI_Cupload, and combine it with other relevant information to generate an MDIrecord and upload it to the BC collaboration chain.

[0164] It should be noted that the MDIrecord information uploaded by UserA only contains the data updated this time.

[0165] Specifically, the updated data refers to the modified data of the original knowledge graph, and does not include the complete knowledge graph data.

[0166] S7: After the end of this design cycle, the smart contract calls the semantic fusion algorithm to fuse the ontology data information uploaded to the design chain during this cycle. After being verified by the collaborative task publisher UserA, it is uploaded to the BC release chain to form the public version data V0.2.

[0167] S8: When entering the graph update cycle, the publicly available version data V0.2 on the release chain will be pulled to the design chain as the initial version data for this design cycle;

[0168] S9: Knowledge graph designers UserB and UserC obtain the public version data V0.2 from the BC design chain and retrieve the knowledge graph data from IPFS according to IPFS_Addr;

[0169] S10: UserB and UserC design knowledge graph data locally to form ontology data B_1 and ontology data C_1;

[0170] S11: UserB and UserC compare the hash of the latest data on the query chain with the local hash, and use the ontology inference engine to perform a consistency check.

[0171] S12: If the hashes are different and the consistency check passes, store the ontology data C_1 in IPFS, obtain the returned IPFS_Addr, calculate the HMDI, send the HDDI to MDI_Cupload, and combine it with other relevant information to generate an MDI record and upload it to the BC collaboration chain.

[0172] S13: If the consistency check fails, UserB modifies the knowledge graph data locally to form ontology data B_2;

[0173] S14: UserB queries the latest data on the design chain, compares the hash with the local hash, and uses a semantic fusion algorithm to perform a consistency check.

[0174] S15: If the hashes are different and the consistency check passes, store the ontology data B_2 in IPFS, obtain the returned IPFS_Addr, calculate the HMDI, send the HMDI to MDI_Cupload, and combine it with other relevant information to generate an MDIrecord and upload it to the BC collaboration chain.

[0175] S16: After the end of this design cycle, the smart contract calls the semantic fusion algorithm to fuse the ontology data information uploaded to the design chain during this cycle. After being verified by the collaborative task publisher UserA, it is uploaded to the BC release chain to form the public version data V1.1.

[0176] Example 2:

[0177] Based on the blockchain-based knowledge graph multi-person collaborative construction method disclosed in Embodiment 1, this embodiment discloses a specific implementation example of a blockchain-based knowledge graph multi-person collaborative construction system (hereinafter referred to as "the system").

[0178] Reference Figure 13 As shown, the system includes:

[0179] Environment Deployment Unit 1: Deploy the blockchain multi-chain network environment and IPFS environment, call the multi-chain partitioning rules to partition the blockchain network, and build IPFS; among them, the blockchain release chain is partitioned as the main chain, and the blockchain design chain and blockchain collaboration chain are partitioned as side chains;

[0180] Initial Data Upload Unit 2: The collaborative task publisher creates knowledge graph collaborative task information, selects the knowledge graph version to be collaborated on, obtains the corresponding knowledge graph summary record from the blockchain publishing chain, obtains the hash storage address of the knowledge graph and the hash value of the knowledge graph ontology data through the knowledge graph summary record, and generates knowledge graph collaborative task information based on the hash address, the task information and the hash value of the knowledge graph ontology data and uploads it to the blockchain design chain. This information is used as initial data for multi-person collaboration and standard data for consistency checks during the graph update cycle.

[0181] Specifically, the initial data upload unit 2 includes:

[0182] Knowledge graph ontology data creation module 21: During the ontology upload cycle, the collaborative task publisher creates ontology data of the knowledge graph and performs a consistency check. After the consistency check passes, the ontology data of the knowledge graph is stored in IPFS and the returned hash storage address is obtained.

[0183] Knowledge graph ontology data upload module 22: calculates the hash value of the ontology data of the knowledge graph using a hash algorithm, generates a knowledge graph summary record based on the hash storage address and hash value of the ontology data, and uploads it to the blockchain publishing chain through the summary chaincode;

[0184] Standard data acquisition module: Obtains the summary records of the knowledge graph to be collaborated on from the blockchain publishing chain, obtains the hash storage address corresponding to the knowledge graph and the hash value of the ontology data of the knowledge graph, and creates task information. Based on the hash address, the task information and the hash value of the ontology data of the knowledge graph, it generates knowledge graph collaboration task information and uploads it to the blockchain design chain as standard data.

[0185] Task Publishing Unit 3: The collaborative task publisher creates knowledge graph collaborative task information, selects the knowledge graph version to be collaborated on, retrieves the corresponding knowledge graph summary record from the blockchain publishing chain, obtains the hash storage address of the knowledge graph and the hash value of the knowledge graph ontology data from the knowledge graph summary record, and generates knowledge graph collaborative task information based on the hash address, the task information, and the hash value of the knowledge graph ontology data. This information is then uploaded to the blockchain design chain and used as initial data for multi-person collaboration and standard data for consistency checks during the graph update cycle.

[0186] Data Design Unit 4: The graph designer obtains knowledge graph collaboration task information from the blockchain design chain, retrieves knowledge graph ontology data from IPFS based on the hash storage address in the knowledge graph collaboration task information, designs the knowledge graph based on the architecture of the ontology data and the knowledge graph triple data in the local database, and forms personal update data from the Cypher statements during the knowledge graph design.

[0187] Specifically, the data design unit 4 includes: during the graph update cycle, the graph designer obtains the latest knowledge graph summary record from the blockchain design chain, and determines whether the hash value in the knowledge graph summary record is consistent with the hash value stored locally; if so, the knowledge graph data is designed and updated locally; if not, the corresponding hash storage address is obtained from the blockchain design chain through the knowledge graph summary record, and the latest knowledge graph ontology data is obtained from IPFS according to the hash storage address and stored in the local knowledge graph database, and the knowledge graph data is designed and updated locally.

[0188] Collaborative Data Upload Unit 5: Before multiple graph designers upload data to the blockchain collaborative chain, they only need to use the ontology inference engine to check whether the standard data in the knowledge graph collaborative task information is consistent with the personal update data in the local database. If they are consistent, the personal update data and the corresponding hash value in the local database will be used to generate a knowledge graph design record and upload it to the blockchain collaborative chain; otherwise, the upload will be abandoned.

[0189] Update Data Fusion Upload Unit 6: When the graph update cycle ends, the smart contract automatically collects the knowledge graph design records uploaded to the blockchain collaborative chain during this cycle, and calls the semantic fusion algorithm to merge all the Cypher update statements involved in this cycle into Cypher statement fusion information. Based on the Cypher statement fusion information and the corresponding hash value, a data fusion record is generated and uploaded to the blockchain design chain.

[0190] Specifically, the update data fusion and upload unit 6 includes:

[0191] Hash value verification module 61: After the graph update cycle ends, the chaincode is downloaded through knowledge design to obtain all knowledge graph design records in this cycle and verify whether the hash value has been tampered with.

[0192] Semantic fusion module 62: If it has not been tampered with, use the semantic fusion algorithm to merge all Cypher update statements involved in the blockchain collaborative chain within this period into Cypher statement fusion information, and calculate the hash value;

[0193] Data fusion upload module 63: Generates a data fusion record based on the Cypher statement fusion information and the corresponding hash value, and uploads the data fusion record to the blockchain design chain by calling the merge upload chaincode.

[0194] Furthermore, the semantic fusion module 62 includes:

[0195] First difference calculation module 621: Initializes all knowledge graph ontology design information in this period, calculates the intersection of the initialized knowledge graph ontology design information, and calculates the difference between the initialized knowledge graph ontology design information and the intersection as the first difference;

[0196] Data filtering module 622: Filters out conflicting and inconsistent data in the first difference;

[0197] Data fusion acquisition module 623: calculates the difference between the first difference and the conflicting data and inconsistent data as the second difference, and merges the intersection of the second difference and the initialized knowledge graph ontology design information to form Cypher statement fusion information;

[0198] Data fusion return module 624: If the Cypher statement fusion information is not empty, the Cypher statement fusion information is returned; if the Cypher statement fusion information is empty, an error message is returned.

[0199] The data fusion upload module 63 generates a data fusion record based on the hash value of the Cypher statement fusion information, and uploads the data fusion record to the blockchain design chain by calling the merge upload chaincode.

[0200] Data Publishing Unit 7: The collaborative task publisher obtains the data fusion record from the blockchain design chain, applies it to the local database to form complete knowledge graph data, and uses an ontology inference engine to perform consistency verification. The verified complete knowledge graph data is then uploaded to the blockchain publishing chain.

[0201] Specifically, the data publishing unit 7 includes:

[0202] Fusion Data Verification Module 71: Obtains data fusion records from the blockchain design chain by downloading chaincode through fusion records, and verifies whether the hash value has been tampered with;

[0203] Data fusion publishing module 72: If the data has not been tampered with, the collaborative task publisher uses a semantic fusion algorithm to apply the Cypher statement fusion information to the local Cypher database for synchronization, obtain updated knowledge graph data, and upload it to the blockchain publishing chain.

[0204] The technical solutions for the same parts of the blockchain-based knowledge graph multi-person collaborative construction system disclosed in this embodiment and the blockchain-based knowledge graph multi-person collaborative construction method disclosed in Embodiment 1 are described in Embodiment 1 and will not be repeated here.

[0205] The technical features of the above-mentioned embodiments can be combined arbitrarily. In order to make the description concise, not all possible combinations of the technical features in the above-mentioned embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0206] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are relatively specific and detailed, they should not be construed as limiting the scope of the invention patent. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this patent application should be determined by the appended claims.

Claims

1. A multi-person collaborative construction method for knowledge graphs based on blockchain, characterized in that, include: Initial data upload steps: The collaborative task publisher creates knowledge graph ontology data for reference by graph designers, stores the knowledge graph ontology data in IPFS, generates a knowledge graph summary record based on the returned hash storage address and the hash value of the knowledge graph ontology data, and uploads it to the blockchain publishing chain; Task publishing steps: The collaborative task publisher creates knowledge graph collaborative task information, selects the knowledge graph version to be collaborated on, obtains the corresponding knowledge graph summary record from the blockchain publishing chain, generates knowledge graph collaborative task information by combining the knowledge graph summary record with the hash value of the task information and knowledge graph ontology data, and uploads it to the blockchain design chain. This information is used as initial data for multi-person collaboration and standard data for consistency checks during the graph update cycle. Data design steps: The graph designer obtains knowledge graph collaboration task information from the blockchain design chain, retrieves knowledge graph ontology data from IPFS based on the hash storage address in the knowledge graph collaboration task information, designs the knowledge graph based on the architecture of the ontology data and the knowledge graph triple data in the local database, and forms personal update data from the Cypher statements during the knowledge graph design. Collaborative data upload steps: Before multiple graph designers upload data to the blockchain collaboration chain, they only need to use the ontology inference engine to check whether the standard data in the knowledge graph collaboration task information is consistent with the personal update data in the local database. If they are consistent, the personal update data and the corresponding hash value in the local database will be used to generate a knowledge graph design record and upload it to the blockchain collaboration chain; otherwise, the upload will be abandoned. Update data fusion and upload steps: At the end of the graph update cycle, the smart contract automatically collects the knowledge graph design records uploaded to the blockchain collaborative chain during this cycle, and calls the semantic fusion algorithm to merge all the Cypher update statements involved in this cycle into Cypher statement fusion information. Based on the Cypher statement fusion information and the corresponding hash value, a data fusion record is generated and uploaded to the blockchain design chain. Data publishing steps: The collaborative task publisher obtains the data fusion record from the blockchain design chain, applies it to the local database to form complete knowledge graph data, and uses the ontology inference engine to perform consistency verification. The complete knowledge graph data that passes the verification is then uploaded to the blockchain publishing chain.

2. The knowledge graph collaborative construction method according to claim 1, characterized in that, The initial data upload step includes: Knowledge graph ontology data creation steps: During the ontology upload cycle, the collaborative task publisher creates the ontology data of the knowledge graph and uses the ontology inference engine to perform consistency checks. After the consistency check passes, the ontology data of the knowledge graph is stored in IPFS, and the returned hash storage address is obtained. Knowledge graph ontology data upload steps: Calculate the hash value of the knowledge graph ontology data using a hash algorithm, generate a knowledge graph summary record based on the hash storage address and hash value of the ontology data, and upload it to the blockchain publishing chain via the summary chaincode; Standard data acquisition steps: Obtain the summary record of the knowledge graph to be collaborated on from the blockchain publishing chain, obtain the hash storage address corresponding to the knowledge graph and the hash value of the knowledge graph ontology data, and create task information. Generate knowledge graph collaboration task information based on the hash storage address, the task information and the hash value of the knowledge graph ontology data, and upload it to the blockchain design chain as standard data.

3. The knowledge graph collaborative construction method according to claim 1, characterized in that, The task publishing steps include: the collaborative task publisher creates knowledge graph collaborative task information, selects the knowledge graph version to be collaborated on, obtains the corresponding knowledge graph summary record from the blockchain publishing chain, obtains the hash storage address of the knowledge graph and the hash value of the knowledge graph ontology data through the knowledge graph summary record, generates knowledge graph collaborative task information based on the hash storage address, the task information and the hash value of the knowledge graph ontology data, and uploads it to the blockchain design chain, which is used as the initial data for multi-person collaboration and the standard data for consistency checks during the graph update cycle.

4. The knowledge graph collaborative construction method according to claim 1, characterized in that, The data design steps include: during the graph update cycle, the graph designer obtains the latest knowledge graph collaboration task information from the blockchain design chain, and determines whether the hash value of the knowledge graph ontology data in the knowledge graph collaboration task information is consistent with the hash value stored locally; if yes, the knowledge graph data is designed and updated locally; if no, the hash storage address corresponding to the knowledge graph is obtained from the knowledge graph collaboration task information, and the latest knowledge graph ontology data is obtained from IPFS according to the hash storage address and stored in the local knowledge graph database, and the knowledge graph data is designed and updated locally to form personal updated data.

5. The knowledge graph collaborative construction method according to claim 1, characterized in that, The updated data fusion and upload steps include: Hash value verification steps: After the graph update cycle ends, download the chaincode through knowledge design to obtain all knowledge graph design records within this cycle, and verify whether the hash value has been tampered with; Semantic fusion steps: If the information has not been tampered with, use the semantic fusion algorithm to merge all Cypher update statements involved in the blockchain collaborative chain within this cycle into Cypher statement fusion information, and calculate the hash value; Data fusion upload steps: Generate a data fusion record based on the Cypher statement fusion information and the corresponding hash value, and upload the data fusion record to the blockchain design chain by calling the merge upload chaincode.

6. The knowledge graph collaborative construction method according to claim 5, characterized in that, The semantic fusion steps include: The first difference calculation step is to initialize all Cypher update statements involved in this period, calculate the intersection of the initialized Cypher update statements, and calculate the difference between the initialized Cypher update statements and the intersection as the first difference. Data filtering steps: Filter out conflicting and inconsistent data in the first difference; Data fusion acquisition steps: Calculate the difference between the first difference and the conflicting data and inconsistent data as the second difference, and merge the intersection of the second difference and the initialized Cypher update statement to form Cypher statement fusion information; Data fusion return steps: If the Cypher statement fusion information is not empty, then return the Cypher statement fusion information; if the Cypher statement fusion information is empty, then return an error message.

7. The knowledge graph collaborative construction method according to claim 1, characterized in that, The data publishing steps include: Data fusion verification steps: Download chaincode from the blockchain design chain through the fusion record to obtain the data fusion record and verify whether the hash value has been tampered with; Data fusion and release steps: If the data has not been tampered with, the collaborative task publisher uses a semantic fusion algorithm to apply the Cypher statement fusion information to the local Cypher database for synchronization, obtain updated knowledge graph data, and upload it to the blockchain release chain.

8. The knowledge graph collaborative construction method according to claim 1, characterized in that, Also includes: Environment deployment steps: Deploy the blockchain multi-chain network environment and IPFS environment, call the multi-chain partitioning rules to partition the blockchain network, and build IPFS; among them, the blockchain publishing chain is partitioned as the main chain, and the blockchain design chain and blockchain collaboration chain are partitioned as side chains.

9. A blockchain-based knowledge graph multi-user collaborative construction system, used to implement the knowledge graph multi-user collaborative construction method according to any one of claims 1-7, characterized in that, include: Environment Deployment Unit: Deploys the blockchain multi-chain network environment and IPFS environment, calls the multi-chain partitioning rules to partition the blockchain network, and builds IPFS; among them, the blockchain release chain is partitioned as the main chain, and the blockchain design chain and blockchain collaboration chain are partitioned as side chains; Initial data upload unit: Creates ontology data of the knowledge graph and stores it in IPFS, returns the corresponding hash storage address, generates a knowledge graph summary record based on the hash storage address and the hash value of the ontology data of the knowledge graph, and uploads it to the blockchain publishing chain; Task Publishing Unit: The collaborative task publisher creates knowledge graph collaborative task information, selects the knowledge graph version to be collaborated on, obtains the corresponding knowledge graph summary record from the blockchain publishing chain, obtains the hash storage address of the knowledge graph and the hash value of the knowledge graph ontology data through the knowledge graph summary record, and generates knowledge graph collaborative task information based on the hash storage address, the task information and the hash value of the knowledge graph ontology data and uploads it to the blockchain design chain. This information is used as initial data for multi-person collaboration and standard data for consistency checks during the graph update cycle. Data Design Unit: Knowledge graph designers obtain knowledge graph collaboration task information from the blockchain design chain, retrieve knowledge graph ontology data from IPFS based on the hash storage address in the knowledge graph collaboration task information, design the knowledge graph based on the architecture of the ontology data and the knowledge graph triple data in the local database, and form personal update data from the Cypher statements during the knowledge graph design. Collaborative Data Upload Unit: Before multiple graph designers upload data to the blockchain collaborative chain, they only need to use the ontology inference engine to check whether the standard data in the knowledge graph collaborative task information is consistent with the personal update data in the local database. If they are consistent, the personal update data and the corresponding hash value in the local database are used to generate a knowledge graph design record and upload it to the blockchain collaborative chain; otherwise, the upload is abandoned. Update Data Fusion Upload Unit: At the end of the graph update cycle, the smart contract automatically collects the knowledge graph design records uploaded to the blockchain collaborative chain during this cycle, and calls the semantic fusion algorithm to merge all the Cypher update statements involved in this cycle into Cypher statement fusion information. Based on the Cypher statement fusion information and the corresponding hash value, a data fusion record is generated and uploaded to the blockchain design chain. Data publishing unit: The collaborative task publisher obtains the data fusion record from the blockchain design chain, applies it to the local database to form complete knowledge graph data, and uses the ontology inference engine to perform consistency verification. The complete knowledge graph data that passes the verification is then uploaded to the blockchain publishing chain.

10. The knowledge graph multi-person collaborative construction system according to claim 9, characterized in that, The initial data upload unit includes: Knowledge graph ontology data creation module: During the ontology upload cycle, the collaborative task publisher creates the ontology data of the knowledge graph and performs a consistency check. After the consistency check passes, the ontology data of the knowledge graph is stored in IPFS and the returned hash storage address is obtained. Knowledge graph ontology data upload module: calculates the hash value of the ontology data of the knowledge graph using a hash algorithm, generates a knowledge graph summary record based on the hash storage address and hash value of the ontology data, and uploads it to the blockchain publishing chain through the summary chaincode; Standard data acquisition module: Obtains the summary records of the knowledge graph to be collaborated on from the blockchain publishing chain, obtains the hash storage address corresponding to the knowledge graph and the hash value of the ontology data of the knowledge graph, and creates task information. Based on the hash address, the task information and the hash value of the ontology data of the knowledge graph, it generates knowledge graph collaboration task information and uploads it to the blockchain design chain as standard data.

11. The knowledge graph multi-person collaborative construction system according to claim 9, characterized in that, The updated data fusion and upload unit includes: Hash value verification module: After the graph update cycle ends, the chaincode is downloaded through knowledge design to obtain all knowledge graph design records within this cycle, and the hash value is verified to see if it has been tampered with. Semantic fusion module: If it has not been tampered with, the semantic fusion algorithm is used to merge all Cypher update statements involved in the blockchain collaborative chain within this cycle into Cypher statement fusion information, and the hash value is calculated; Data fusion upload module: Generates a data fusion record based on the Cypher statement fusion information and the corresponding hash value, and uploads the data fusion record to the blockchain design chain by calling the merge upload chaincode.

Images