The idea of a Semantic Web was proposed by Tim Berners-Lee at the very first World Wide Web Conference in 1994 (Shadbolt et al., 2006). Many years later, however, it has still not been fully realized. The technology stack for implementation of the Semantic Web was later standardized by the W3C organization. The semantic Web is designed to be an extension of the World Wide Web, where the meaning of information is well defined. The main focus is put on the data instead of the documents. On the Semantic Web, data is presented by entities and the relations between them.

The basis for a Semantic Web are unique identifiers of resources that can be used to reference and differentiate between the resources. For that purpose, we use uniform resource identifiers (URI). The most common type of a URI is the URL that defines the protocol and the location on the computer network required for accessing a resource.

In addition to resource identifiers, another technology defined by the W3C is the data model for representing information. W3C standardized the use of the Resource Description Framework (RDF) model, described by Decker et al. (2000), for data representation on the Semantic Web. The RDF model uses simple statements to describe resources and connections between them. When working with ontologies, it is useful to have some unified sets of relations that can be used to describe entities. For this purpose, the RDFS and the OWL languages were created to expand the RDF and provide better descriptiveness (McBride, 2004; Horrocks et al., 2003; McGuinness and Van Harmelen, 2004).

The Semantic technology stack also defines the SPARQL language described by Pérez et al. (2006). SPARQL is a language for querying an ontology. It supports a set of statements for retrieving data from an ontology. It also supports commands for inserting and deleting relations captured in an ontology. The specification also defines some other standards that are not relevant to our proposed system.

In this work, we focus mostly on the part of the Semantic Web related to building ontologies. The ontologies are considered to be the backbone of the Semantic Web (Taye, 2010). In the field of computer science, ontology is a model of entities and the relations between them (Stevens et al., 2000; Noy and McGuinness, 2001). Ontologies have become one of the most common representations for storing general human knowledge in computer systems (Noy and McGuinness, 2001). Over the last years, many different ontologies have been built with the aim of capturing as much Semantic knowledge as possible (Lehmann et al., 2015; Bollacker et al., 2008; Speer and Havasi, 2012; Shortliffe, 1976; Donnelly, 2006). One of the best-known ontologies is DBpedia (Lehmann et al., 2015), which contains general knowledge gathered from infoboxes on Wikipedia. We decided to demonstrate our system on the DBpedia ontology. Ontologies can also contain more specific domain knowledge. For instance, the SNOMED CT (Donnelly, 2006) ontology and the MYCIN (Shortliffe, 1976) ontology contain medical information designed to help doctors with their work.

The rise of blockchain technology started with the cryptocurrency Bitcoin in 2009 (Nakamoto, 2009) when a peer-to-peer electronic cash system was presented to allow online payments to be sent to people without the need for centralized intermediaries. This has also solved the double-spending problem. However, the idea of a chain of blocks secured by cryptography was introduced by Stuart Haber for timestamping digital documents in 1991 (Haber and Stornetta, 1991).

Blockchain technology has been evolving through generations. First-generation (Bitcoin, Litecoin, Dogecoin) was focused on creating a digital currency. The second-generation (Ethereum Classic) extended the concept to the use of smart contracts. They enable more advanced use cases besides the transfer of currency to support the digital economy. Smart contracts follow the terms of the agreement. An example of such platform is Ethereum but in the early stages, such smart contracts were error-prone and contained security vulnerabilities. Ethereum co-founder Gavin Wood even coined the term web3 as a decentralized online ecosystem based on blockchain. It could be the future of the world wide web (Edelman, 2021). The third generation (Cardano, Polkadot) created blockchain applications. With them, we can create a digital society where people could participate in broader economic activity in the areas such as health, art, education, and culture (Efanov and Roschin, 2018). Based on accessibility we can differentiate between consortium, private and public blockchains. In public blockchains, anyone can join the network and participate in it. In private blockchains, only a selected few participants can be part of the network. Consortium blockchains have properties of both public and private networks. For consortium blockchains, permissions can be set as needed. They can be used to connect people from multiple organizations.

