Towards a semantic blockchain: A behaviouristic approach to modelling Ethereum

Abstract

Decentralised ledgers are gaining momentum following the interest of industries and people in smart contracts. Major attention is paid to blockchain applications intended for trading assets that exploit digital cryptographic certificates called tokens. Particularly relevant tokens are the non-fungible tokens (NFTs), namely, unique and non-replicable tokens used to represent the cryptographic counterpart of assets ranging from pieces of art through to licenses and certifications. A relevant consequence of the hard-coded nature of blockchains is the hardness of probing, in particular when advanced searchers involving the capabilities of the smart contracts or the assets digitised by NFTs are required. For this purpose, a formal representation for the operational semantics of smart contracts and of tokens has become particularly urgent, especially in economy and finance, where blockchains become increasingly relevant. Hence, we feel the need to tailor Semantic Web technologies to achieve that semantic representation at least for NFTS.

This article reports on an ontology that leverages the Ontology for Agents, Systems, and Integration of Services (“OASIS”) towards the semantic representation of smart contracts responsible for managing ERC721-compliant NFTs and running on the Ethereum blockchain. Called Ether-OASIS, the proposed ontology adopts OASIS and tailors its behaviouristic approach to the Ethereum blockchain by conceiving smart contracts as agents running on the blockchain and, consequently, smart contract interactions as agent commitments. Smart contracts are represented in terms of their actions, purposes and tokens that they manage, thus realising a blockchain that is more usable both by users and automated applications. The ontology is evaluated using standard ontological metrics and applied on a case study concerning the minting and transferring of NFTs that digitise batches of wheat.

Keywords

Ontology Semantic Web Agent Blockchain Ethereum OWL

1. Introduction

The last decade report huge interest from various realms such as economic, social, business, and academic ones in blockchain technology and related applications (Xu et al., 2017). The interest in blockchain technologies is mainly motivated by the fact that they implement decentralised and publicly shared ledgers, where third-party intermediaries demanding the client’s total and unquestioned trust are not required. One of the most popular applications of blockchains such as Ethereum (Szabo, 1997) is the smart contract. Smart contracts are executable specifications of agreements in blockchain transactions that implement decentralised and autonomously running programs called dApps.

Applications of blockchain technologies are innumerable, ranging from the Internet of Things (IoT) and robotics (Christidis and Devetsikiotis, 2016), to commerce, healthcare, insurance, energy, laws, and communications. In particular, in the commerce and financial realms, some types of blockchains are used to deliver cryptographic versions of the digital twins of assets within a public decentralised environment. Properties of digital twins are commonly represented by means of non-fungible tokens (NFTs). An NFT is a digital certificate stored on the blockchain representing predetermined rights on certain unique assets. Therefore, NFTs are mainly used as digital proofs of assets’ ownership, even though they do not provide inherent legal meaning, do not grant copyright, intellectual or any other legal rights over them, and unauthorized copies cannot be avoided. NFTs are routinely exchanged mainly to transfer the ownership of assets whose uniqueness is hard to demonstrate (for example, digital data such as images and sounds), mainly for monetary profit.1

¹
The NFT market is projected to reach 2,378.0 millions of dollars in 2024 (Statista, 2024).

This article targets the well-known problem of the user-friendliness and usability of blockchain-based trading. A paradigmatic use case sees a beginner approach such a technology and come across a number of identifiers (notably, the hashes of previous transactions and the token identifiers) that were transferred with each transaction. Not only are such identifiers as cryptic as hexadecimal representations, but it remains unclear what goods correspond to each token and what tokens are for sale. The only plausible means to retrieve such information at present are a) the inspection of the source code of the smart contract that handles specific tokens, b) the fetching of some metadata that may be available about each token, for example off-chain by means of an HTTP link to a dedicated page (maintained either by the token owner or by intermediaries), and c) the appeal to off-chain services that operate as intermediaries promoting specific types of tokens. While code inspection is clearly not for the layman, metadata is not always available. Part of this problem is how to structure such a metadata to enable automated processing, and searching in particular. Additionally, it is currently hard for newcomers to search through a blockchain, for example, to find smart contracts trading the specific tokens that satisfy the user requirements on quality or quantity. Moreover, users perceive tokens and related smart-contracts as a black-box and remain vastly unaware of (the details of the essential processes of) deploying, transferring, and destroying tokens – thereby also increasing the likelihood of scam attempts (Tom’s Hardware, 2022).

Arguably, all facets of the problem outlined above could be addressed by developing ontologies about the logic of the full, blockchain-based trading, coherently with the Semantic Blockchain paradigm (Aswini and Padmapriya, 2021). Therefore, this article aims at a formal, semantic representation capturing not only metadata but the entire trading process, namely blockchain smart contracts and all related activities, so as to facilitate the understanding of blockchain concepts, the interlinking with off-chain information, and also formal reasoning. Moreover, a semantic conception of blockchains could support the automatic discovery of smart contracts, the interconnection of services running on different blockchains (i.e., cross-chain integration) and the integration between smart contract and off-chain services. These features turn out to be yet more relevant when smart contracts are implemented as mechanisms for generating and exchanging tokens: one of the most desirable features of token exchange systems is a precise and intelligent query mechanism capable of determining what, when, and how certain assets were generated, exchanged or destroyed. Token marketplaces may be aware of the activation of smart contracts for generating tokens with specific features, of the type of exchanged asset or of their exchange conditions, or more in general of all the related activities over the blockchain. Final users would also benefit from a clear representation of the blockchain, since they gain means to understand the underlying mechanics and the decisions taken in trading tokens.

Hence, this article contributes to the realization of the Semantic Blockchain by interpreting smart contracts as reactive agents operating on a common environment, with a fully specified semantics of available operations, committed actions, and stored data. The representation of blockchain actors requires ontological capabilities for fully representing agents and their interactions in a detailed way.

The behaviouristic approach, inspired to the Tropos methodology (Bresciani et al., 2004), focuses on the agents’ mental components, notably on goals and tasks to achieve a result. Tasks are, in turn, oriented at changing the environment through some actions, namely, the direct consequences of bringing the behaviours into effect. Therefore, this comes as a natural approach at formalising the operational capabilities of agents. The Ontology for Agents, Systems, and Integration of Services (“OASIS”) (Cantone et al. (2019); Bella et al. (2022); Bella et al. (2023a-b)), applies the behaviouristic approach to deliver an ontological representation system and a communication protocol for agents and their commitments by leveraging the Semantic Web capabilities, thus to semantically describe agents in terms of the actions they are able to perform and the way they interact with the environment through the appropriate mental states.

In this work, OASIS is leveraged towards the full, semantic representation of the Ethereum blockchain and the smart contracts running on it, with a focus on the smart contracts compliant with the ERC721 standard for NFTs management (Ethereum, 2021). The resulting ontology is called Ethereum Through OASIS (in short, Ether-OASIS). Ether-OASIS leverages the behaviouristic approach of agent representation to semantically describe Ethereum smart contracts through their capabilities of modifying the distributed ledger and managing tokens with specific features. The behaviour of ERC-721 compliant smart contracts is defined together with a suitable classification of tokens, thus providing the necessary means to semantically describe smart contracts. A comparison with the BLONDiE ontology is mandatory. While BLONDiE focuses on the representation of the structural elements of Ethereum, such as contracts and address and transactions, Ether-OASIS aims at characterizing the full operational semantics of smart contracts and tokens. The new ontology is developed here through an epistemological process that is supported by the definition of suitable competency questions implemented as SPARQL queries. Therefore, the contribution of Ether-OASIS to the Semantic Blockchain becomes clear. This article also presents the results of the ontology evaluation to ensure both domain coverage and suitability. The choice fell on the OntoQA approach (Tartir et al., 2005), a standard feature-based method for evaluating ontologies by applying techniques that do not require data training and effort from the valuer. Finally, a case study concerning minting and transferring of NTFs representing batches of wheat is introduced to show the potential of the epistemological approach adopted by Ether-OASIS.

The present manuscript extends a previous conference paper (Bella et al., 2022) by fully describing the Ethereum blockchain together with the ERC-721 compliant smart contracts and related non-fungible tokens, including how minting and transferring operations are semantically represented. Part of this work is integrated within ONTOCHAIN (NGI-ONTOCHAIN, 2020; Bella et al., 2021), a family of solutions to deliver a secure and transparent blockchain-based knowledge management system. This is meant as an interoperability service for the Internet in several domains such as health, economy, mobility, public services, energy and sustainability, news, media, entertainment, Industry 4.0, and tourism.

The paper is organised as follows. Section 2 presents related works. Section 3 outlines OASIS, while Sections 4 and 4.2 describe how Ether-OASIS models the Ethereum blockchain and the main Ethereum ERC721 standard functions, respectively. Section 5 introduces a case study on managing NFTs of wheat, showing how their minting and transferring is semantically represented. An analysis of Ether-OASIS is introduced in Section 6 together with a comparison with the state of the art. Finally, Section 7 draws some conclusions and delineates future research directions.

2. Related work