With smart contracts on Ethereum other cryptocurrencies or tokens can be created. Fungible tokens like Ether can be exchanged and traded as they are identical. On the other hand, we have non-fungible tokens. Each such token is unique and is not identical to other tokens. They can be used to represent rights, identities, and other real-world items such as art. In our application, we only use the ether tokens, which are fungible to pay for smart contract operations. The use of custom tokens is interesting for future expansion, as they could be used for the purpose of managing user permissions or as a payment for certain operations on the ontology.

The combination of Semantic Web and blockchain technologies has seen some attention in the literature recently. One project combining the two technologies was presented by Hector and Boris (2020). They created an interface in the form of an ontology called BLONDiE, that uses a Semantic representation to convey the current information about a blockchain. Multiple projects also explored ways of using blockchains to make the Semantic Web better. One such work is presented by Ugarte (2017), who presents an idea about a futuristic Internet based on blockchains. English et al. (2016) present the potential benefits of combining Semantic technologies with a blockchain. The work of English et al. is later expanded by Cano-Benito et al. (2019). Both papers focus on using blockchain technologies in the Semantic Web definitions themselves. By doing this the Semantic Web can be improved. They also present some scenarios in which the blockchain could be improved by using Semantic Web technologies. On the other hand, our aim is not to replace parts of the Semantic Web with blockchain, but rather to use the blockchain to enable the construction of a communal ontology without relying on a centralized governing entity.

Naim and Klas (2019) present a Semantic blockchain framework, that allows storing data on a blockchain in the form of an ontology. This helps with the efficient retrieval of data from the blockchain. Their approach requires everyone connected to the blockchain network to store the entire ontology. This raises scalability concerns for use cases that require storing large ontologies.

Another solution using blockchain technologies is presented by Markovic et al. (2019). They implement a system for tracking food transport and determining if each part was compliant with the appropriate legislation. Data is stored in the Hyperledger Fabric blockchain that allows buyers to check if the transport process was appropriate.

Our application focuses on using a blockchain for tracking changes in an ontology. Tracking ontology changes is not a new concept. We present the existing tools that are related to our use case in Table 1. Some tools for tracking changes for the purposes of undo and redo functionalities are already present in the Protégé editor for ontologies (Liang et al., 2005). These tools are very limited since all changes are lost after a program restart. An improvement for change tracking in Protégé was proposed by Khattak et al. (2009). They created a plugin for the Protege editor that tracks every change that the user makes and allows a rollback to any previous version. Their solution keeps the changes stored in one place, which enables the tracking of each change from the beginning of an ontology. In their solution, all changes are only stored on a single computer and are available to only one user. We aim to use distributed storage technologies to store the changes in a decentralized and distributed way that protects us from data loss and enables collaboration between multiple users.

We propose a solution for ontology management, that uses the Ethereum blockchain combined with IPFS to track changes. This concept is somewhat similar to the work done by Nizamuddin et al. (2019). They used Ethereum and IPFS to keep track of changes when editing documents. Their application works in a similar way to version control software. They also implemented the limitation that a change is only applied if it is approved by at least two-thirds of the approvers. The main difference between our system and the one proposed by Nizamuddin et al. is that their system is designed to work with general documents without understanding their structure, while ours is designed as a transaction manager for an ontology database. Our system uses the Apache Jena framework to parse and execute the queries written by a user. Thus it can perform a variety of checks for the correctness of a change, like checking its syntax, checking the ontology consistency after the execution of a query etc. Jianjun et al. (2020) also combined IPFS with Ethereum to create a system for sharing documents that can only be viewed by authorized users. This is achieved by using an Ethereum smart contract for checking the identities of the users. An approach similar to Jianjun et al. was also proposed by Steichen et al. (2018). They use Ethereum and IPFS for access control. This way they solve the problem of only allowing some users to access documents stored on the IPFS network.

A large majority of the existing solutions for integrating semantic web with blockchain technologies use the Ethereum blockchain. The main reason for that is that they rely on the use of Ethereum smart contracts. The Ethereum smart contracts can also be used on any other network compatible with the Ethereum virtual machines. Because of that, there are several alternatives to using Ethereum. We found that the most perspective alternatives are the BNB chain (Binance team, 2022) and the Fantom platform (Choi et al., 2018). An advantage of using Ethereum is that it has the most users making it very secure, while the alternatives offer cheaper prices for executing smart contract functions.

We decided to use the Ethereum blockchain for storing the content identifiers of each change to the ontology. The reason for using the Ethereum network is that the Ethereum smart contracts are also supported by various different blockchain systems. We demonstrate our system on the Ethereum network which is the most well-known and offers high security due to a large number of miners. One of the drawbacks of using Ethereum for production systems is the high cost of smart contract transactions. To avoid that, the user could easily reconfigure our system to work with a different blockchain that also supports Ethereum smart contracts.

The idea behind consistency checking is that we can apply some rules to the relations in an ontology. For instance, if we have a relation stating that a person was born on a certain day, we can decide not to allow another relation stating that the same person was born on another date. In order to prevent such cases, we need a method for checking consistency based on some reasoning rules. Apache Jena supports multiple inference engines (reasoners) for deriving assertions from base RDF graph and for checking its consistency (Apache Jena, 2021). The mechanisms differ in their capabilities and complexities:

We only publish the changes to the blockchain if the resulting ontology is consistent. One limitation of our approach for consistency checking is that the checks are done locally before a change is applied. This means that a malicious user could bypass the checks and apply a contradictory change directly to the blockchain. This can be mitigated by checking consistency when fetching the changes and reverting transactions that cause invalid states. In order to completely resolve this issue in the future, we propose the use of a voting-like mechanism where a change has to be confirmed by some number of users in order to become a part of the ontology. This mechanism can be implemented similarly to the voting mechanism proposed by Nizamuddin et al. (2019). In this case, we would have a group of trusted users, who have the ability to approve transactions. Once a transaction has been approved by two-thirds of the trusted users, it would become part of the ontology. In our case, the process of approving a transaction would be done automatically by the reviewers’ transaction managers. In order for someone to become a trusted user, they would also need the approval of a large enough percentage of existing trusted users. This way the changes that cause an inconsistent state would not get included in the shared ontology. This mechanism is not a part of our current implementation but could be implemented in the future.

When the transaction manager gets executed, the system first checks if the local ontology is present. If there is no local ontology, it either reconstructs the ontology from the blockchain (see Section 4.4) if it is available or initializes a new ontology (see Section 4.2). Once the local ontology is present, the system checks for new changes that might have been submitted to the blockchain by other users and applies them to the local ontology (see Section 4.5). After that the queries provided by the user get executed on the local ontology and written to the blockchain (see Section 4.3).

We present the interactions between each part of the system that take place when a user submits a query to an already initialized ontology (Fig. 2). When a query is sent to our transaction manager, it first checks for new changes using the Ethereum smart contract. If any new changes have been committed since the last synchronization, it loads their identifiers. The identifiers allow the transaction manager to locate the details about each change on the IPFS network. The transaction manager then uses the identifiers to retrieve the SPARQL queries that have been executed during each of the changes and runs them on the local ontology database. After that, the state of the local ontology is synchronized with the shared state.

Once the local ontology is in a synchronized state, the user’s query gets executed and the transaction manager checks the ontology for consistency with all of the reasoning rules. If the ontology is consistent, the query gets written to the IPFS network. After that, the transaction manager writes the IPFS content identifier of the query to the Ethereum blockchain using the smart contract. By storing the queries on the IPFS network and only storing their content identifiers on the blockchain we avoid the problems and cost of storing large amounts of data on the blockchain. This is important since some queries for adding ontology records can be very large.