Combining Semantic Web technologies and blockchains is the goal of recent research (English et al., 2016; Cano-Benito et al., 2019). One of the most investigated aspects is the specification of blockchain concepts and technologies by means of ontologies to provide semantic reasoning capabilities. An ontological albeit theoretical approach at blockchain representation already exists (de Kruijff and Weigand, 2017). The authors of (Ruta et al., 2018) propose a blockchain framework for Semantic Web of Things (SWoT) contexts settled as a Service-Oriented Architecture (SOA), where nodes can exploit smart contracts for registering, discovering, and selecting annotated services and resources. Blockchain technologies are also exploited as a secure and public storage system for small data, including linked data, and to realise a more resilient architecture for the Semantic Web (English et al., 2016).

Other works aim at representing ontologies within a blockchain context. In (Kim and Laskowski, 2018), ontologies are used as common data format for blockchain-based applications such as the proposed provenance traceability ontology, but are limited to implementation aspects of the blockchain. The author of (Fill, 2019) discusses the application of blockchains for tracking the provenance of knowledge, establishing delegation schemes, and ensuring the existence of patterns in formal conceptualizations. This is achieved using the zero-knowledge proof of knowledge method, which consists in proving a given statement without revealing how it was proved or any additional knowledge.

Semantic interpretations of smart contracts as services such as the Ethon ontology (Pfeffer et al., 2016; Baqa et al., 2019) or analogous approaches (Cano-Benito et al., 2021) exist: their main limitation is the poor semantic description of the represented smart contracts, which hinders the discovery of unknown smart contracts and of the related operations fulfilled during their life-span. This is due to the fact that these ontologies limit the representation of smart contracts to the one of services, or only to hard-coded functions. Moreover, the semantics of smart contract interactions is extremely limited and no specification about the type of operation and of the entities involved in the commitment is provided.

The Blockchain Ontology with Dynamic Extensibility (BLONDiE) project (Ugarte Rojas, 2017) provides a comprehensive vocabulary that covers the structure of various components (wallets, transactions, blocks, accounts, etc.) of blockchain platforms (both Bitcoin and Ethereum), which could be easily extended to other ledgers. However, BLONDiE does not cover the type of operations carried on by smart-contracts, how and what type of tokens and related assets they manage. This is the fundamental limitation of BLONDiE that this article overcomes.

Worthy to be mentioned, Ethereum recently introduced the TokenURI2

²
https://docs.openzeppelin.com/contracts/2.x/erc721

option that allows users to include metadata in the JSON format. Ethereum metadata permit to access information that cannot be stored within the smart contract in the form of Ethereum states, for example, long text descriptions or token features that do not activate any smart contract behaviour. Metadata are also a way to reduce the size of the smart contract states, thereby enhancing performance and reducing transaction costs. Moreover, the Ethereum compiler automatically generates the metadata containing information about the compiled contract, which could be used to query the compiler version, the sources used, and the contract documentation in order, ultimately facilitating the interaction with the contract and the verification of the related source code. However, Ethereum metadata currently have no aim at enabling a semantic Ethereum. In fact, such metadata does not describe the operational semantics of smart contracts, hence, cannot contribute to the capabilities of oracles to search for those dApps that match particular criteria.

Finally, we summarise the works that led to Ether-OASIS. In (Cantone et al., 2022) the authors illustrated how the OASIS ontology is applied for semantically describing digital contracts implemented through ontologies (called ontological smart contracts), intended as agreement among agents, and how they can be secured on Ethereum. Moreover, in (Cantone et al., 2022) the definition of semantic agreements reached among agents and secured on the Ethereum blockchain is provided, while smart contracts intended as programs running on the blockchain and interpreted as digital agents in the OASIS fashion are introduced in (Bella et al., 2022).

3. The OASIS ontology

In this section we present the Ontology for Agents, Systems and Integration of Services (in short, OASIS),3

³
The OASIS ontology is reachable in (Cantone et al., 2021a).

which is leveraged by Ether-OASIS to describe smart contracts and their commitments in the behaviouristic fashion. OASIS is a foundational OWL 2 ontology that leverages the behaviouristic approach inspired from the Theory of Agents (Wooldridge and Jennings, 1995) and its mentalistic notions to represent multi-agent systems. The behaviouristic approach, inspired by (Bresciani et al., 2004), is an effective way of semantically describing agents by defining the capabilities of each agent. Agents are enabled to publicly report the set of activities they are able to perform, the types of data required to execute those activities, as well as the expected output. Agents’ implementation details are abstracted away so as to make the discovery of agents transparent, automatic, and independent from the underlying physical infrastructure. In consequence, agent commitments are also clearly described as well as the entire evolution of the environment, which is unambiguously represented, searchable, and accessible. As a consequence, agents may join a collaborative environment in a plug-and-play fashion, as there is no need for third-party intervention. The behaviouristic approach is exploited by OASIS to characterise agents in terms of the actions they are able to perform, including purposes, goals, responsibilities, information about the world they observe and maintain, and their internal and external interactions. Moreover, OASIS models the executions and assignments of tasks, restrictions on them, and constraints used to establish responsibilities and authorizations among agents. Agents are represented through their behaviours, which are publicly exposed, in such a way as to report the set and type of operations that they are able to perform, including the type of data required to execute them together with the expected output.

In OASIS, representation of agents and their interactions is carried out along three main steps:

modelling general abstract behaviours (called templates), from which concrete agent behaviours are drawn;

modelling concrete agent behaviours drawn by agent templates;

modelling actions performed by agents by associating them with the behaviours from which actions are drawn.

The first step is not mandatory and consists in defining the agent’s behaviour template, namely a high-level description of behaviours of abstract agents that can be implemented to define more specific and concrete behaviours of real agents. For example, a template may be designed to describe specific commercial actors such as sellers and publishers. Moreover, templates are useful to guide developers to define the most suitable behaviours for their own agents. To describe abstract agent’s capabilities to perform actions, an agent template comprises three main elements, namely behaviours, goals and tasks. Behaviours represent the mental state of the agent associated with its capability of activating, modifying the environment or doing something; goals are conceived as mental attitudes representing preferred progressions of a particular system that the agent has chosen to put effort into bringing about (van Riemsdijk et al., 2008), while tasks depict how such progressions are carried on. Agent tasks, in their turn, describe atomic operations that agents may perform including, possibly, input and output parameters required to accomplish the actions. Indeed, the core of OASIS agent representation revolves around the description of atomic operations introduced by the definition of tasks, i.e., the most simple (atomic) operations that agents are able to put in practice.

The second step consists in representing the concrete agent behaviours either by specifying a shared template or by defining it from scratch: in both cases, concrete behaviors have the same shape of templates, where ideal features are replaced with actual characteristics. Behaviours drawn by shared templates are clearly associated with them in order to depict the behaviour inheritance relationship.

Finally, in the third step, actions performed by agents are described as direct consequences of some behaviours and associated with the behaviours of the agent that generates them. To describe such an association, OASIS introduces plan executions. Plan executions describe the actions performed by an agent and associated with one of its behaviours. The association is carried on by relating the description of the performed action with the behaviour from which the action has been drawn: actions are hence described by suitable graphs that retrace the model of the agent’s behaviour.

We now illustrate how those three steps are implemented in OASIS.

Agent templates in OASIS are defined according to the UML diagram depicted in Fig. 1. To describe how abstract agents perform actions, an agent template comprises three main elements, namely behaviour, goal, and task. Agent tasks, in their turn, describe atomic operations that agents may perform, including possibly the required input and output parameters. Hence, the core of agent representation is focused on the description of atomic operations, represented by instances of the class TaskDescription that characterises agent commitments. In their turn, instances of the class TaskDescription are related with the following five elements that identify the operation:

an instance of the class TaskOperator, characterizing the action to be performed. Instances of TaskOperator are connected either by means of the object-property refersExactlyTo or refersAsNewTo to instances of the class Action. The latter class describes physical actions that are introduced by means of entity names in the form of infinite verbs representing the actions (e.g., produce, sell, …). The object-property refersExactlyTo is used to connect the task operator with a precise action having a specific IRI, whereas refersAsNewTo is used to connect a task operator with an action for which a general abstract description is provided. In the latter case, the action is also defined as instance of the class ReferenceTemplate: instances of the class ReferenceTemplate are used to introduce entities that represent templates for the referred element describing the characteristics that it should satisfy. By exploiting the object-property refersAsNewTo, the entity provides only a general description of the features needed to accomplish the task, for example, that it must be of a specific type; on the contrary, the object-property refersExactlyTo specifies the actual and exact entity that is involved in the task.

Possibly, an instance of the class TaskOperatorArgument, connected by means of the object-property hasTaskOperatorArgument and representing additional specifications for the task operator action (e.g., on, off, left, right, …). Instances of TaskOperatorArgument are referred to the operator argument by specifying either the object-property refersAsNewTo or refersExactlyTo.

An instance of the class TaskObjectTemplate, connected by means of the object-property hasTaskObjectTemplate and representing the template of the object recipient of the action performed by the agent (e.g., apple, …). Instances of TaskObjectTemplate are referred to the action recipient by specifying either the object-property refersAsNewTo or refersExactlyTo.

Input parameters and output parameters, introduced in OASIS by instances of the classes TaskInputParameterTemplate and TaskOutputParameterTemplate, respectively. Instances of TaskDescription are related with instances of the classes TaskInputParameterTemplate and TaskOutputParameterTemplate by means of the object-properties hasTaskInputParameterTemplate and hasTaskOutputParameterTemplate, respectively. Instances of TaskInputParameterTemplate and of TaskOutputParameterTemplate are referred to the parameter by specifying either the object-property refersAsNewTo or refersExactlyTo. Moreover, the classes TaskInputParameterTemplate and TaskOutputParameterTemplate are also subclasses of the class TaskParameterTemplate.