The first use case that we describe is responsible for the initial loading of an existing ontology into our system. In this case, we start with a pre-existing ontology stored locally as a set of files containing the ontology triplets. The local ontology of the system is not yet set up and the ontology is not yet stored on the distributed storage. During the process, the ontology gets loaded into our local database and stored on the IPFS and blockchain. This process is important since it allows us to use our system on an already existing ontology. Our system also supports initialization from an empty ontology or an ontology stored on the IPFS and blockchain. The latter is presented in more detail in Section 4.4. The process of initialization using a local ontology has the following steps (presented in Fig. 3):

After the initialization, we can track the changes of the ontology. We can also make some guarantees about the integrity of the tracked data. Ontology data at the content identifier has not been altered. This could not be guaranteed if we were using location addresses. Journal of ontology changes is kept, which proves the time and author of any change. The authors of each change to the ontology are identified under the Ethereum pseudo-anonymous address.

The second scenario is querying the data in the ontology (presented in Fig. 4). Queries are created in SPARQL language which allows both reading and updating the ontology. If the query only performs a read operation, the system only returns the local data. This way there is no need for the usage of the Ethereum or the IPFS which might slow down the performance. In the event that the query changes, creates, or deletes entries in the ontology, all of the changes are also checked for consistency and written to the Ethereum blockchain. Writing to the blockchain is done in two parts. First, the query is stored on the IPFS and the system generates an IPFS content identifier. Next, the identifier is stored in the smart contract on the Ethereum network. Running a query follows these steps:

After the ontology data is updated, other users can download the changes from the blockchain and apply them to their local ontologies. This way each change can be shared between everyone that is working on the ontology. The collaboration scenario is explained in more detail in Section 4.5.

The use of the blockchain enables full recovery of the ontology. This means that if any of the data in the local ontology is lost, it can be restored from the blockchain. The same process can be used when a new user wants to get the shared ontology. The recovery process is presented in Fig. 5. The recovery process works in a similar way to the initialization of the ontology except that the ontology is loaded from the Ethereum network instead of the local file system. Loading the ontology is done in two parts. First, all of the identifiers for the initial data and every recorded change are loaded from the smart contract on the Ethereum network. Next, the actual initialization data and queries are downloaded from the IPFS network using the retrieved identifiers. The steps for the ontology recovery are the following:

A similar process can be also used for updating an existing local ontology to the latest version. Our implementation stores the queries that have been already executed, so it can automatically skip the changes from the Ethereum that have been applied already.

As mentioned in the previous scenario, we can use the data stored on the blockchain in order to enable collaboration between multiple people when working with the ontology. Once the ontology exists on the blockchain, new contributors can use the recovery process described in Section 4.4, to recreate the entire ontology locally. After that, they can apply their own changes to the ontology. The changes get automatically stored on the blockchain, so the other users can download them and apply them to their local ontologies. The process is shown in Fig. 6. The collaboration between person A and person B would follow these steps:

The option for the collaborative building of the ontology enables the creation of a completely open ontology, where anyone could contribute their knowledge. Since this ontology can be stored on a decentralized blockchain, there is no need for centralized servers and their maintenance.

All tests were executed on a Mac computer with 16 GB of memory and an Intel 8-core processor. During our tests, the heap size of our program was set to 2 GB. We tested the performance of the most common use cases by running a scenario 10 times. The scenario consisted of three parts, performed by two different users and contained the initialization of the ontology, its restoration from the blockchain, execution of all query types, and collaboration between the user. This way we covered all of the presented use cases. We measured the time that each operation took to execute as well as the amount of gas that has been required for the Ethereum operations. We computed the price of the required gas in Euro based on the price at the evaluation time (22.12.2021). In Tables 2, 3, 4, 5, and 6 we present the average values as well as standard deviations for times and prices of each operation. For testing, we used a public Ethereum test network called Rinkeby2²