Fig. 1.

UML diagram of agent templates in OASIS.

Summarizing, the main classes characterizing an agent template in OASIS are the following ones:

AgentBehaviorTemplate. This class comprises all the individuals representing templates of agents. Instances of such a class are connected with one or more instances of the class Behavior by means of the OWL object-property hasBehavior.

Behavior. Behaviours of agent templates represent containers embedding all the goals that the agent can achieve. Instances of Behavior are connected with one or more instances of the class GoalDescription by means of the object-property consistsOfGoalDescription.

GoalDescription. Goals represent containers embedding all the tasks that the agent can achieve. Instances of GoalDescription comprised by a behaviour may also satisfy dependency relationships introduced by the object-property dependsOn. Goals are connected with the tasks that form them and are represented by instances of the class TaskDescription through the object-property consistsOfTaskDescription.

TaskDescription. This class describes atomic operations that agents are able to perform. Atomic operations are the most simple actions that agents are able to execute and, hence, they represent what agents can do within the environment. Atomic operations may depend on other atomic operations when the object-property dependsOn is specified. Atomic operations whose dependencies are not explicitly expressed are intended as to be performed in any order. Finally, tasks are linked to the individuals that describe the features of the atomic operations, i.e., the instances of the classes TaskOperator, TaskOperatorArgument, TaskObjectTemplate TaskInputParameterTemplate, and TaskOutputParameterTemplate, as described above.

TaskOperator. This class characterises the type of operation to perform. Instances of TaskOperator are connected with instances of the class Action by means of either the object-properties refersExactlyTo or refersAsNewTo. Tasks are connected with task operators by means of the object-property hasTaskOperator.

Action. This class describes actions that can be performed by agents. Entity names of the class Action’s instances are introduced as infinite verbs such as buy, sell, compute, and so on, drawn from a common, shared and extendable vocabulary defined by the OASIS-Abox ontology (Cantone et al., 2021b).

TaskOperatorArgument. This class defines operator arguments representing subordinate characteristics of task operators. Tasks are connected with operator arguments by means of the object-property hasTaskOperatorArgument.

TaskObjectTemplate. Instances of this class represent the recipient of the behaviours of agent templates. Tasks are connected with object templates by means of the object-property hasTaskObjectTemplate.

TaskInputParameterTemplate. This class represents the input parameters required to accomplish the referred operation, as for instance the wallet to which a token is transferred. Tasks are possibly connected with the input parameters by means of the object-property hasTaskInputParameterTemplate.

TaskOutputParameterTemplate. This class represents the output parameters obtained as a result of the referred operation. Tasks are possibly connected with the output parameters by means of the object-property hasTaskOutputParameterTemplate.

Concrete behaviours of agents are represented in similar way as to behaviour templates (see Appendix A, Fig. 14), which reflects the modelling pattern adopted for the representation of agent behaviour templates described above. The main difference between concrete behaviours and behaviours template can be summarised as follows:

The instance of the class AgentBehaviorTemplate gives way to an instance of the class Agent, representing a concrete agent in the knowledge domain.

The instance of the class TaskObjectTemplate gives way to an instance of the class TaskObject, representing a real recipient of the concrete agent action.

The instance of the class TaskInputParameterTemplate gives way to an instance of the class TaskFormalInputParameter, representing the formal input parameter of the concrete agent action.

The instance of the class TaskOutputParameterTemplate gives way to an instance of the class TaskFormalOutputParameter, representing the formal output parameter of the concrete agent action.

Concrete agents are possibly connected with the agent template that they are drawn from. In order to describe the fact that concrete agents inherit their behaviours from a common and shared agent template, the object-property overloads associates a) the instance of the class TaskDescription of the concrete agent with the instance of the class TaskDescription of the agent template, b) the instance of the class TaskObject of the concrete agent with the instance of the class TaskObjectTemplate of the agent template, c) the instance of the class TaskFormalInputParameter of the concrete agent with the instance of the class TaskInputParameterTemplate of the agent template, d) the instance of the class TaskFormalOutputParameter of the concrete agent with the instance of the class TaskOutputParameterTemplate of the agent template.

Agent actions that are executed autonomously are associated to the description of the concrete behaviour of the agent from which they are drawn: an agent action is primarily introduced by an instance of the class PlanExecution, representing the agent commitment (see Appendix A, Fig. 15). In their turn, plan executions comprise goal executions, represented by instances of the class GoalExecution, whereas goal executions provide task executions (instances of the class TaskExecution) embedding at least the following three elements:

TaskObject. As in the case of agent behaviours, this class comprises elements used as recipients of performed actions.

TaskOperator. As in the case of agent behaviours, this class comprises the operations performed by the agent.

TaskOperatorArgument. As in the case of agent behaviours, this class comprises a specification of the operations performed by the agent. Operator arguments are introduced in agent actions only if the corresponding behaviour that generates the actions also provides operation arguments.

Unlike the tasks of agent behaviours, task executions comprise instances of the following classes, which take the place of the instances of the classes TaskFormalInputParameter and TaskFormalOutputParameter:

TaskActualInputParameter. This class represents the actual input parameters exploited to accomplish the agent action. Task executions are possibly connected with the actual input parameters by means of the object-property hasTaskActualInputParameter.

TaskActualOutputParameter. This class represents the actual output parameters obtained as result of an agent’s action. Task executions are possibly connected with the output parameters by means of the object-property hasTaskActualOutputParameter.

Agent actions are related with the behaviour from which they are drawn by. These relationships are introduced by a) connecting the instance of PlanExecution of the agent action to the instance of the class Behavior of the agent behaviour by means of the object-property planExecutionDrawnBy; b) connecting the instance of GoalExecution of the agent action to the instance of the class GoalDescription of the agent behaviour by means of the object-property goalExecutionDrawnBy; c) connecting the instance of TaskExecution of the agent action to the instance of the class TaskDescription of the agent behaviour by means of the object-property taskExecutionDrawnBy; d) connecting the instance of TaskObject of the agent action to the instance of the class TaskObject of the agent behaviour by means of the object-property taskObjectDrawnBy; e) connecting each instance of TaskActualInputParameter of the agent action to the related instance of the class TaskDescription of the agent behaviour by means of the object-property taskActualInputParameterDrawnBy; f) connecting each instance of TaskActualOutputParameter of the agent action to the related instance of the class TaskDescription of the agent behaviour by means of the object-property taskActualOutputParameterDrawnBy; g) connecting the instance of TaskOperator of the agent action to the related instance of the class TaskOperator of the agent behaviour by means of the object-property taskOperatorDrawnBy;

We now recall OASIS conditionals. Generally speaking, conditionals are used in OASIS outside the context of digital contracts to put constraints on the execution of actions and to ensure that some conditions are verified before executing a task. Conditionals are OWL sentences that have the fashion of Semantic Web Rule Language (SWRL) rules (World Wide Web Consortium, 2004) that describe operations triggered by agents when certain conditions hold. Indeed, unlike SWRL rules, which check the consistency of the knowledge base and infer new sentences, the provided representation of conditionals allows OASIS-based applications and systems to combine constraints with behaviours, thus extending the expressiveness and providing a higher-level description and representation of agents. Moreover, the introduction of conditionals in OASIS is also justified by the fact that satisfiability of conditionals does not coincides with satisfiability of the knowledge base: violations of conditionals may result in a litigation among agents or may lead agents to actuate alternative plans, without affecting the satisfiability of the knowledge base. In the context of smart contracts, conditionals are used to characterise contract terms, which are clearly expressed provisions that give rise to an obligation and whose breach can lead to a litigation.

Figure 2 depicts the schema of OASIS conditionals. Conditionals are constituted by a consequent (head) and an antecedent (body), both comprising a conjunctive set of atoms. In their turn, atoms comprise the subject of the conditional, the object, the operator describing the action and, possibly, an operator parameter and argument.

Conditional atoms are introduced by means of the following classes:

ConditionalAtom: represents a conditional atom;

ConditionalHeadAtom: represents atoms of conditional consequents and is defined as a subclass of the class ConditionalAtom;

ConditionalBodyAtom: represents atoms of conditional antecedents and is defined as a subclass of the class ConditionalAtom;

ConditionalSubject: represents subjects of atoms of conditional consequents or of conditional antecedents;

ConditionalObject: represents objects of atoms of conditional consequents or of conditional antecedents;

ConditionalOperator: represents actions of atoms of conditional consequents or of conditional antecedents;

ConditionalParameter: represents parameters of actions considered by conditional consequents or conditional antecedents (the class ConditionalParameter includes the classes ConditionalInputParameter and ConditionalOutputParameter, representing the input and output parameter, respectively);

ConditionalOperatorArgument: defines operator arguments that represent a subordinate characteristic of the conditional operator (for example, “quality check” may be represented by the operator check with argument quality);

ConditionalEntryTemplate: represents templates of the features that the entities involved in the conditional, which are introduced by means of the object-property refersAsNewTo, must satisfy.

Conditionals are introduced in OASIS by means of the following classes:

Conditional: defines conditionals, comprising a consequent (head) and an antecedent (body), both consisting in a conjunctive set of atoms;

ConditionalHead: represents consequents (heads) of conditionals. Conditionals comprise at least by one instance of ConditionalHead;