Rinkeby Website: https://www.rinkeby.io/

In our tests, we evaluated the effect of consistency checking separately from the main tests. That is because we want our main tests to reflect the effects that the use of blockchain has on the performance of the system working with large ontologies. Our tests have shown that consistency checking in Apache Jena becomes memory intensive when working with large ontologies, which prevents us from running consistency checking on our entire ontology.

For testing the transaction manager, we needed a large ontology to demonstrate common use scenarios. By using a large ontology we can demonstrate the performance of our system for larger projects. There are several such ontologies that are publicly available. We decided to use the DBpedia (Lehmann et al., 2015) since it is one of the most well-known general knowledge ontologies. We decided to only load the parts of DBPedia, necessary for running our test queries. The final size of the database was 2.8 GB. The parts that we used are: (1) the ontology structure, (2) home pages of resources, (3) numerical properties of entities, and (4) entity types. By including these parts of the ontology, our database contained all of the entities, their numeric properties, home pages, and types. The evaluation ontology, therefore, contained approximately 7 million entities of about 800 different types with around 3000 different properties. Approximately 6.5 million of the entities fall under one of the DBpedia types, while the rest have a type from another ontology. Altogether there were around 9 million triplets in our testing ontology.

During the initialization, the smart contract was first published to the Ethereum network and then all four parts of the data from DBpedia were stored in the local database. The files required for the initialization of the ontology were uploaded to the IPFS network, so they can be retrieved by anyone using their identifiers. The IPFS identifiers were then stored on the blockchain using the smart contract. We compared this with the initialization process when only using the Apache Jena library without the blockchain. The times and gas cost of each operation is presented in Table 2. In this scenario, the steps for publishing the initial ontology to the IPFS and storing the IPFS identifiers in the smart contract were performed in four steps. In the table, we present the sum of all four times and prices. The reason for the four parts is that we used four parts of the DBpedia in our testing and each part is stored in a separate file.

Most of the time was spent loading the data to the Jena TDB database. This part has to be performed even if we are only using a local ontology without the blockchain. The reason for a slow operation is that our initial ontology contains a large amount of data, which requires a substantial amount of processing before it can be used. In addition to that, we have to perform blockchain synchronization steps in our implementation which take about two minutes.

The most common operation is running a query. The steps required to run a query are described in Section 4.3. We evaluated the performance of this scenario by running three queries. The first query only retrieved values and did not change the data, so the smart contract did not get updated. The second query performed the insert operation, and the third query deleted an entity in the ontology. The final two queries changed the ontology so they had to be stored on the IPFS and recorded in the smart contract. The time required to run each query is presented in Table 3. The select query (1) is performed locally and does not require a blockchain update. The insert query is first performed locally (2a), then the query is uploaded to the IPFS network (2b) and stored by an identifier. Finally, the identifier is stored on the blockchain using the smart contract (2c). The same process is used for the delete query (3a–3c).

The query for retrieving data took a similar amount of time compared to only running locally without the blockchain. This was expected since we only use the local database to retrieve the data. The two queries for inserting and deleting data both took significantly longer to complete on our implementation than on a system only using Apache Jena. This was also expected since changes to the ontology require the creation of a record on the blockchain and communication with the IPFS network. Most of the time required for these queries was used for updating the smart contract.

One of the advantages of using blockchain is that we can recover the entire ontology in the event of a data loss. To showcase that, our third test was a complete recovery of the ontology. This is done in three steps. First, the IPFS identifiers are retrieved from the blockchain. Since this is only a read operation, it can be performed quickly and does not require gas payment. After that, the data is downloaded from the IPFS network. Finally, the data is loaded to the Jena database. These three steps are repeated first for the initial data and second for the transactions that were applied on top of the initial database. Times for all parts of the operation are presented in Table 4. Just like in the initialization scenario, most of the time is spent loading the ontology to Jena. This is expected since the ontology is still the same size. This is also the reason that the entire process of restoring the ontology from the blockchain takes a similar amount of time compared to the loading of initial data in the initialization of the ontology in Section 5.3.