ConditionalBody: represents antecedents (bodies) of conditionals. Conditionals comprise zero or more instances of ConditionalBody, while instances of ConditionalBody are constituted by one or more instances of ConditionalBodyAtom;

ConditionalSet: represents conjunctive sets of conditionals.

Fig. 2.

UML diagram of conditionals in OASIS.

Conditional atoms are related with a subject (instance of the class ConditionalSubject), an object (instance of the class ConditionalObject), and an operator (instance of the class ConditionalOperator) by means of the object-properties hasConditionalSubject, hasConditionalObject, and hasConditionalOperator, respectively. Moreover, conditional atoms are possibly related with parameters (instances of the class ConditionalParamenter) and with operator arguments (instances of the class ConditionalOperatorArgument) by means of the object-properties hasConditionalParameter and hasConditionalOperatorArgument, respectively. Specifically, input and output parameters are introduced through the object-properties hasConditionalInputParameter and hasConditionalOutputParameter, respectively.

In OASIS there are two ways to connect conditional entries (i.e., instances of ConditionalSubject, ConditionalObject, ConditionalOperator, ConditionalParamenter, and ConditionalOperatorArgument) to the related entities, namely by exploiting the object-property refersExactlyTo and by exploiting the object-property refersAsNewTo.

The first way consists in directly indicating the individual involved in the conditional by means of the object-property refersExactlyTo, e.g., the address of a digital wallet of a specific person. In the second approach, the entry is unknown but there is a set of desirable features that the entry must own in order to make the conditional satisfied when it is checked. For example, if a digital asset is sold to anyone who sends the correct amount of money to the designated wallet, the seller (i.e., the conditional entry) will not be known until the transaction is completed: completing the transaction is the necessary requirement for a specific entity to be identified as the “buyer” of the transaction. In such situations, the object-property refersAsNewTo is used to indicate an instance of the class ConditionalEntryTemplate, which endows the set of features that must be satisfied by the conditional entry.

Instances of the classes ConditionalHead and ConditionalBody are related to instances of the classes ConditionalHeadAtom and ConditionalBodyAtom, representing conditional atoms through the object-properties hasConditionalHeadAtom and hasConditionalBodyAtom, respectively. The object-properties hasConditionalHeadAtom and hasConditionalBodyAtom are defined as subproperties of the object-property hasConditionalAtom.

Finally, conditionals are introduced in OASIS by way of instances of the class ConditionalSet. Such instances are linked through the object-property hasConditional to instances of the class Conditional, which in their turn are linked to instances of the classes ConditionalHead (representing the consequent) and ConditionalBody (representing the antecedent) by means of the object-properties hasConditionalHead and hasConditionalBody, respectively.

4. The Ether-OASIS ontology

In this section, we describe how the Ethereum blockchain is modelled in Ether-OASIS.4

⁴
The ontology is reachable at (Bella et al., 2021).

An overview of Ether-OASIS and its utilization is given in Fig. 3.

Fig. 3.

Overview of Ether-OASIS and its application.

With respect to similar ontologies such as Ethon (Pfeffer et al., 2016) and BLONDiE (Ugarte Rojas, 2017), Ether-OASIS provides a different representation of blockchains that is aligned with the behaviouristic approach pursued by OASIS so as to deliver a tool for formally describing the operational semantics of blockchain transactions. Specifically, Ether-OASIS defines an OASIS-fashioned behaviour template for representing the smart contracts, in particular the ones compliant with the ERC-721 standard. In particular, we shall see below that we found the OWL taxonomic constructors, namely subclass and sub-property ones, convenient to specify Ether-OASIS. By following the OASIS specifications, the template is leveraged to define concrete behaviours modelling the functionalities of smart-contracts that are developed by Ethereum users. Any type of transactions, included the one for releasing and retiring smart contracts, can be annotated by means of the schema provided by Ether-OASIS to describe the Ethereum blockchain and its constitutional elements (illustrated in Section 4.1). Moreover, Ether-OASIS provides a means to semantically describe the operations induced by blockchain transactions through suitable OASIS agent actions (as shown in Section 4.2), including the operations for generating, transferring, and destroying tokens: Ether-OASIS pays particular attention to the Ethereum tokens, currently focusing on the ERC-721 compliant ones. Finally, the ontological knowledge base derived from the application of Ether-OASIS can be queried to deeply investigate on the activities carried on the blockchain. Hence, Ether-OASIS can be leveraged to annotate any activity on Ethereum, thus enabling semantic searching and reasoning, or can be extended by ontologies to represent other blockchains that are equipped with the management of smart contracts such as Cardano. Moreover, Ether-OASIS plays an important role for those ontologies that aims at reaching in heterogeneous systems and in many enterprise applications the interoperability between on chain and off-chain information. A common utilization of such data is given by the competency questions illustrated in Section 6. The main object-properties and classes of Ether-OASIS are illustrated in Appendix B, Fig. 16 and Fig. 17, respectively.

Fig. 4.

UML diagram of the Ethereum blockchain in Ether-OASIS.

4.1. The Ethereum blockchain in Ether-OASIS

Ethereum is represented in Ether-OASIS as illustrated in the schema of Fig. 4.5

⁵
For the rest of this article, we use the namespace prefix oasis for OASIS, aoasis for OASIS-Abox, while for Ether-OASIS the prefix is omitted.

Ethereum blocks embedding transactions are represented by instances of the class EthereumBlock (subclass of BlockchainBlock that represents general blockchain blocks) and connected to the embedded transactions by means of the object-property embeds. Each transaction is identified by an instance of the class EthereumTransaction (subclass of BlockchainTransaction that represents general blockchain transactions), encapsulating the main transaction information.

Miners nodes are conceived as OASIS agents identified by instances of the class EthereumNode (subclass of BlockchainNode that represents general blockchain nodes) and linked to the mined block through the object-property mines. Since miners are OASIS agents, instances of BlockchainNode are also instances of the class Agent. Moreover, instances of the class EthereumNode are connected to instances of the class EthereumSystem by means of the object-property constitutes. In contrast with analogous approaches such as Ethon and BLONDiE, such a characterization of nodes, blocks, and transactions allows one to describe activities carried out by both in-chain and off-chain agents, thus providing a higher-level model that unifies them. Specifically, Ethereum activities are classified into three main categories, namely a) smart contracts deployments, represented by instances of the class EthereumSmartContratCreation (subclass of BlockchainSmartContractCreation, representing the deployment of smart contracts into the blockchain), b) smart contracts interactions, represented by instances of the class EthereumSmartContractInteraction (subclass of BlockchainSmartContractInteraction, representing the interaction of blockchain smart contracts), and c) cryptocurrency exchanges, represented by instances of the class EtherExchangeSmartContractInteraction (subclass of CryptocurrencyExchangeBlockchainInteraction that in its turn is a subclass of BlockchainSmartContractInteraction).

In Ether-OASIS, also smart contracts deployed into the Ethereum blockchain correspond to OASIS agents with well-defined behaviours: interactions with smart contracts are represented by means of plan executions and linked to the behaviour that induced the action. Specifically, the creation of a smart contract is represented by an instance of the class BlockchainSmartContractCreation, which is related to the agent endowing the behaviour generating the action by means of the object-property describes. Such agent is represented by an instance of the class BlockchainSmartContractAgent, subclass of Agent. Instances of BlockchainSmartContractCreation are also associated by means of the object-property associatedWith with the related Ethereum accounts, represented by instances of the class EthereumSmartContractAccounts (subclass of BlockchainSmartContractAccount that represents blockchain smart contract accounts and is a subclass of BlockchainAccount, the latter representing blockchain accounts). Users are associated with Ethereum externally owned accounts (EOA), represented by instances of the class EOA-EthereumAccount (subclass of EOA-BlockchainAccount, representing blockchain externally owned accounts, which in its turn is a subclass of BlockchainAccount).

Ether-OASIS identifies four main general types of smart contract agents: a) smart contracts providing non-fungible token exchange mechanisms compatible with the Ethereum standard ERC-721, which are represented by instances of the class EthereumERC721SmartContractAgent (subclass of NonFungibleBlockchainSmartContractAgent, representing non-fungible smart contracts); b) smart contracts providing fungible token exchange mechanisms compatible with the Ethereum standard ERC20, which are represented by instances of the class EthereumERC20SmartContractAgent (subclass of FungibleBlockchainSmartContractAgent, representing fungible smart contracts); c) agents responsible for exchanging the Ether cryptocurrency, which are represented by instances of the class EtherExchangeSmartContractAgent (subclass of CryptocurrencyExchangeBlockchainSmartContractAgent); d) general purpose and user-defined smart contract agents that do not enjoy the characteristics of the aforementioned smart contracts, which are introduced by instances of the class EthereumGeneralPurposeSmartContractAgent (subclass of GeneralPurposeSmartContractAgent, representing general purpose smart contracts). In OASIS, agents may perform actions autonomously or as response to requests of executing some operations submitted by a peer. As a consequence, in the blockchain ecosystem we mainly limit ourselves to take into account only requests that modify the state of the chain (both internal and external), and hence induce transactions, even through view functions (namely functions that do not modify the state of the chain), may be represented as well.