When recovering an ontology, we can also choose to only apply changes up to a certain point. This way we can get an ontology from a certain time instead of using the latest one. A user could also use our system to create a new branch of the ontology. Creating a branch requires the creation of a new Ethereum smart contract.

Our final test was designed to simulate collaborative editing of an ontology. We created two separate users A and B each with their own Ethereum wallet. The users then edited the ontology together. This scenario is constructed from previous scenarios. In the first step, user A initializes the ontology. The steps required for the initialization are shown in Section 5.3. User A then performs a delete query. The steps required for the delete operation are presented in Section 5.4. After that, user B reconstructs the ontology from the blockchain as is shown in Section 5.5. User B then executes an insert query adding an element to the ontology. The steps for the insert query are presented in more detail in Section 5.4. After that, user A updates their local ontology to the latest version by reading the identifier of the change performed by B from the blockchain, downloading the query from the IPFS network, and executing it on the local ontology. Finally, user A performs a select query to confirm that the change is visible. Times and prices of each operation are presented in Table 5. This scenario is also not possible if we are not using the blockchain. Because of that, we do not present the results for the basic Apache Jena implementation without our modifications.

Most of the time in this scenario is used for initialization of the ontology for both users. In real use, this is not a big issue, since the ontology only has to be initialized once. Another operation that requires a relatively long time is the execution of queries that change the ontology data. The long time is the result of limitations with Ethereum smart contracts. This can be improved by combining larger changes into one transaction. The operations that require only read operations are performed quickly.

In this test, each user had their own local Semantic database. It is also possible to share a single local Semantic database amongst multiple users. In this case, it is especially important that all changes to the content of the database are done through our transaction manager. If a user changes the database directly, the change does not get recorded on the blockchain so we get an inconsistency between the local ontology and the one stored on the blockchain. This inconsistency can be later resolved by restoring the ontology from the blockchain. In our implementation, we recommend the use of Apache Jena TDB as the database for storing the ontology. However, the proposed transaction management system could also work with any other Semantic database.

Each change of the ontology gets executed as a transaction, where all changes get reverted in case of an error at any point. In the proposed implementation the changes are synchronized with the blockchain before each set of queries that the user requests. The synchronization is done by checking for new changes on the blockchain. After that, the new queries are loaded from the IPFS network and applied to the local database. Another option for the implementation would be to synchronize the local ontology with the one stored on the blockchain in real-time as the changes get made. In both cases, we get the latest version of the ontology before the new change gets applied. This is important since we could get an inconsistent state of the ontology if the local database would not contain the same information that is stored on the blockchain. Lastly, the transaction gets committed and new changes get recorded on the blockchain.

We performed an additional scenario to test the effects that consistency checking has on the performance of the system. In this test, we only loaded three out of four parts of our ontology, because consistency checking over the entire ontology was too memory intensive. For consistency checking, we used transitive rules. In this scenario, the user first loads the initial ontology and checks for consistency. The initial ontology is then uploaded to IPFS and the Ethereum network. After that, the user performs a SELECT and a DELETE query. These queries were selected to demonstrate the effect of consistency checking on a query that only reads the data and on a query that also changes the data. After the DELETE query, consistency is checked again. After that the update is also uploaded to the IPFS and to the Ethereum network. The time and payment required for each step of the process are presented in Table 6.

Checking the ontology consistency requires less time than the initialization of the ontology. On the other hand, we have observed that the memory required to perform a consistency check becomes an issue with large ontologies. The consistency check also has to be performed after each query that changes the data. We believe that the benefits of using consistency checking outweigh the performance cost when editing smaller ontologies. When working with larger ontologies, for example, the entire DBpedia, the consistency checking is too demanding for practical use. This is not a limitation of our transaction manager, but rather of the Apache Jena framework.