The transactions (represented by instances of the class EthereumTransaction) induced by interaction requests submitted to smart contracts are related with instances of the class EthereumContractInteraction (subclass of SmartContractInteraction, representing interactions of smart contracts through the blockchain) by means of the object-property describes. Instances of the class EthereumContractInteraction introduce plan descriptions as in the OASIS fashion by means of the object-property describes. The most notable subclass of the class EthereumContractInteraction is the class EtherExchangeSmartContractInteraction, representing the transferring of Ether from a wallet to another. The latter class is also a subclass of the class CryptocurrencyExchangeBlockchainSmartContractInteraction, representing interactions provided to transfer cryptocurrency through the blockchain, which in turn is a subclass of the class BlockchainSmartContractInteraction.

Figure 5 shows an Ethereum transaction storing the smart contract for emitting NFTs of the Sicilian Wheat Bank (SWB) S.p.A.6

⁶

https://www.bancadelgrano.it/en/

The individual block_node_10452395_tran_1 represents the Ethereum transaction and is related with the individual SWB_SmartContractCreation describing the smart contract by means of the object-property describes. The description of the agent identifying the SWB smart contract is introduced by the individual SWB_smart_contract_agent, which is linked to SWB_smart_contract_creation by means of the object-property describes. Finally, the node (SparkPool) that mined the block (block_node_10452395) that includes the transaction is also associated to the Ethereum main-net (ethereum_mainnet) by means of the object-property constitutes.

Fig. 5.

UML diagram of an example of an Ethereum transaction in Ether-OASIS.

4.2. The ERC-721 protocol in Ether-OASIS

Next, we show how Ether-OASIS represents the main ERC-721 standard functions for managing non-fungible tokens on the Ethereum blockchain, namely a) minting tokens, b) transferring tokens, c) burning tokens, d) verifying ownership, e) granting ownership of single tokens, f) granting ownership of all the tokens stored in the wallet.

As described above, the smart contracts defined for the ERC-721 token management are introduced by way of instances of the class EthereumERC721SmartContractAgent (subclass of Agent). In OASIS, agents having similar behaviours inherit the representation of their behaviour from a common shared template providing general descriptions that may be customised by concrete agents. For this purpose, Ether-OASIS provides a template for the ERC-721 standard introduced by the individual ethereum_ERC721_smart_contract_behavior_template, which describes the behaviours of agents minting, burning, and transferring Ethereum NFTs according to the guidelines provided by the standard. Other functions admitted by the standard ERC-721, namely the approve function (delegating wallets for managing single tokens), the setApprovalForAll function (delegating wallets for managing all the tokens owned), and ownerOf (for retrieving the owner of a given token) are also represented in Ether-OASIS.

Figure 6 illustrates the behaviour template provided by Ether-OASIS that introduces the ERC-721 function for generating new tokens, namely the mint function. Such behaviour template consists of a single goal, which in its turn consists of a single task. Tasks comprise four elements. The first element is the task operator, providing the description of the action to be performed, namely minting, which is introduced by means of the individual mint (instance of the OASIS class Action) through the object-property refersExactlyTo. We recall that the object-properties refersExacltyTo and refersAsNewTo are used to describe how constituting elements of agent behaviours must be matched when a verification of compatible behaviours occurs. The object-property refersExactlyTo introduces well-known entities whose IRIs must correspond to the IRIs of the matched entities or for which the OWL object-property sameAs has been expressed. On the contrary, the object-property refersAsNewTo introduces entities (instances of the class ReferenceTemplate) that are used as general descriptions encapsulating the features that the matching entities must satisfy.

The second element of the ERC-721 token minting task is the operator argument introducing the individual blockchain_digital_token by means of the object-property refersExactlyTo. Operators and operator arguments identify unambiguously that the referred operation consists in generating (digital) tokens on the blockchain. The third and the fourth elements represent the recipient and the outcome of the operation, respectively. The recipient is described by the template of the task object, while the outcome is introduced by the template of the output parameter of the task. The object template and the output parameter are both connected through the object-property refersAsNewTo to the entity mint_ERC721_token, which describes the features that the recipient of the action must have, namely, being an instance of the class EthereumTokenERC721.

Fig. 6.

UML diagram of behaviour template for the ERC-721 minting function.

The behaviour for the ERC-721 function for transferring tokens is depicted in Fig. 7. The behaviour provides three input parameters, one for the token to be transferred and one for each externally owned account involved in the transferring of the token, namely the source wallet and the destination wallet. The source and destination wallets are introduced by exploiting the object-property refersAsNewTo by means of two individuals that are instances of the class EOA-EthereumAccount, namely, transfer-2_ERC721_EOA-account (the source) and transfer-3_ERC721_EOA-account (the destination). To ensure that the token is transferred from the wallet identified as source to the wallet identified as destination, the conditional illustrated in Fig. 8 is provided.

Fig. 7.

UML diagram of behaviour template for the ERC-721 transfer function.

The conditional ensures that a transfer activity for each token to be transferred exists. The conditional has a fresh transfer activity as conditional object, and the individual exist as operator. In its turn, the transfer activity indicates as transfer source the wallet used as first parameter in the token transferring, as transfer destination the wallet used as second parameter, and as transferred object the token passed as input parameter.

Fig. 8.

UML diagram of the conditional for the ERC-721 transfer function.

The behaviour for the burning function of the ERC-721 standard is depicted in Appendix B, Fig. 18. In this case, the individual ethereum_ERC721_smart_contract_behavior_template (representing the ERC-721 behaviour template) is also connected to the behaviour describing the burning function, whose structure is analogous to the minting function but with a different action and with an input parameter template instead of an output parameter template. The action introduced in the burning function is the individual burn, while the input parameter template is connected with an individual representing the token to be burnt that is passed as input to the burning function.

The standard ERC-721 also allows the owner of tokens to delegate wallets to manage tokens on his/her behalf. Authorizations may be carried out either on a single token or on any token stored in his/her wallet. The ERC-721 function approve and setApprovalForAll are introduced for the former and the latter case, respectively.

In case that an externally owned account is authorised to manage a single token, the behaviour in Appendix B, Fig. 19 is adopted.

Specifically, the behaviour introduces: (a) the account to be authorised and the granted token, as input parameter; (b) the instance delegate, as operator; and (c) the instance ownership, as task operator argument.

The conditional in Appendix B, Fig. 20 ensures that only the operation of burning and transferring may be performed when the wallet is authorised to operate on behalf of his owner. Such a condition is guaranteed by the existence of a delegation activity (instance of DelegationActivity) having as delegation property the instances burn and transfer. The subject and the object of the delegation activity are the authorised wallet and the granted token, respectively.

The Ethereum ERC-721 standard allows token owners to authorise an account to manage all the tokens owned. The corresponding behaviour is illustrated in Appendix B, Fig. 21. The behaviour is similar to the behaviour template introduced for granting a single token, with the only difference that there is no input parameter concerning the granted token. In this case, the conditional in Appendix B, Fig. 22, ensures that authorization is extended to each token owned. Indeed, the delegation object expresses the object-property hasSpecificity with value the individual any.

The Ethereum ERC-721 standard allows users to discover the wallet currently owning a certain token. The corresponding behaviour is illustrated in Appendix B, Fig. 23. The behaviour is related with a task description providing both as recipient and as input parameter the selected token whose owner has to be retrieved. The conditional in Appendix B, Fig. 24, ensures that the wallet retrieved is the effective owner of the token considered.

Fig. 9.

UML diagram of the Ethereum token representation in Ether-OASIS.

One of the most important features of Ether-OASIS consists in modelling Ethereum tokens. The schema adopted is illustrated in the diagram of Fig. 9. Ether-OASIS identifies four main types of tokens:

non-fungible tokens, represented by instances of the class EthereumSemiFungibleToken, the latter containing the class EthereumTokenERC721 that represents non-fungible tokens compliant with the ERC-721 standard protocol. In its turn, EthereumSemiFungibleToken is a subclass of the OASIS class SemiFungibleToken.

Fungible tokens, represented by instances of the class EthereumFungibleToken, the latter containing the class EthereumTokenERC20 that represents fungible tokens compliant with the ERC20 standard protocol. EthereumFungibleToken is a subclass of FungibleToken.

Semi-fungible tokens, represented by instance of the class EthereumSemiFungibleToken, the latter containing the class EthereumTokenERC1155 that represents semi-fungible tokens compliant with the ERC1155 standard protocol. EthereumSemiFungibleToken is a subclass of SemiFungibleToken.

Custom user-defined tokens not compliant with the ERC standard protocols, represented by instances of the class EthereumCustomToken, subclass of CustomToken.

Additionally, the four mentioned classes are defined as subclasses of the class EthereumToken.

Inspired from the definitions in (Gangemi et al., 2002), tokens carry two types of features, namely a) endurant features such as the token ID that never change and are embedded with the entity representing the token, and b) perdurant features that change during the life-span of the token and are associated with an instance of the class EthereumTokenPerdurantFeatures (subclass of PerdurantFeature) by means of the object-property hasEthereumTokenPerdurantFeature.

The most notable subclass of PerdurantFeature is the class EthereumWalletOwnerPerdurantFeature, which associates tokens with the related owner (by means of the object-property isInTheWalletOf). When the perdurant features of a token are modified by the smart contract managing it, they became deprecated and replaced with a new set of features by means of a suitable modification activity. Those new features are introduced by a fresh instance of the class PerdurantFeature. Modifications of tokens are allowed only when they involve perdurant features and hence endurant features cannot change. Perdurant features may be replaced with other perdurant features by introducing an instance of the class EthereumTokenFeatureModificationActivity, which is connected with (i) the changed perdurant feature, which is also an instance of the class EthereumTokenDeprecatedPerdurantFeature by means of the object-property hasEthereumTokenFeatureModificationSource, and with (ii) the new perdurant feature, by means of the object-property hasEthereumTokenFeatureModificationResult.

Moreover, the modified perdurant feature is connected with the perdurant feature that replaces it by means of the object-property isEthereumTokenFeatureModifiedIn, while the token embedding the features is connected with the new perdurant feature by means of the object-property hasEthereumTokenPerdurantFeature, as described above.

Analogously, the state of a token can be changed from active to burned. An instance of the class TokenActivationStatusModificationActivity is introduced to represent the burning of the token due to a call to the burning function of the smart contract. Such instance connects the old active status, which is now deprecated, by means of the object-property hasTokenActivationStatusModificationSource, and a new status (representing the deactivation status) by means of the object-property hasTokenActivationStatusModificationResult.7

⁷

This approach based on deprecating the old activation status is motivated by the fact that, unlike perdurant features, activation status of tokens can be restored, depending on how the burning function is implemented.

5. An example of Ether-OASIS on NFTs of wheat

In this section we illustrate a concrete application of Ether-OASIS. We take into account the smart contract depicted in Section 4.1, Fig. 5, that implements the trading mechanisms of NFTs digitizing batches of wheat.8

⁸
The OWL of the example can be found in https://github.com/dfsantamaria/OASIS/tree/main/AO2022-addendum/UseCaseasswb-example.owl. The repository also includes the Python program used to generate the examples.

We recall that smart contracts are represented by the entity SWB_smart_contract_agent, instance of the class EthereumERC721SmartContractAgent. Smart contracts are conceived to manage NFTs representing batches of wheat that are generated and released to farmers as witnesses of the of the quality and type of production. An NFT of such type satisfies the following standard features.

An NFT of wheat is an instance of both the class EthereumTokenERC721, representing the Ethereum non-fungible tokens, and of the class SWBWheatToken, representing the token of wheat emitted by the SWB smart contract.

An NFT of wheat is related with an integer through the data-property hasEthereumTokenID, representing the unique and progressive identification code (ID) of the NFT. As foreseen by Ethereum, the ID is unique within the smart contract, and IDs of burned tokens are not reassigned.

An NFT of wheat satisfies at least one perdurant feature. The mandatory perdurant feature describes the ownership of the token.

Moreover, NFTs generated from the SWB smart contract satisfy the following features too:

An NFT of wheat is related with an instance of the class QualityClass (through the object-property hasQualityClass). Specifically, QualityClass contains the instances PlatinumQuality, GoldQuality, SilverQuality, and BronzeQuality, representing the quality level of wheat from the higher to the lower.

An NFT of wheat is related with a double through the data-property hasQuantity, representing the quantity of wheat digitised.

An NFT of wheat is related with an instance of type EthereumAccount through the object-property hasProducer, representing the wallet of the farmer that requested the digitization of the batch.

In this example we consider the minting and transferring of the token number 217 illustrated in Fig. 10. The token with ID 217 digitised a batch of 98 tons, classified as “gold” and currently owned by the wallet number “0x41db48574b0a6e59f30ad59fee63f023eb7b9745”.

Fig. 10.

Example of an SWB token numbered 217.

Fig. 11.

Minting behaviour of an SWB smart contract.

As a concrete agent, the smart contract implements all the behaviour templates in Section 4.2. In particular, the concrete behaviours for minting and transferring tokens are introduced by extending the corresponding template in Section 4.2, Fig. 6 and Fig. 7, respectively. For instance, the minting behaviour of the smart contract is depicted in Fig. 11. The concrete behaviour follows the same lines of the corresponding template. Each mental state of the behaviour is linked with the corresponding state of the template by means of the object-property overloads. As in the template, the recipient of the action represents an ERC-721 compliant token, which is additionally an SWB compliant token.

In order to generate the token 217, an agent commitment derived from the concrete behaviour in Fig. 11 is required. For this purpose, the fragment illustrated in Fig. 12 is introduced. The figure shows a fragment of the action associated with the minting behaviour of the SWB smart contract. The action carries all the mental states required to perform the minting of an SWB token, which are also connected by means of the object-property drawnBy with their corresponding states of the concrete behaviour of the smart contract. The task recipient is a specific entity that refers to token 217, which is different from the general SWB token described in the template recipient. The task recipient is linked to the token 217 by means of the object-property ‘refersAsNewTo’.

Fig. 12.

The agent commitment for minting the SWB token 217.

From now on, the token is available and ready to be traded. To complete the example, the token 217 is transferred from the wallet of the farmer to a chosen wallet (called cp132-trader). In a similar way as the minting of the token, an agent commitment derived from the concrete behaviour devoted to the transferring of SWB tokens is required. As a consequence of that action, the ownership of the token is changed through the introduction of a modification activity involving the perdurant features of the Ethereum token. Specifically, the modification activity is introduced to mark as deprecated the perdurant feature that associates the ownership of the token with the producer, and to introduce a new perdurant feature that associates the token with the new owner. The result is shown in Fig. 13. The figure shows (on the left) the transfer activity involving the two perdurant features concerning the ownership of the token 217, the old perdurant feature that becomes deprecated (on the right), and the new perdurant feature (in the bottom-center). Now the token is in the wallet of the new owner cp132-trader and can continue its life cycle.

Fig. 13.

The transfer activity involving the SWB token 217.

6. Evaluation of Ether-OASIS

The Ether-OASIS ontology was evaluated during the entire life-time of its development through four main Key Performance Indicators (KPIs). To begin with, the consistency check was carried on by means of three main OWL reasoners, thus demonstrating the soundness of the ontology. Then, structural metrics that depicts the number and type of elements used to define Ether-OASIS, such as number of classes and object-properties, were computed, providing a general evaluation of how much the ontology is large and complex. Protégé (Musen, 2015) was used to compute the structural metrics of the ontology. Furthermore, ontological metrics (Garcia, Garcia-Peñalvo and Therón, 2010) were calculated on Ether-OASIS, excluding the imported ontologies OASIS and OASIS-Abox: this ensures that metrics depend only on the root ontology and are not affected by any imported ontologies. The evaluation took into account all the schema metrics defined by the OntoQA approach (Tartir et al., 2005).

In addition, a suitable set of competency questions were defined for the modeling of Ether-OASIS. Competency questions constitute questionnaires in natural language, which help to clarify the context and the scope of an ontology, aiming at verifying whether an ontology is truly being developed towards the project objectives and is reaching the stated representational goals. Competency questions are implemented into SPARQL queries in order to be performed against the developed ontology. SPARQL queries also constitute regression and integration tests for the ontology.

In what follows, we report the results of the evaluation methodology, including the competency questions defined, together with a discussion of the results obtained.

Consistency check has been carried out by the reasoners Pellet (Sirin et al., 2007), HermiT (Glimm et al., 2014), and FaCT $+ +$ (Tsarkov and Horrocks, 2006). The last column of Table 1 reports the structural metrics computed on the original ontology Ether-OASIS, hence excluding the values inherited from OASIS. The values obtained from the BLONDiE ontology are reported in the first column of Table 1. A comparison with the Ethon ontology is not currently practicable due to the project’s apparent abandonment and lack of an accessible working version.9

⁹
The last GitHub commit (https://github.com/ConsenSys/EthOn) and author’s interaction are dated 2018.

Table 1

Structural metrics on Ether-OASIS

Metric	BLONDiE	Ether-OASIS
Axiom count	323	555
Logical axiom count	210	368
Declaration axiom count	98	187
Class count	23	85
Object property count	11	47
Data property count	64	16
Individual count	0	125
Subclass axiom count	16	40
Sub-object-property axiom count	0	12
Object property domain axiom count	11	12
Object property range axiom count	11	12
Data property domain axiom count	64	8
Data property range axiom count	64	7

We recall that BLONDiE provides the description of three blockchains, namely Ethereum, Hyperledger Fabric, and Bitcoin, while Ether-OASIS is focused on the first one. Due to the hierarchies introduced to describe smart contracts and tokens, Ether-OASIS provides more classes and object-properties than BLONDiE, making it a larger ontology.

Ether-OASIS provides less data-properties, since many blockchain elements are represented by means of class and individuals instead of data-types. For instance, the block miner is introduced in BLONDiE by means of the data-property minerBlock, while it is represented as an OASIS agent in Ether-OASIS.

Moreover, Ether-OASIS introduces 125 individuals used for representing the behaviour templates and conditionals for the ERC-721 smart contracts, such as ethereum-system, which represents the Ethereum blockchain.

The ontological metrics computed by OntoQA on the Ether-OASIS ontology are reported in Table 2, and are compared with those obtained from BLONDiE.

Table 2

Ontological metrics of Ether-OASIS

Evaluation criteria	BLONDiE	Ether-OASIS	Delta %
Relationship richness	82.41%	61.55%	−25.31%
Inheritance richness	2.28%	1.14%	−50%
Tree balance	0.88%	0.37%	−57.95
Attribute richness	0.30%	0.31%	+ 3.3%
Class richness	0	41.17%	+INF

The relationship richness metric reflects the diversity of the relations and the placement of the relations occurring in the ontology. With respect to BLONDiE, the difference of relationship richness in Ether-OASIS is appreciable because BLONDiE makes large use of data-properties to describe the constitutional elements of three blockchains. The inheritance richness describes the distribution of information across the different levels of the inheritance tree of the classes. BLONDiE reports a higher inheritance richness with respect to Ether-OASIS, because it covers a larger domain and many classes and properties used in Ether-OASIS derive from the imported ontology OASIS. Moreover, tree balance, namely how much class hierarchies differ in deepness, is also higher in BLONDiE than in Ether-OASIS, because Ether-OASIS inherits from OASIS many classes and properties that are not included in the computation of the metric. The class richness is related to how instances are distributed across classes. Class richness of Ether-OASIS is higher, as it contains many individuals, while BLONDie records a 0%, since it does not include any individual. Finally, attribute richness calculates the average number of attributes per class, giving insight into how much knowledge about classes is represented in the model. Attribute richness is almost the same in Ether-OASIS and BLONDiE.

We are now ready to discuss the competency questions for the Ether-OASIS ontology. In addition to the following competency questions, which are also addressed by BLONDiE and Ethon,

Who mined a specific block?

What is the height of a specific block?

How many transactions are written in a block?

Is a transaction confirmed?

How many total coins were transferred on a block?

Ether-OASIS answers also at least the competency questions C1–C4 below, specifically concerned with the management of tokens and related smart contracts. The SPARQL implementation of the competency questions can be found in Appendix C.

C1: Which are the tokens minted and not burned, the associated asset, minter, and current owner?

Competency question C1 is intended to retrieve the tokens available on the Ethereum blockchain and their type, providing an overview of the current arrangement of the token market. In addition, the competency question also shows the asset digitised by the token, thus enabling users to discover and possibly acquire the desired product through a decentralised infrastructure: by knowing quantity and type of assets traded by means of their corresponding tokens, it is possible to realise new instruments for analyzing the market and potentially generate new business opportunities.

C2: Which are the block and the transaction hash that mint a given token?

Competency question C2 allows users to verify that the given token has been effectively minted on the blockchain, and hence a proof for the related asset is available. In addition to the other competency questions, this constitutes a countermeasure against NFTs scams.

C3: Which are the smart contracts that emit tokens related with a specific type of asset?

Competency question C3 allows users to access the smart contracts that generate the tokens associated with the desired type of digital or physical asset: the functionalities of the smart contracts are clearly expressed, thus users have an effective instrument to evaluate the affordability of the related NFT exchange system.

C4: Which is the number of tokens and the type of the related assets owned by wallets?

Competency question C4 allows users to verify how many tokens associated with the desired asset are owned by wallets, thus permitting to check whether whale wallets own the desired tokens. The term ‘whale wallet’ refers to individuals or entities that hold large amounts of specific cryptocurrencies or tokens and therefore have the potential to manipulate their valuations on the market.

7. Conclusions

This paper presented the Ether-OASIS ontology that models the Ethereum blockchain and the smart contracts deployed on it, in particular, by focusing on the representation of the ERC721 standard for managing non-fungible tokens (NFTs). Ether-OASIS exploits the behaviouristic approach pursued by the OASIS ontology to semantically represent the Ethereum blockchain, thus providing a tool for making the blockchain more easily accessible both technically and from a human perspective. An analysis by ontological metrics is also provided through a comparison with BLONDiE, an ontology with similar goals but limited capabilities. Suitable competency questions are also presented to verify the alignment of the project with the representational goals.

Ether-OASIS allows smart contracts and related NFTs to be located by specifying the desired features, hiding the underlying implementation details, while supporting the integration of off-chain and cross-chain applications. Moreover, tokens are meaningfully associated with traded assets so as to provide a semantic search across the blockchain, cross-chain, and off-chain infrastructures. The ontological representation of Ether-OASIS enables users to find smart contracts by inspecting general descriptions of their behaviours and related managed NFTs. Ether-OASIS enables the blockchain with the automatic discovery of smart contracts in a transparent and automatic way, independently from the implementation of the ledger. It follows that blockchain transactions and the embedded information are easily searchable and accessible at a higher level, hence off-chain services can be built to realise smarter decentralised applications. Notably, affordable semantic marketplaces can be delivered, where sellers and buyers may freely choose the services associated with their interest and business. Users are enabled to profitably find goods, products, resources, and services, in line with their expectations and requirements, especially in the context of NFT trading, where black-boxes pose a relevant economic risk. Thanks to OASIS, it was known by intuition that the Ether-OASIS approach had the power of generality, and our findings confirm that by demonstrating it at an applied level.

Ether-OASIS moves towards the Semantic Blockchain and hence many future works must to be take into account. The very next step is to extend Ether-OASIS so as to model the standard protocol ERC1155 for semi-fungible tokens and to represent different blockchains such as Hyperledger Fabric and Cardano. In particular, we foresee an extension of Hyperledger Fabric to take up the design of the Ether-OASIS ontology and build a Semantic Blockchain, also including a semantic search engine. Such a search engine could exploit the model provided by Ether-OASIS to find desired smart contracts and tokens using mechanisms such as auto-generating parametric ad-hoc SPARQL queries (Cantone et al., 2019). Moreover, representing the ontological stack through the decidable fragments of set-theory as in (Cantone et al. (2015–2017) is one of the future works. Finally, we foresee an extension of Ether-OASIS involving the ontological representation of cryptography protocols and cryptography proof mechanisms such as Proof Of Work, Proof of Stake, Proof of Integrity, and Zero Knowledge Proof.

In conclusion, the present work supports the claim that the potential of the semantic representation of blockchains is vast, contributing substantially to the more flexible yet usable blockchain technology expected in the very next version of the Web.

Footnotes

Acknowledgements

This work is an extended version of the paper “Blockchains through ontologies: the case study of the Ethereum ERC721 standard in OASIS”. In D. Camacho et al. (eds.), Intelligent Distributed Computing XIV, Studies in Computational Intelligence 1026, Chapter 23, pp. 249–259.

This work was supported by the project “FuSeCar” funded by the MUR Progetti di Ricerca di Rilevante Interesse Nazionale (PRIN) Bando 2022 – grant 2022W3EPEP – CUP: E53D23008210006

The work of POC4Commerce has been supported by the ONTOCHAIN NGI European project grant agreement no. 957338. We are thankful to the ONTOCHAIN Consortium who mentored and assisted the research.

Domenico Cantone acknowledges partial support from project “STORAGE–Università degli Studi di Catania, Piano della Ricerca 2020/2022, Linea di intervento 2” and from the “Naples Dante Project” funded by the MUR Progetti di Ricerca di Rilevante Interesse Nazionale (PRIN) Bando 2022, grant 2022ZJ4N9E. Domenico Cantone is member of the Gruppo Nazionale Calcolo Scientifico-Istituto Nazionale di Alta Matematica (GNCS-INdAM).

Daniele Francesco Santamaria acknowledges the Research Program PIAno di inCEntivi per la Ricerca di Ateneo 2020/2022 – Linea di Intervento 3 “Starting Grant” – University of Catania.

UML diagrams of OASIS

UML diagrams of Ether-OASIS

SPARQL queries for the Ether-OASIS competency questions

References

Aswini, R. & Padmapriya, N. (2021). Semantic and blockchain technology. In Advanced Concepts, Methods, and Applications in Semantic Computing (pp. 50–71). ISBN 9781799866992.

Baqa, H., Truong, N., Crespi, N., Lee, G.M. & Le Gall, F. (2019). Semantic smart contracts for blockchain-based services in the Internet of Things. In 2019 IEEE 18th International Symposium on Network Computing and Applications (NCA) (pp. 1–5). doi:10.1109/NCA.2019.8935016.

Bella, G., Cantone, D., Longo, C., Nicolosi Asmundo, M. & Santamaria, D.F. (2021). Semantic Representation as a Key Enabler for Blockchain-Based Commerce. Lecture Notes in Computer Science (Including Subseries Lecture Notes in Artificial Intelligence and Lecture Notes in Bioinformatics) LNCS (Vol. 13072, pp. 191–198). doi:10.1007/978-3-030-92916-9_17.

Bella, G., Cantone, D., Longo, C., Nicolosi Asmundo, M. & Santamaria, D.F. (2022). Blockchains through ontologies: The case study of the Ethereum ERC721 standard in oasis. Studies in Computational Intelligence, 1026, 249–259. doi:10.1007/978-3-030-96627-0_23.

Bella, G., Cantone, D., Longo, C.F., Nicolosi-Asmundo, M. & Santamaria, D.F. (2023a). The ontology for agents, systems and integration of services: OASIS version 2. Intelligenza Artificiale, 17(1), 51–62. doi:10.3233/IA-230002.

Bella, G., Cantone, D., Nicolosi Asmundo, M. & Santamaria, D.F. (2022). The Ontology for Agents, Systems and Integration of Services: Recent Advancements of OASIS. In 23rd Workshop from Objects to Agents, WOA 2022, Genova, 1–3 September 2022 (Vol. 3261, pp. 176–193). CEUR–WS. ISSN 16130073.

Bella, G., Cantone, D., Nicolosi-Asmundo, M. & Santamaria, D.F. (2021). Ether-OASIS ontology. https://github.com/dfsantamaria/OASIS.git.

Bella, G., Castiglione, G. & Santamaria, D.F. (2023b). A behaviouristic approach to representing processes and procedures in the OASIS 2 ontology. In Proceedings of the Joint Ontology Workshops 2023, Episode IX: The Quebec Summer of Ontology, Co-Located with the 13th International Conference on Formal Ontology in Information Systems (FOIS 2023), Sherbrooke, Québec, Canada, July 19–20, 2023. CEUR Workshop Proceedings (Vol. 3637, pp. 1–17).

Bresciani, P., Perini, A., Giorgini, P., Giunchiglia, F. & Mylopoulos, J. (2004). Tropos: An agent-oriented software development methodology. Autonomous Agents Multi Agent Systems, 8(3), 203–236. doi:10.1023/B:AGNT.0000018806.20944.ef.

10.

Cano-Benito, J., Cimmino, A. & Garcia-Castro, R. (2019). Towards blockchain and Semantic Web. In

Abramowicz and

Corchuelo (Eds.), Business Information Systems Workshops (pp. 220–231). Cham: Springer. doi:10.1007/978-3-030-36691-9_19.

11.

Cano-Benito, J., Cimmino, A. & García-Castro, R. (2021). Toward the ontological modeling of smart contracts: A solidity use case. IEEE Access, 9, 140156–140172. doi:10.1109/ACCESS.2021.3115577.

12.

Cantone, D., Longo, C., Nicolosi-Asmundo, M. & Santamaria, D.F. (2015). Web Ontology Representation and Reasoning via Fragments of Set Theory. Lecture Notes in Computer Science (Including Subseries Lecture Notes in Artificial Intelligence and Lecture Notes in Bioinformatics) (Vol. 9209, pp. 61–76). ISBN 978-331922001-7. doi:10.1007/978-3-319-22002-4_6.

13.

Cantone, D., Longo, C.F., Nicolosi-Asmundo, M., Santamaria, D.F. & Santoro, C. (2019). Towards an ontology-based framework for a behavior-oriented integration of the IoT. In 20th Workshop from Objects to Agents, WOA 2019, Parma, 26–28 June 2019 (Vol. 2404, pp. 119–126). CEUR–WS. ISSN 16130073.

14.

Cantone, D., Longo, C.F., Nicolosi-Asmundo, M., Santamaria, D.F. & Santoro, C. (2021a). Ontology for Agent, Systems, and Integration of Services (OASIS) – project page. https://github.com/dfsantamaria/OASIS.git.

15.

Cantone, D., Longo, C.F., Nicolosi-Asmundo, M., Santamaria, D.F. & Santoro, C. (2021b). OASIS-Abox ontology. https://github.com/dfsantamaria/OASIS.git.

16.

Cantone, D., Longo, C.F., Nicolosi-Asmundo, M., Santamaria, D.F. & Santoro, C. (2022). Ontological smart contracts in OASIS: Ontology for Agents, Systems, and Integration of Services. In

Camacho , et al. (Eds.), Intelligent Distributed Computing XIV. Studies in Computational Intelligence (Vol. 1026, pp. 237–247). doi:10.1007/978-3-030-96627-0_22.

17.

Cantone, D., Nicolosi-Asmundo, M. & Santamaria, D.F. (2016). Conjunctive query answering via a fragment of set theory. In 17th Italian Conference on Theoretical Computer Science, ICTCS 2016, Lecce, 7–9 September 2016 (Vol. 1720, pp. 23–35). CEUR–WS. ISSN 16130073.

18.

Cantone, D., Nicolosi-Asmundo, M. & Santamaria, D.F. (2017). A Set-Theoretic Approach to ABox Reasoning Services. Lecture Notes in Computer Science (Including Subseries Lecture Notes in Artificial Intelligence and Lecture Notes in Bioinformatics) LNCS (Vol. 10364, pp. 87–102). doi:10.1007/978-3-319-61252-2_7.

19.

Christidis, K. & Devetsikiotis, M. (2016). Blockchains and smart contracts for the Internet of Things. IEEE Access, 4, 2292–2303. doi:10.1109/ACCESS.2016.2566339.

20.

de Kruijff, J. & Weigand, H. (2017). Understanding the blockchain using enterprise ontology. In CAiSE.

21.

English, M.D., Auer, S. & Domingue, J. (2016). Blockchain technologies & the Semantic Web: A framework for symbiotic development. In

Lehmann ,

Thakkar ,

Halilaj and

Asmat (Eds.), Computer Science Conference for University of Bonn Students (pp. 47–61).

22.

Ethereum (2021). Standart token non fungible ERC-721, last visit on 29/01/2022. https://ethereum.org/it/developers/docs/standards/tokens/erc-721/.

23.

Fill, H.G. (2019). Applying the concept of knowledge blockchains to ontologies. In AAAI Spring Symposium: Combining Machine Learning with. Knowledge Engineering.

24.

Gangemi, A., Guarino, N., Masolo, C., Oltramari, A. & Schneider, L. (2002). Sweetening ontologies with DOLCE. In

Gómez-Pérez and

V.R.

Benjamins (Eds.), Knowledge Engineering and Knowledge Management: Ontologies and the Semantic Web: 13th International Conference, EKAW 2002 Sigüenza, Spain, October 1–4, 2002. Proceedings (pp. 166–181). Springer.

25.

Garcia, J., Garcia-Peñalvo, F.J. & Therón, R. (2010). A survey on ontology metrics. In

M.D.

Lytras ,

Ordonez De Pablos ,

Ziderman ,

Roulstone ,

Maurer and

J.B.

Imber (Eds.), Knowledge Management, Information Systems, E-Learning, and Sustainability Research (pp. 22–27). Berlin Heidelberg: Springer. ISBN 978-3-642-16318-0. doi:10.1007/978-3-642-16318-0_4.

26.

Glimm, B., Horrocks, I., Motik, B., Stoilos, G. & Wang, Z. (2014). HermiT: An OWL 2 reasoner. Journal of Automated Reasoning, 53(3), 245–269. doi:10.1007/s10817-014-9305-1.

27.

Kim, H.M. & Laskowski, M. (2018). Toward an ontology-driven blockchain design for supply-chain provenance. Int. Syst. in Accounting, Finance and Management, 25(1), 18–27.

28.

Musen, M.A. (2015). The protégé project: A look back and a look forward. AI Matters, 1(4), 4–12. doi:10.1145/2757001.2757003.

29.

NGI-ONTOCHAIN (2020). ONTOCHAIN a new software ecosystem for trusted, traceable & transparent ontological knowledge. https://ontochain.ngi.eu/.

30.

Pfeffer, J., Beregszazi, A. & Li, S. (2016). Ethon – an ethereum ontology. Available on-line: https://ethon.consensys.net/index.html.

31.

Ruta, M., Scioscia, F., Ieva, S., Capurso, G., Pinto, A. & Di Sciascio, E. (2018). A blockchain infrastructure for the Semantic Web of Things. In 26th Italian Symposium on Advanced Database Systems (SEBD 2018).

32.

Sirin, E., Parsia, B., Grau, B.C., Kalyanpur, A. & Katz, Y. (2007). Pellet: A practical OWL-DL reasoner. Web Semantics, 5(2), 51–53. doi:10.1016/j.websem.2007.03.004.

33.

Statista (2024). NFT – worldwide, last visit on 15/03/2024. https://www.statista.com/outlook/fmo/digital-assets/nft/worldwide.

34.

Szabo, N. (1997). Formalizing and securing relationships on public networks. First Monday, 2(9). doi:10.5210/fm.v2i9.548.

35.

Tartir, S., Arpinar, I.B., Moore, M., Sheth, A.P. & Aleman-Meza, B. (2005). OntoQA: Metric-based ontology quality analysis. In Proceedings of IEEE Workshop on Knowledge Acquisition from Distributed, Autonomous, Semantically Heterogeneous Data and Knowledge Sources.

36.

Tom’s Hardware (2022). Minecraft NFT game blockverse evaporates with $1 million, last visit on 31/01/2022. https://www.tomshardware.com/news/minecraft-nft-game-blockverse-evaporates-with-1-million.

37.

Tsarkov, D. & Horrocks, I. (2006). FaCT++ description logic reasoner: System description. In

Reasoning ,

Furbach and

Shankar (Eds.), Automated Reasoning (pp. 292–297). Berlin Heidelberg: Springer. ISBN 978-3-540-37188-5.

38.

Ugarte Rojas, H.E. (2017). A more pragmatic web 3.0: Linked blockchain data. In Google Scholar.

39.

van Riemsdijk, M.B., Dastani, M. & Winikoff, M. (2008). Goals in agent systems: A unifying framework. In AAMAS 08, International Foundation for Autonomous Agents and Multiagent Systems (pp. 713–720). ISBN 9780981738116.

40.

Wooldridge, M. & Jennings, N. (1995). Intelligent agents: Theory and practice. Knowledge Engineering Review, 10(2), 115–152. doi:10.1017/S0269888900008122.

41.

World Wide Web Consortium (2004). SWRL: A Semantic Web Rule Language Combining OWL and RuleML. http://www.w3.org/Submission/SWRL/ .

42.

Xu, X., Weber, I., Staples, M., Zhu, L., Bosch, J., Bass, L., Pautasso, C. & Rimba, P. (2017). A taxonomy of blockchain-based systems for architecture design. In Software Architecture (ICSA), 2017 IEEE International Conference on (pp. 243–252). IEEE. http://design.inf.usi.ch/sites/default/files/biblio/icsa2017-blockchain.pdf . doi:10.1109/ICSA.2017.33.