A behaviouristic semantic approach to blockchain-based e-commerce

The overarching goal of the present article is to lay out the foundations for a clear and unambiguous semantic representation of the blockchain Ethereum in the area of e-commerce, but generalizable to any Turing-complete blockchain. Therefore, we focus on the Ethereum smart contracts and transactions related to NFT trading and associated with commercial means.

Achieving this goal would have several advantages. A major one would be the simplification and automation of the tasks of querying the blockchain for identifying creation, destruction, or transfer of specific tokens and related features, as well as the smart contract exchanging specific types of tokens and the trading conditions.

It must be clear that such tasks are customarily left to (human) programmers. For example, programmers routinely have to study API documentation in order to interact with a new blockchain-based ecosystem and program new facilities. While APIs may (often) be badly documented, it is unquestionable that any developments are tightly bound to a scaling up of human resources – by contrast, a semantic representation notoriously makes the disrupting contribution of breaking up the tightness of that bound. Therefore, once the technicalities of blockchain-based e-commerce get semantically represented, much access, integration, and, in general, development effort can be offloaded to machines, which become able to interpret potentially unbound volumes of data, information, and, consequently, knowledge. Noteworthy mentioning, traditional blockchain APIs permit limited query capabilities involving transactions logs, blocks, and transactions metadata, functions signatures or, as in the case of the Etherscan search engine, keywords defined by the smart contract developer. However, they lack advanced features such as searching for NFTs, assets, or smart contracts with specific features, due to the hard-coded nature of the blockchain: APIs would be greatly enhanced and improved if DApps provided semantic meaning clearly explaining the operations they can carry out, how they process data, and the type of information they manipulate. This would, in turn, promote the widespread and widespread use of the new technologies at all levels of society. Some state of the art exists and, as we shall see below, is valid and useful, but the combination of blockchain systems and e-commerce from an epistemological standpoint is still out of reach, hence the goal for the present work.

1.2. Existing tools and chosen approaches

A few existing ontologies can be profitably leveraged. Notably, the GoodRelations [69] project has been active since 2001 and targets the semantic representation of commercial goods and services, while ontologies for blockchains were introduced much more recently, particularly with the widely-known ontologies BLONDiE [105] and Ethon [86]. However, these are pivoted on essential elements of the respective knowledge domain such as offerings and tokens, and lack on the operational use that the relevant stakeholders should make of those elements. Our approach is to frame the core elements of the commerce and blockchain domains within their effective contexts of use, including the roles that each participant may play.

As a consequence, another challenge is to take into account the relevant stakeholders, including applications, people, and assets. Because stakeholders may be active participants, it is convenient to leverage the concept of autonomous agent [73]. Agents are defined as entities whose state consists of mental components such as beliefs, capabilities, choices, and commitments [90]. On these premises, the Agent Oriented Programming (AOP) paradigm can be profitably adopted to represent open architectures that continuously evolve to adapt agents to external changes in a robust, autonomous, and proactive way. Another useful tool for our purposes is the Semantic Web, which provides a means for proof and trust models, mediation and communication, and representation mechanisms of the environment, thus supporting semantic markup annotations attached to data sources available to agents.

A practical way of semantically describing agents is through a behaviouristic approach [17], which aims at defining the tasks 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 to make the discovery of agents transparent, automatic, and independent of the underlying physical infrastructure. This implies that agents may join a collaborative environment in a plug-and-play fashion, as there is no need for third-party intervention. Additionally, thanks to the Semantic Web technology and reasoning techniques, data manipulated by agents carry machine-understandable information that can be processed, integrated, and exchanged by any type of agent at a higher level.

We contributed to the OASIS ontology [10–12,22], which applies the behaviouristic approach to deliver a general representation system and a communication protocol for agents and their interactions. Therefore, OASIS can be profitably leveraged here, so that commercial participants and their commitments are semantically described as agents by means of the actions they can perform through their commercial activities, including the applicable payment options, provision methods, and supply chains. This will allow people to freely choose products and services according to their needs and taste, as well as to increase awareness on the supply chains up to the delivery of goods.

1.3. Contributions

This article adopts the behaviouristic approach towards the representation of today’s blockchain-based e-commerce, in particular leveraging token generation and exchange mechanisms as decentralized public proofs. OASIS is leveraged by three novel ontologies, namely OC-Found, OC-Commerce and OC-Ethereum, to semantically describe the blockchain-oriented e-commmerce and related stakeholders. First, the OC-Found ontology extends OASIS, thus inheriting its representation of agents and their commitments. It introduces digital identities because they enable an agent to claim and manage their online identity within a decentralized and anonymous environment such as the blockchain. Moreover, OC-Found also covers supply chains because these account for how products and services are delivered and consumed by customers, an essential feature of commerce in general. The current release of the ontology accounts for the crucial steps of the supply chain, namely selling and delivering [71], but the ontological model is laid out and readily extensible with additional features, such as the other supply chain steps of planning, sourcing, and making. Finally, quality valuation mechanisms provide commercial participants with a means of publicly witnessing their experience.

Then, the OC-Commerce ontology captures the model of commercial offerings provided by GoodRelations and extends it with the representation system of agents and their commitments derived from OC-Found and inherited from OASIS. The stack culminates with the OC-Ethereum ontology, which imports the definitions of the BLONDiE ontology for the constitutional elements of the Ethereum blockchain to include the description of Ethereum tokens and the operational semantics of smart contracts. Additionally, OC-Ethereum describes the practical uses for the Ethereum ERC20 standard for fungible tokens, for the Ethereum ERC721 standard for non-fungible tokens and for the Ethereum ERC1155 standard for semi-fungible tokens.

The contributed ontological stack is publicly released [6] under GNU General Public License, version 3. It is evaluated by means of standard structural and ontological metrics, each time by relating the root of the ontology being defined to the import from relevant ontologies. It is also sanity-checked through a number of competency questions, which are implemented by suitable SPARQL queries. Competency questions constitute questionnaires in natural language, which help to clarify the context and the scope of ontologies, aiming at verifying whether the ontologies are truly being developed towards the project objectives and are reaching the stated representational goals.

Finally, the ontological stack is demonstrated on a real-world case study, the iExec marketplace [72], to further confirm its expressiveness.

Such contributions meet the goals stated in Section 1.1 and summarize the results of the POC4COMMERCE project [9], funded by the NGI ONTOCHAIN European initiative [83]. Following NGI ONTOCHAIN’s call for solutions for a secure and transparent blockchain-based knowledge management system, POC4COMMERCE delivers the ONTOCHAIN ontological stack, namely the core NGI ONTOCHAIN framework, with a focus on the commercial domain as outlined above, then unfolded in the sequel of this manuscript. A position paper calling for such contributions exists [7].

1.4. Structure

The paper is organized as follows. Section 2 concerns relevant related works. Section 3 outlines the existing ontologies that are leveraged through the present work. Specifically, Section 3.1 introduces the ontology OASIS, designed for representing agents and their commitments; Section 3.2 outlines the ontology GoodRelations for representing commercial offerings and selling conditions; and Section 3.3 focuses on the BLONDiE ontology for representing blockchains constitutional elements, such as block, wallet, and transaction. Then, Section 4 introduces the ontological stack and is organized into three subsections, one for each layer of the stack. Precisely, Section 4.1 presents the ontology OC-Found, which extends OASIS with supply chains, digital identities and quality valuation mechanisms; Section 4.2 introduces OC-Commerce, which imports OC-Found and extends GoodRelations with offerings, auctions, assets, and activities through the behaviouristic approach; and Section 4.3 depicts the OC-Ethereum ontology, which exploits BLONDiE by providing the representation of Ethereum smart contracts and related tokens in compliance with standards ERC20, ERC721, and ERC1155. Subsequently, Section 5 evaluates the ontological stack a) by considering both structural and ontological metrics applied to each ontology and compared with the related imported ontologies, and b) by suitable competency questions defined for each ontology and implemented as SPARQL queries. Section 6 demonstrates the stack on a real-world case study by modelling the iExec marketplace. Finally, Section 7 draws conclusions and directions for future research.

2.1. Services and the Semantic Web

In the context of the semantic representation of applications, the Semantic Web aims to enable users to locate, select, employ, compose and monitor web-based services automatically, giving rise to Semantic Web Services. Semantic Web Services describe Web Services with semantic content, thereby automatically enabling service discovery, composition, and invocation. For this reason, the DARPA Agent Markup Language (DAML) pursued the goal of developing a markup language for representing semantic relations in a machine-readable way [67]. In 2003, the World Wide Web Consortium (W3C) proposed OWL-S [109], an ontology for describing web services and related information. OWL-S tries to enable several tasks such as automatic web services discovery, automatic web services invocation, and automatic web services composition and interoperation. OWL-S explicitly supports the description of services as classes of activities, so that agents can decide how to use, invoke and interpret responses from them. However, since DAML and OWL-S are conceived to describe services, they do not adequately fulfil the requirements of describing general-purpose agents operating in different types of environments [81]. Indeed, describing agents as they coincide with services, although of a limited kind, may lead to an inaccurate and ambiguous depiction of them, also because service capabilities need to be semantically described both at a high and at a low level. Hence, one of the most prominent visions of the relationships between agents and services is one in which agents exploit, use, are composed of, or are deployed as, and are extended by services [81], which remain relatively simple. For example, Google Maps or GeoSPARQL may be conceived as agents for retrieving driving directions and described as actors able to compute the best path (in terms of time or distance) from a geographical amenity to another one that is realized through the related end-points. While GeoSPARQL is free to use, Google Maps requires an API-KEY that can be obtained free for limited use or on payment. The requirement of owning an API-KEY is a low-level mechanism related to the service, whereas the needed authorization is a high-level constraint of the agent. For these reasons, research communities have investigated several representation systems for agents and agent-based systems.

2.2. Agents and the Semantic Web

Since 2000, numerous studies have explored how agents enter and exit various interaction systems, utilizing both commitment objects [53] and virtual institutions [49]. Commitment objects are unambiguous, objective and independent of the agent mental states describing the effects that sending a message has on the social relationship between the sender and the receiver of the message (Social Semantics). By contrast, virtual institutions describe systems that regulate the behaviour of agents in a multi-agent system or in a multi-agent society (in particular their interaction) in compliance with the norms in force in that society. Therefore, Social Semantics is not able to represent agents that act autonomously, due to its declarative nature, i.e., it describes what agents do rather than how they do it [91].

The integration of agent systems and Semantic Web technologies has been investigated in the last decade in several contexts [56,66,67] and the advantages of ontology-based applications have been recognized in the analysis and development of MAS [102]. Those advantages are manifest a) in the context of agent matching, i.e., the capability of finding agents satisfying specific requirements and automatically engaging them, b) in the context of developing agents with standard features using shared common semantic tools, or c) as decision support for supply chains.

Ontologies for MAS have been modelled by taking approaches similar to those of Agent-Oriented Software Engineering (AOSE) [39,43], a software engineering paradigm for the development of complex MAS, based on the abstraction of agent roles and on their organizations. Other approaches inspired by belief-desire-intention agent architectures (BDI) [87] are proposed in [17] and in [51]. Inspired by Bratman’s theory of human practical reasoning [16], BDI systems focus on the idea that agents have certain goals (desires) and a set of plans whose realization leads to their achievement; plans are selected, thus becoming intentions, depending on the agent’s perception of the circumstances (represented by a set of beliefs). Beliefs, desires, and intentions are specified at a high level, often using a powerful logic/declarative approach: this enables the implementation of complex behaviours while still keeping code transparent and readable. The AOSE approach is intended to support all analysis and design activities in the software development process, whereas the BDI approach provides a flexible environment offering both traditional object-oriented imperative and declarative constructs, enabling the definition of a robot’s high-level behaviour in a simple, natural way. In [54], an ontology for agent-oriented software engineering is proposed along with a tool that generates programming code for MAS using the ontology. However, it does not examine agents and their interactions in detail, and it lacks an appropriate modelling of agent communication.

2.3. Domain-legacy approaches for Semantic Web agents

Some results attempt to bring uniformity and coherence to the increasing volume and diversity of information in a specific domain, but domain-legacy generally makes them not applicable to other contexts. For example, in [58], the authors propose an ontology-based framework to seamlessly integrate agents and Semantic Web Services, focusing on biomedical information. In [55], an infrastructure to allow agent-oriented platforms to access and query domain-specific OWL ontologies is presented. In [35], the authors introduce an approach to design scalable and flexible agent-based manufacturing systems integrating automated planning with multi-agent oriented programming for the Web of Things (WoT). In particular, autonomous agents synthesize production plans using semantic descriptions of web-based artifacts and coordinate with one another via multi-agent organizations. Concerning the Internet of Things (IoT), ontological approaches mainly focus on the description of sensors, with the purpose of collecting data associated with them to generate perceptions and abstractions of the observed world [4].

A comprehensive ontology for representing IoT services is presented in [107], together with a discussion on how it can be used to support tasks such as service discovery, testing and dynamic composition, taking into account also parameters such as Quality of Services (QoS), Quality of Information (QoI) and IoT service tests. A unified semantic knowledge base for IoT is proposed in [1], capturing the complete dynamics of IoT entities, for example enabling semantic searching while hiding their heterogeneity.

In [89], the authors discuss about the unification of the state-of-the-art architectures, as put forward by the scientific community of the Semantic Web of Things (SWoT), by means of an architecture based on different abstraction levels, namely Lower, Middle, and Upper Node (LMU-N). In [15], the authors propose a lightweight and scalable model, called IoT-lite, to describe key IoT concepts that allow interoperability and the discovery of sensory data on heterogeneous IoT platforms.

The W3C advances a formal model and a common representation for WoT descriptions based on a small vocabulary that makes it possible both to integrate diverse devices and to allow diverse applications to interoperate [113]. The representation system provides a way to expose the state of a thing and to invoke functions that, however, must be known in advance, and this may complicate the task of invoking agents that would like to join the environment in a plug-and-play manner. Moreover, the schema provided does not fully allow agents to interact according to the specific roles they aim to play.

In [22], the authors propose a first version of OASIS, an ontology to represent agents and their commitments using the behaviouristic approach adopted in this work, together with a home automation assistant based on it, called Prof-Onto. The approach used in [22] also represents a first foundational contribution to the use of Semantic Web technologies to define a transparent communication protocol among agents. It is based on the exchange of fragments of OASIS, each consisting of a description of a request that is checked, by means of ad hoc constructed queries, against the description of the behavior of the agent selected to satisfy it. Recently, the application of OASIS in the context of cybersecurity [13,14,32], video games [45], and chatbots [78–80] has been devised.

2.4. Business processes and the Semantic Web

It is worth noting that there are well-known applications of Semantic Web ontologies in the literature devoted to business processes. For example, in [100] an ontological approach is presented to represent business processes together with a prototype of a system architecture based on the proposed model. In [62], ontologies are used as facilities within a framework that assists designers in the realization and analysis of complex processes. In [38], they present an approach that combines logic programming and ontologies to verify the compliance of a business process with given business rules. Additionally, in [18], they propose an approach using Ontology-Based Data Access (OBDA) to manage data-aware processes. These processes are addressed, particularly those executed over a relational database that make calls to external services to acquire new information and update data. However, the downside of limiting ontological models to business processes lies in the absence of relationships between agents and their commitments, which instead represents the core of agent-oriented representations. That implies the inability to find agents/services with specific capabilities, invoke them, and enable their interoperability. Notably, benefits of process-oriented representations, such as the facilitation mechanisms, to the search and selection of process models are also offered by the agent-oriented ones, as long as they are sufficiently general, albeit flexible.

2.5. E-commerce and the Semantic Web

There are relevant works on the use of Semantic Web technologies on e-commerce. In [74], the authors identify six challenges facing the e-commerce ecosystem: inability of existing product data for automated processing; diffuse lack of interoperability of product data; insufficient use of unique product identifiers; heterogeneity of product category taxonomies; incomplete, inconsistent or outdated product descriptions; weakness of current product recommendation systems. Then, they propose a technological stack, based on the Semantic Web, to support the creation of intelligent e-commerce applications. In [37], a mediation framework for e-commerce based applications leveraging a Semantic Web ontology for electronic services is presented, while the authors of [33] propose a scalable approach that automatically selects and extracts from semi-structured texts in business contexts relevant information published as RDF graphs. The authors of [63] present a comprehensive survey on ontologies for supply chains, pointing out the lack of operational semantics. In [59], this weakness is overcome by the proposed ontology, which aims at describing the supply chain processes where IoT devices are involved. However, such ontology does not account for more general features such as blockchain networks and people.

Creating shared or, at least, interoperable vocabularies for product descriptions has been recognized as a crucial task for e-commerce [94]. In [106], it is suggested that semantic vocabularies enable the implementation of semantic search engines [65] to find out items in a very specific range. In the last decades, several industrial Products and Services Categorization Standards (in short PSCS) have been proposed and adopted.2

The proliferation of PSCS supports the observation that e-commerce stakeholders have not reached a consensus on product and service description representation systems, and this forms an obstacle for the interoperability of applications following different standards. Remarkably, as proposed in [36], Semantic Web technologies may help to overcome this issue by enabling Ontological Mapping between different systems. Worth of mentioning, the schema.org [85,112], a general purpose vocabulary largely used in tagging web page contents, allows for the enrichment of web pages with machine-readable information in the RDFa [110], JSON-LD [111] or HTML Microdata formats, and is commonly adopted by search engines for probing commercial websites.

GoodRelations is an OWL vocabulary to describe offerings of tangible goods and commodity services. Its descriptive features are broad enough to cover both product and service instance descriptions. In addition, a wide range of offerings and pricing can be modelled via GoodRelations. Offerings described using the GoodRelations vocabulary are recognized by major search engines such as Google, Yahoo, and Bing. Also, well-known content management tools, such as Joomla!, osCommerce, and Drupal, support the publication of data with the GoodRelations ontology. GoodRelations is demonstrated in [3] and integrated with schema.org. Of course, other trading activities beyond offerings are important and, for example, ownership information may be used for personalized recommendations, as shown in [101]. Notably, GoodRelations does not cover how negotiations are carried out and how offerings or assets are related with tokens managed on the blockchain.

Only recently, researchers have focused on conjoining the blockchain with ontologies [19,48]. One of the areas of investigation has concentrated in developing a characterization of blockchain concepts and technologies through ontologies. In [44], a theoretical contribution looking at the blockchain through an ontological approach has been provided. In [88], the authors propose a blockchain framework for SWoT contexts settled as a Service-Oriented Architecture (SOA), where nodes can exploit smart contracts for registration, discovery, and selection of annotated services and resources. In [77], a preliminary work on capturing the semantics of the Fast Healthcare Interoperability Resources (FHIR) standard vocabulary in smart contracts is presented.

Other works aim at representing ontologies within a blockchain context. In [75], ontologies are used as a common data format for blockchain-based applications such as the proposed provenance traceability ontology, but are limited to describe implementation aspects of the blockchain.

The Blockchain Ontology with Dynamic Extensibility (BLONDiE) project [104] provides a comprehensive vocabulary that covers the structure of different components (wallets, transactions blocks, accounts, etc.) of blockchain platforms (Bitcoin and Ethereum) and that can be easily extended to other alternative systems. In [5], the authors propose a semantic interpretation of smart contracts as services bases on the ontology Ethon [86]. More debate can be found in [52] through a discussion on the blockchain as applied for tracking the provenance of knowledge, for establishing delegation schemes and for ensuring the existence of patterns in formal conceptualizations using zero-knowledge proofs. We contend that the main limitation of these approaches is the poor semantic description of smart contracts, and this precludes the discovery of unknown smart contracts and of the operations that they fulfilled during their life-span. These, however, would be extremely relevant in the area of e-commerce.

It is noteworthy to mention that blockchains are adopted as a means to achieve traceability and transparency of assets [95] also in supply chain management [46]. Moreover, Semantic Web ontologies support pragmatic traceability in supply chains [2]. Therefore, conjoining blockchains and Semantic Web enhances the methodologies and tools for traceability and auditability and would be valuable, for example, to trace both tangible and intangible assets over their supply chains (including fair market values, litigation, and insolvency proceedings and financial reporting). However, the work presented in this article focuses on the representation choices involving the representation of Ethereum smart contracts and tokens and on how they are used as a means for trading the underlying assets through public announcements.

In [21], the OASIS ontology is extended with ontological smart contracts (in short, OSCs) and conditionals. OSCs are intended as ontological agreements among agents to allow one to establish responsibilities and authorizations. Conditionals are used a) to restrict and limit agent interactions, b) to define activation mechanisms that trigger agent actions, and c) to define constraints and contract terms on OSCs. Conditionals and OSCs are applied to add ontological capabilities to digital public ledgers such as the blockchain and the smart contracts implemented on it. The architecture of a framework based on OSCs that exploits the Ethereum blockchain and the Interplanetary File System is also sketched. In [8], the definition of digital contracts is extended over the blockchain to include smart contracts, intended as programs running on the blockchain and interpreted as digital agents in the OASIS fashion, including their operational semantics and tokens exchanged through them. The same approach is part of the work presented in this paper, even though it presents structural differences on how blockchains are modelled. Finally, application of OASIS in the context of the Hyperledger Fabric blockchain has been devised [31].

3.1. The OASIS ontology

We present in detail the main features of the OASIS ontology that are adopted to build the core of the ontological stack related to the semantic representation of the agents and their commitments to the e-commerce based on Ethereum.

The Ontology for Agents, Systems and Integration of Services (in short, OASIS) is a foundational OWL 2 ontology that applies the behaviouristic approach to represent multi-agent systems. The behaviouristic approach is an abstraction of an operational semantics based on the definition of an agent behaviour through its decomposition in the essential mental states of the agent, namely, goals, and tasks that are sought to be accomplished. While goals depict the long term desires of the agent, tasks represent the atomic operations that it is able to physically carry out. Alongside the representation of the agent mental states, the behaviouristic approach takes care of how behaviors are invoked and put in practice by agents, thus defining agents’ plans and commitments. Whereas plans represent the agent’s desire of seeing a behavior materialize, commitments represent such a materialization.

Hence, OASIS characterizes 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. Additionally, OASIS models information concerning executions and assignments of tasks, restrictions on them and constraints used to establish responsibilities and authorizations among agents.

OASIS models agents by representing their behaviours, which are publicly exposed. Thanks to public behaviours, agents report the set and type of operations that they are able to perform, including the type of data required to execute them, possibly with the expected output.

Representation of agents and their interactions in OASIS is carried out along three main steps:

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 for agents whose behaviour consists in producing and selling products to buyers, and it may be implemented by an apple seller that produces and sells batches of green apples. Moreover, templates are useful for helping developers define the most suitable representations for their agents.

The second step consists of representing the agent behaviors either by specifying a shared template or by defining it from scratch. To describe an abstract agent’s capabilities to perform actions, an agent template comprises three main elements, namely behaviours, goals, and tasks. Agent tasks, in 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 perform in practice.

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, representing the agent commitments, describe the actions performed by agents and associated with behaviours. Plan executions are made up of goal executions, representing the execution of agent goals. Goal executions in their turn are constituted by task executions that represent the executions of agent tasks.

The association is carried on by entailing a description of the performed action to 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 describe the entities of the OASIS ontology that concern the representation of agents and their commitments that are used by the ontological stack. Figure 1 depicts the classes and properties provided by OASIS that are relevant for the goals of the ontological stack.

OPEN IN VIEWER

Fig. 1.

Main classes and properties of OASIS.

In OASIS, agent templates are defined according to the UML diagram in Fig. 2. To describe abstract agent capabilities of performing actions, an agent template comprises three main elements, namely behaviours, goals, and tasks. Agent tasks, in turn, describe atomic operations that agents may perform, including possibly input and output parameters required to accomplish the actions. The core of agent representation, indeed, revolves around the description of atomic operations introduced by the instances of the class TaskDescription that characterizes agent commitments. Instances of the class TaskDescription are related to five elements that identify the operation:

OPEN IN VIEWER

Fig. 2.

UML diagram representing OASIS agent templates.

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

Analogously, concrete agents are represented according to the UML diagram in Fig. 3, which reflects the modelling pattern adopted for the representation of agent behaviour templates described above, but introducing the following differences:

Concrete agents are possibly connected with the agent template from which they are drawn. In order to describe the fact that concrete agents inherit their behaviours from a common and shared agent template, the following associations are introduced:

Analogous object-properties are defined for the behaviour and goal of the agent.

OPEN IN VIEWER

Fig. 3.

UML diagram representing OASIS concrete agents.

Agent actions entail the description of the concrete behaviour of the agent from which they are drawn. As depicted in Fig. 4, an agent action is primarily introduced by an instance of the class PlanExecution, representing the agent commitment. Plan executions comprise goal executions, represented by instances of the class GoalExecution, whereas, in turn, goal executions provide task executions (instances of the class TaskExecution) embedding the following elements:

In contrast to 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:

OPEN IN VIEWER

Fig. 4.

UML diagram representing OASIS agent actions.

GoodRelations is an OWL vocabulary describing offerings about products and services, involved legal entities, prices, selling terms, and conditions.

The core class of the GoodRelation vocabulary (see Fig. 5) allows one to represent offerings. An offering is an agent’s announcement concerning the provision of a certain business function (one of “sell”, “lease out”, “maintain”, “repair”, “provide service”, “dispose”, and “buy”) for a certain product or service instance to a particular target audience and under specific commercial conditions.

OPEN IN VIEWER

Fig. 5.

UML diagram representing the GoodRelations ontology.

A business entity can create or seek for offerings providing goods and terms under particular conditions.

An offering can either refer to

An offering may be linked to multiple price specifications that specify alternative prices for non-overlapping sets of conditions that can be characterized by:

It is possible to specify the availability of an offering and the related accepted payment methods, possibly combined with additional payment charge specifications, by means of several methods: in advance or after delivery, by credit card, cash or bank transfer.

The delivery methods associated with an offering are standardized procedures for providing the product or service, with the destination of fulfillment chosen by the customer. They can possibly be coupled with delivery charge specifications. Also, the product or service may be available at some physical location (a shop, an office, etc.) characterized by a geographical position and a set of opening hour specifications for various days of the week.

Finally, offerings may be provided with information about warranty on goods.

The BLONDiE ontology aims to provide a simple representation of some of the most widespread blockchains, namely Bitcoin, Ethereum, and Hyperledger Fabric, and can potentially cover every blockchain available by means of suitable extensions. The ontology, depicted in the UML diagram in Fig. 6, tries to answer to at least the following main competency questions:

OPEN IN VIEWER

Fig. 6.

UML diagram representing the BLONDiE ontology.

The domain covered by the ontology includes the structural information of Bitcoin, Ethereum, and Hyperledger Fabric blockchains, as expressed in the official documentations, and also the following elements:

4.1. The OC-Found ontology

The OC-Found ontology provides the semantic foundation required to represent the main actors and their actions of the blockchain-based commerce. The constructed model is also suitable for many other domains that require the characterization of agents, agent commitments, and supply chains, such as health-care, public services, and industry.

In addition to those provided by BLONDiE, the OC-Found ontology answers at least to the following competency questions (CF1-CF7), that describe classical situations about how the core of the ontology could be leveraged by final users.

To achieve the objective, OC-Found applies the behaviouristic approach pursued by OASIS for representing agents to the commercial domain by extending the notions of agent behaviour template, agent behaviour, and agent action with the semantic representation of digital identities, supply chains, and quality valuation mechanisms.

In this section, we describe the ontological core of OC-Found and how it extends OASIS to reach the proposed goals.

The main classes and properties introduced by OC-Found to model supply chains and digital identities associated with agents are depicted in Fig. 7, which has been obtained by means of the editor Protégé [82]. Entities having the prefix oasis are those imported from the OASIS ontology, whereas the remaining ones are defined in OC-Found.

OPEN IN VIEWER

Fig. 7.

Hierarchies of classes (on the left) and object-properties (on the right) in the OC-Found ontology.

In OC-Found, agents are associated with digital identities, represented by instances of the class DigitalIdentity (subclass of the OASIS class DescriptionObject) through the object-property hasDigitalIdentity (subproperty of the OASIS property owns); the class hierarchy of DigitalIdentity can be expanded in order to describe different types of digital identities such as public keys. Additionally, agents that are also legal entities are presented by instances of the class LegalEntities, subclass of the OASIS class Agent.

In OC-Found, the life-cycle of assets is described by means of supply chains. These encompass all of those activities associated with moving goods from the raw-materials stage through to the end user [76]. Hence, more in general, supply chains concern all the activities describing the life-cycle of digital or physical resources from sourcing to consumption. By leveraging the above definition, OC-Found models supply chains as instances of the class SupplyChainManagement (subclass of the OASIS class Activity) encompassing all the activities describing the life-cycle of the involved resources and introduced by instances of one of the subclasses of the class SupplyChainActivity. Each subclass describes one of the phases of the resource’s life-cycle. Each phase, in its turn, is connected with the behaviour of the agent responsible for its realization. Specifically, OC-Found currently includes the following subclasses of the class SupplyChainActivity:

Resources may express many alternative supply chains that, in turn, may also specify one or more supply chain activities, depending on the specific life-cycle of the resource. Each supply chain activity, instead, must be related with the agent’s behaviour responsible for its execution. The classes SupplyChainManagement and SupplyChainActivity are also defined in OC-Found as subclasses of the class SupplyChainThing, encompassing all the entities related with supply chains.

Usage of OC-Found classes and properties are depicted in Fig. 8, where the prefix ocfound is used for the namespace of the OC-Found ontology, properties are illustrated together with the related super-properties defined in OASIS, whereas OC-Found entities are reported in bold.

OPEN IN VIEWER

Fig. 8.

UML diagram representing the OC-Found ontology.

Resources are related with instances of the class SupplyChainManagement for each supply chain introduced by means of the object-property hasSupplyChainManagement, subproperty of the OASIS property isRelatedWithActivity. In turn, instances of the class SupplyChainManagement are connected with one or more instances of the subclasses of the class SupplyChainActivity, depending on the type of the activities of the resource’s life-cycle to be described, through the object-property supplyChainActivityImplementedBy (subproperty of the OASIS property implementedBy). For example, the supply chain of an apple producer may be represented as depicted in Fig. 9, where classes are reported in bold and instances are reported below the related membership classes.

OPEN IN VIEWER

Fig. 9.

UML diagram exemplifying an apple producer supply chain in OC-Found.

Specifically, the example in Fig. 9 describes an apple farmer providing for his harvest of apples collected in a batch (individual appleBatch2532) a supply chain (individual appleSupplyChain) consisting of four supply chain activities:

If dependency relationships among supply chain activities are required, the object-property of OASISdependsOn can be used to connect an activity with the one it depends on. Hence, thanks to the description provided by OC-Found, the supply chain of the apple batch produced by the farmer is completely described, and the responsibilities of the agent entrusted for the activities that make up the supply chain are clearly defined.

In order to build an ontological trust management system based on participants experiences and feedbacks, OC-Found models the quality valuation processes performed on the resource either by professional quality valuer agents or by customers. With this aim, OC-Found provides the classes illustrated in Fig. 10 (entities that are newly introduced in OC-Found are reported in bold).

OPEN IN VIEWER

Fig. 10.

UML diagram representing OC-Found quality valuation process.

Agents performing professional quality valuations are defined as instances of the OC-Found class QualityValuerAgent. When quality valuers perform actions associated with a quality valuer behaviour, the agent is connected to the activity related with the execution of the quality valuation activity, defined as instance of the class QualityValuationActivity) by means of the object-property performsQualityValuation (subproperty of the OASIS property isRelatedWithActivity). In its turn, the instance of the class QualityValuationActivity is connected with a) the resource on which the valuation is performed, by means of the object-property qualityValuationPerformedOn (subproperty of the OASIS property involves) and with b) the result of the valuation, represented by an instance of the class QualityValuationResult (subclass of the OASIS class CompositeValue) by means of the object-property hasQualityValuationResult (subproperty of the OASIS property hasCompositeValue). An example of valuating the apple batch is illustrated in Fig. 11, where the valuer agent agriFoodValuer performs a valuation activity on the apple batch appleBatch2532, assigning a total result of 5.

OPEN IN VIEWER

Fig. 11.

UML diagram exemplifying the quality valuation on apple batch 2563 in OC-Found.

We first show the structure of GoodRelations and how some of its concepts are extended in OC-Commerce. The OC-Commerce ontology5

OC-Commerce extends the definition of offerings introduced in GoodRelations by means of OC-Found supply chains and agents responsible for their realization, including agent actions performed to publish, reject, accept, and close offerings. OC-Commerce is also an extension of GoodRelations for the most common commercial activities that are relevant to the e-commerce realm, which would build a blockchain-based framework to directly connect seller and buyer, but that are carried out by different enterprises such as eBay, Vinted, Eprice, ans so on. Specifically, OC-Commerce provides models to describe bargaining activities, auctions, modifications of offerings, valuations, and price determination mechanisms. For this reason, OC-Commerce foresees at least the following competency questions:

The classes and object-properties introduced by OC-Commerce and the related mapping into GoodRelations are illustrated in Figs 12 and 13, respectively. The prefix gr is used to refer to the GoodRelations namespace.

OPEN IN VIEWER

Fig. 12.

Hierarchies of classes in the OC-Commerce ontology.

OPEN IN VIEWER

Fig. 13.

Hierarchies of object-properties in the OC-Commerce ontology.

In the same way as GoodRelations, OC-Commerce revolves around the concept of “offering”, which represents the public announcement to publish or seek for a certain asset with specific supply chains and at certain conditions. In order to publish offerings, participant should expose a suitable behaviour involving the action publish and the task object related with a general instance of the OC-Commerce class Offering (subclass of the GoodRelations class Offering), as in the schema of Fig. 14. In an analogous way, agents enabled to request, modify, retract, close, accept, and reject offerings should manifest a suitable behaviour for each operation, where the related action is:

Before publishing an offering, the traded asset should be available beforehand through a specific agent action that releases the asset, as described in Section 4.1. For example, an apple producer, whose behaviour is depicted in Fig. 15, deploys a new asset of apples, namely batch 2563, and makes it available for trading, as reported in Fig. 16.

OPEN IN VIEWER

Fig. 14.

UML diagram representing OC-Commerce offering publishing.

OPEN IN VIEWER

Fig. 15.

UML diagram exemplifying the production of apple batch 2563 in the OC-Commerce ontology.

OPEN IN VIEWER

Fig. 16.

UML diagram exemplifying the publication of apple batch 2563 in the OC-Commerce ontology.

As a second step, the agent delegated to make the offering available publishes an action associated with the behaviour responsible for publishing offerings. In the case of the apple producer, a new offering concerning the batch 2563 should be published, as reported in Fig. 17.

OPEN IN VIEWER

Fig. 17.

UML diagram exemplifying the publication of an offering for apple batch 2563 in the OC-Commerce ontology.

The agent responsible for the action of publishing an offering can also be connected with the published offering by means of the object-property publishesOffering, subproperty of the GoodRelations property offers. In turn, offerings must be connected both with the traded asset and with the related supply chain. In OC-Commerce, such relationships are modelled as depicted in the UML diagram in Fig. 18.

OPEN IN VIEWER

Fig. 18.

UML diagram representing OC-Commerce offerings.

There are currently four types of offerings in OC-Commerce:

Moreover, offerings are also classified as

Offerings are connected with the traded assets (instances of the class CommercialAsset, subclass of the OASIS class Asset) by means of the object-property isOfferingAbout (subproperty of the GoodRelations property includes), whereas supply chains are introduced by means of the object-property hasSupplyChainManagement, as described in Section 4.1.

In OC-Commerce, prices are conceived as the result of some price determination activities carried out either by the publisher of the offering or by suitable agents delegated to compute the value of specific assets (see Section 4.1). The activity of determining the price of an offering is represented by instances of the class PriceDeterminationActivity, which are connected with a) the offering by means of the object-property priceDeterminationPerformedOn and with b) the computed price (instance of the class Price) by means of the object-property hasPriceValue. In its turn, the instance of the class Price is related with the value of the price introduced as a float by means of the GoodRelations data-property hasCurrencyValue, where the selected currency is introduced as a string by means of the GoodRelations data-property hasCurrency.

Offerings change their status when they are accepted, closed, rejected or modified. An offering is also defined as an instance of the following classes:

Our example continues with the full details of the offering for the asset batch 2563 of apples, as illustrated in Fig. 19. The offering involves the batch 2563, which is sold at the price of 1000 euros. The supply chain related with the offering is the one illustrated in Fig. 9 of Section 4.1. Then, the user Bob accepts the offering by performing the action depicted in Fig. 20 and, as a consequence, the publisher closes the offering. Subsequently, the two agents indicated in the supply chain perform the indicated actions, namely by registering the payment and shipping the product, respectively. The payment action, performed by the Paypal agent, is illustrated in Fig. 21. The action consists in transferring the established quantity of the selected currency from Bob’s account to the apple producer’s account, in order to pay for the apple batch in the offering. As a result of the action, a payment receipt is emitted. At this point, the Fedex agent ships the selected product, as described in Fig. 22. The user destination is represented by an instance of the GeoNames ontology [108], and a suitable receipt is generated to track the shipment. Additionally, the user Bob can assess his commercial transaction experience by valuating the quality of both the offering and the involved agents, by committing himself to an action as the one described in Section 4.1.

OPEN IN VIEWER

Fig. 19.

UML diagram exemplifying the full details of an offering for apple batch 2563 in the OC-Commerce ontology.

OPEN IN VIEWER

Fig. 20.

UML diagram exemplifying the offering acceptance for apple batch 2563 in the OC-Commerce ontology.

OPEN IN VIEWER

Fig. 21.

UML diagram exemplifying the payment acceptance for apple batch 2563 in the OC-Commerce ontology.

Where allowed, offerings can be modified when some features, such as supply chains, have changed for any reason. A modified offering gets deprecated and replaced with a new offering endowing both all the features of the deprecated offering that are still valid and the features for which the new offering has been introduced. The UML diagram for offering modification is illustrated in Fig. 23.

When offerings are replaced by new ones, the deprecated offerings are defined as instances of the class DeprecatedOfferings and must not be involved in any new commercial activity. Instead, a new offering satisfying all the required features takes the place of the deprecated one. The deprecated offering is connected with the new offering by means of the object-property isOfferingModifiedIn. Moreover, a new modification activity needs to be introduced to possibly motivate the modification purposes, for example by specifying the agent that performed the action of modification. Modification activities are introduced as instances of the class OfferingModificationActivity connecting the abandoned offering by means of the object-property hasOfferingModificationSource and the new offering by means of the object-property hasOfferingModificationResult.

The OC-Commerce ontology provides representation means to describe auctions. Auctions are conceived as activities involving agents that propose bids on a particular type of offering, namely the instances of the class Auction. As any other type of offerings, auctions are characterized by three elements, that is, the supply chain, the traded asset, and the price, the latter conceived as the starting price of the auction. Users enabled to join the auction introduce a new seek action pipeline involving a new offering that represents the user bid. The bid is a general offering connected to the instance of the class Auction by means of the object-property isBidOnOffering, as illustrated in Fig. 24, in a way analogous as in counter-offerings.

OPEN IN VIEWER

Fig. 22.

UML diagram exemplifying the shipment confirmation for apple batch 2563 in the OC-Commerce ontology.

OPEN IN VIEWER

Fig. 23.

UML diagram representing OC-Commerce offering modification.

OPEN IN VIEWER

Fig. 24.

UML diagram representing OC-Commerce auctions.

The OC-Ethereum ontology extends with smart contracts and tokens the semantic model describing the essential elements of the Ethereum blockchain provided by the BLONDiE [105] ontology. OC-Ethereum conjoins the BLONDiE ontology with the OC-Commerce to provide commercial activities, in particular those based on the trading of NFTs carried out through the Ethereum blockchain, with the operational semantics as demanded by the behaviouristic approach.

Hence, OC-Ethereum answers at least to the following competency questions:

To achieve the expected results, OC-Ethereum defines the classes and properties depicted in Figs 25 and 26, respectively.

OPEN IN VIEWER

Fig. 25.

Hierarchies of classes in the OC-Ethereum ontology.

OPEN IN VIEWER

Fig. 26.

Hierarchies of object-properties (on the left) and of data-properties (on the right) in the OC-Ethereum ontology.

OC-Ethereum mainly adopts the BLONDiE definitions of EthereumBlock, EthereumPayload, EthereumTransaction, and related subclasses, to describe the Ethereum blockchain entities securing smart contracts, tokens and operations leveraged to carry out commercial activities. Moreover, OC-Ethereum extends the BLONDiE model of Ethereum transactions by including an ontological representation of smart contracts and their operations published on the Ethereum blockchain, in particular of those related with the management of tokens, as depicted in Fig. 27. As a first step, OC-Ethereum connects a) transactions instantiating Ethereum smart contracts, as defined in BLONDiE with the related OASIS representation of smart contracts as agents running on the blockchain, and b) standard Ethereum transactions concerning smart contracts with the related OASIS representation of agent actions.

To provide BLONDiE with the representation of smart contracts and related operations, OC-Ethereum connects instances of the BLONDiE class NormalEthereumTransaction and MessageCallEthereumTransaction with instances of the OC-Ethereum class EthereumSmartContractExecution (subclass of the OASIS class PlanExecution) by means of the object-property introducesEthereumSmartContractExecution, in order to associate the transactions that secured smart contract operations with the semantic representation of the actions performed. Then, OC-Ethereum connects instances of the BLONDiE class ContractCreationEthereumTransaction with instances of the OC-Ethereum class ocether:EthereumSmartContractAgent (subclass of the OASIS class Agent) by means of the object-property introducesEthereumSmartContractAgent, thus associating the transactions that instantiate smart contracts with the ontological representation of the smart contracts in terms of OASIS agents.

OPEN IN VIEWER

Fig. 27.

UML diagram representing OC-Ethereum smart contracts.

Specifically, OC-Found identifies five types of Ethereum smart contract agents, suitably represented by the following classes:

For example, the smart contract generated by our apple producer is represented by means of the fragment in Fig. 28.

OPEN IN VIEWER

Fig. 28.

UML diagram exemplifying an apple producer’s smart contract in the OC-Ethereum ontology.

The block and the transaction securing the apple producer smart contracts are introduced by means of the instances of the BLONDiE classes EthereumBlock and EthereumTransaction, respectively. The instances of the former class provide, among others, information concerning the block number (by means of the data-property heightBlock) and the miner of the block (by means of the data-property minerBlock), whereas the instances of the latter class provide information about the signed transactions, such as the transaction hash (by means of the data-property to) and the smart contract address (by means of the data-property recipientEthereumTransaction). Finally, the transaction, as modelled in BLONDiE, is provided with the ontological description of the smart contract agent by means of the OC-Ethereum object-property introducesEthereumSmartContractAgent. In the example considered, the entity appleProducerSmartContractAgent represents the smart contract of the apple producer.

In addition, the OC-Ethereum ontology extends BLONDiE by describing tokens generated and exchanged through the Ethereum blockchain, in particular for commercial purposes. As illustrated in Fig. 29, OC-Ethereum identifies four main types of tokens:

OPEN IN VIEWER

Fig. 29.

UML diagram representing OC-Ethereum tokens.

The four above-mentioned classes are defined as subclasses of the class EthereumToken. Additionally, tokens that have been definitively destroyed are also instances of the class BurnedEthereumToken.

In OC-Ethereum, commercial assets (instances of the OC-Commerce class CommercialAsset) that are uniquely associated with Ethereum tokens are related with instances of the class EthereumToken by means of the object-property isDescribedByEthereumToken. Tokens carry two types of features [57], 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 OC-Ethereum class EthereumTokenPerdurantFeatures (subclass of the OASIS class PerdurantFeature) by means of the object-property hasEthereumTokenPerdurantFeature. The most notable subclass of PerdurantFeature is the class EthereumWalletOwnerPerdurantFeature, which describes the wallet of the token’s owner (by means of the data-properties isInTheWalletOf, having as range XSD:string). When the perdurant features of a token are modified by the smart contract managing it, they become deprecated and replaced by a new set of features by means of a modification activity. Such new features are introduced by a fresh instance of the class PerdurantFeature, as illustrated in Fig. 30.

OPEN IN VIEWER

Fig. 30.

UML diagram representing OC-Ethereum token modification.

In OC-Ethereum, the modification of tokens is allowed only if it involves perdurant features; hence, endurant features cannot be modified. Perdurant features may be replaced with other perdurant features by introducing an instance of the class EthereumTokenFeatureModificationActivity, which is connected with:

Moreover, the modified perdurant feature is connected as usual 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.

An example of representing tokens in OC-Ethereum is illustrated in Fig. 31, which shows a token emitted by the apple producer’s smart contract.

OPEN IN VIEWER

Fig. 31.

UML diagram exemplifying the publication of the token for apple batch 2563 in the OC-Ethereum ontology.

The token appleBatch2563Token, with identification code 12, is associated with the apple batch 2563. The token is also associated with a perdurant feature describing the current owner’s wallet. The perdurant feature is introduced by the entity appleBatch2563TokenWF01, instance of the class EthereumWalletOwnerPerdurantFeature and connected with the string representing the wallet’s owner by means of the data-property isInTheWalletOf.

In this section, we introduce the evaluation methods and the results obtained for the OC-Found ontology. We first present the ontological metrics and then the SPARQL queries implementing the identified competency questions.

5.1.2. SPARQL queries

We are ready to introduce the SPARQL queries that implement the competency questions CF1-CF7 (see Section 4.1). Specifically,

Which are the participants currently available (including the associated digital identities and operations they can perform)?

The answer to CF1 is entailed by the SPARQL query QF1.

OPEN IN VIEWER

Query QF1

Which are the agents commitments and type of actions performed during their entire lifespan?

The answer to CF2 is entailed by the SPARQL query QF2.

OPEN IN VIEWER Query QF2

Given the resource resource, which is, if any, the supply chain of resource?

The answer to CF3 is entailed by the SPARQL query QF3.

OPEN IN VIEWER Query QF3

Given the resource resource, how the supply chain of resource is constituted?

The answer to CF4 is entailed by the SPARQL query QF4.

OPEN IN VIEWER Query QF4

Given the resource resource, which are the agents responsible for resource’s supply chain activities?

The answer to CF5 is entailed by the SPARQL query QF5.

OPEN IN VIEWER Query QF5

Given the resource resource, which are the valuations (including the valuer agents) performed on resource?

The answer to CF6 is entailed by the SPARQL query QF6.

OPEN IN VIEWER Query QF6

Given the resource resource, which is the average score of valuation of resource and how many valuations are there?

The answer to CF7 is entailed by SPARQL query QF7.

OPEN IN VIEWER Query QF7 5.2. Evaluation of the OC-Commerce ontology

We begin by introducing the evaluation methods and the related results for the OC-Commerce ontology. We first present the structural and ontological metrics and then the SPARQL queries that implement the provided competency questions.

5.2.1. Metrics

In this section we discuss the ontological metrics computed on the OC-Commerce ontology. Consistency of the OC-Commerce ontology was checked by the reasoners Pellet, HermiT and FaCT + + as usual. The main structural metrics computed on OC-Commerce are reported in Table 3. The metrics on the imported ontology GoodRelations are reported in the first column, whereas the root of the OC-Commerce ontology are reported in the second one.

OPEN IN VIEWER

Table 3

Structural metrics on OC-Commerce

Metric	GoodRelations import	Root of OC-Commerce
Axiom count	1188	113
Logical axiom count	450	61
Declaration axiom count	196	29
Class count	38	30
Object property count	53	18
Subclass axiom count	19	25
Sub-object-property axiom count	4	15
Object property domain axiom count	50	10
Object property range axiom count	50	10
Annotation assertion	0	23

The difference of dimension between OC-Commerce and GoodRelations is the result of their inheritance relationship, since OC-Commerce requires many entities provided by GoodRelations and by OC-Found. The ontological metrics computed by OntoQA on OC-Commerce are reported in Table 4 and compared with GoodRelations.

OPEN IN VIEWER

Table 4

Ontological metrics on OC-Commerce

Evaluation criteria	GoodRelations import	Root of OC-Commerce	Delta %
Relationship richness	84.67%	40.81%	−107.47%
Inheritance richness	2.11%	2.07%	−2.85%
Tree balance	0.98%	1.35%	+27.40%
Attribute richness	0.5%	0.40%	−19.99%
Class richness	83.76%	6.25%	−1240%

The imported ontology GoodRelations is reported in the first column, whereas the root of the OC-Commerce ontology is reported in the second one, and the difference in percentage among the two ontologies is reported in the last column.

Relationship richness of OC-Commerce reports a lower value than GoodRelations because many entities are inherited and extended, and therefore they cannot be considered in the evaluation of the metric. Thus, the value still indicates a good balancing between description of properties and class hierarchies, with a propensity for the former. The difference of inheritance richness between OC-Commerce and GoodRelations is notable, as OC-Commerce’s class hierarchies such as Offerings and PriceDeterminationActivity have very different levels of depth. Tree balance of OC-Commerce is higher than the one computed on GoodRelations, since classes such as Offering are deeply specialized in OC-Commerce in a vertical way. GoodRelations provides a higher value of attribute richness due to the thorough characterization of some classes, such as Offering. These classes are not considered in the evaluation of OC-Commerce, as they are imported, and therefore they do not belong to the root of the ontology. Class richness of OC-Commerce remains low, since data are not present within the ontology, whereas GoodRelations introduces many individuals used to apply the punning technique.

OC-Commerce may also be usefully compared with OC-Found. Relationship richness of OC-Commerce reports a lower value than OC-Found (the latter is 57.14%) due to the inheritance relationship between the two ontologies. The value for the inheritance richness is close to the one of OC-Found, as they are vertical ontologies. The tree balance of OC-Commerce, as expected, is also higher than the one computed on OC-Found, because some classes introduced in OC-Found are specialized in the context of digital commerce (e.g., Asset). Attribute richness and class richness of OC-Commerce are close to the values computed on OC-Found, confirming the verticality of the ontological stack developed at this step.

5.2.2. SPARQL queries

We now discuss the SPARQL queries that implement the competency questions CC1-CC3 (see Section 4.2) defined for the OC-Commerce ontology. Specifically, the competency questions are implemented as follows.

Which are the available offerings (including related details)?

The answer to CC1 is entailed by the SPARQL query QC1.

OPEN IN VIEWER

Query QC1

Given an offering offering, which is the supply chain related with offering?

The answer to CC2 is entailed by the SPARQL query QC2.

OPEN IN VIEWER Query QC2

Which are the accepted offerings?

Answers to competency question CC3 are entailed by the SPARQL query QC3.

OPEN IN VIEWER Query QC3 5.3. Evaluation of the OC-Ethereum ontology

Next, we introduce the evaluation methods and related results obtained for the OC-Ethereum ontology. We first present the ontological metrics and then the implementation of the competency questions in the SPARQL query language.

5.3.1. Metrics

As in the case of OC-Found and OC-Commerce, consistency check has been carried out by the reasoners Pellet, HermiT, and FaCT + + . Table 5 reports the structural metrics computed on the root of OC-Ethereum, hence excluding the values inherited from OC-Commerce, OC-Found, and BLONDiE, in the first column. In the second column, Table 5 reports the values obtained from the imported ontology BLONDiE.

OPEN IN VIEWER

Table 5

Structural metrics on OC-Ethereum

Metric	BLONDiE import	Root of OC-Ethereum
Axiom count	323	149
Logical axiom count	210	65
Declaration axiom count	98	58
Class count	23	45
Object property count	11	11
Data property count	64	3
Subclass axiom count	16	28
Sub-object-property axiom count	0	7
Object property domain axiom count	11	7
Object property range axiom count	11	8
Data property domain axiom count	64	2
Data property range axiom count	64	2
Annotation assertion	15	26

We recall that BLONDiE provides the description of three blockchains, namely Ethereum, Hyperledger Fabric, and Bitcoin, whereas OC-Ethereum is focused on the former. Thus, there is a notable difference in size between the two ontologies, even though OC-Ethereum provides more classes because of the hierarchies introduced to describe smart contracts and tokens.

The ontological metrics computed by OntoQA on OC-Ethereum are reported in Table 6 and compared with those obtained from BLONDiE. A comparison between the results obtained on OC-Found and on OC-Commerce is in order.

OPEN IN VIEWER

Table 6

Ontological metrics on OC-Ethereum

Evaluation criteria	BLONDiE import	Root of OC-Ethereum	Delta %
Relationship richness	82.41%	29.16%	−182.61%
Inheritance richness	2.28%	1.36%	−67.64%
Tree balance	0.88%	0.83%	−6.02%
Attribute richness	0.30%	0.59%	+49.15%
Class richness	0	9.09%	+INF

With respect to BLONDiE, the difference of relationship richness in OC-Ethereum is notable because BLONDiE makes large use of data-properties to describe the constitutional elements of the three blockchains introduced. BLONDiE reports a higher inheritance richness with respect to OC-Ethereum, because BLONDiE covers a larger domain. Moreover, the tree balance of BLONDiE is also higher than the one of OC-Ethereum because OC-Ethereum inherits many classes and properties that are not included in the computation of the metric. Class richness of OC-Ethereum remains low (9.09%), as it contains just few individuals, whereas BLONDie records a 0%, since it does not include any individual. Finally, we can appreciate a higher attribute richness in OC-Ethereum with respect to BLONDiE, since smart contracts and tokens are described in more details.

A comparison between OC-Ethereum and the ontologies on the upper layers of the stack, namely OC-Found and OC-Commerce, follows. Relationship richness of OC-Ethereum is close to the value computed on OC-Commerce and OC-Found (that are 40.81% and 57.14%, respectively) confirming that the ontology provides a sufficient balancing between descriptions of properties and class hierarchies. Inheritance and attribute richness are close to those calculated from OC-Commerce and OC-Found, confirming the vertical nature of OC-Ethereum, as also proved by the tree balance value (0.83%). The tree balance of OC-Ethereum, in particular, is also lower than the one computed on OC-Commerce and OC-Found, due to the intrinsic difference of deepness level between some class hierarchies, as for example between the class hierarchy of EthereumToken and the class hierarchy of EthereumTokenPerdurantFeature. Finally, we notice similar values of class richness among the three ontologies, since only few individuals were introduced coherently with the verticality of their nature.

5.3.2. SPARQL queries

We are now ready to present the implementation of the provided competency questions CE1-CE4 (see Section 4.3) for the OC-Ethereum ontology in the SPARQL query language.

Which are the tokens minted and not destroyed, the related asset, minter, and current owner?

The answer to CE1 is entailed by the SPARQL query QE1.

OPEN IN VIEWER

Query QE1

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

The answer to CE2 is entailed by the SPARQL query QE2.

OPEN IN VIEWER Query QE2

Which are the smart contracts that emit tokens related to a specific type of asset?

The answer to CE3 is entailed by the SPARQL query QE3.

OPEN IN VIEWER Query QE3

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

The answer to CE4 is entailed by the SPARQL query QE4.

OPEN IN VIEWER Query QE4 6. A real-world case study: The iExec marketplace

In this section, we show how to apply our ontological stack to model a real world use case, namely the iExec marketplace [72]. iExec is one of the main founders of the ONTOCHAIN project and is present in the blockchain context since 2007 thanks to its first decentralized marketplace for computing assets, the iExec marketplace. The iExec marketplace connects buyers with sellers of cloud resources, building an ecosystem of decentralized and autonomous, privacy-preserving applications that are also scalable, secure, with a simplified mechanism to access services, datasets, and computing resources. The intangibility of the assets traded in the iExec marketplace and their particular supply chains are challenging for the ontological stack, since it represents a proving ground for the generality of the ontological model that have been applied to physical resources traded through common supply chains so far.

We first provide an overview of the basic concepts and functioning of the iExec marketplace, then we illustrate in detail how its main features are represented through the ontological stack.

6.1. Outlining the iExec marketplace

In the iExec marketplace, cloud resources are of three main types, namely applications, datasets, and computing resources.

Applications are standalone computer programs that can be downloaded and executed in a decentralized way by a remote machine as tasks. Tasks admit execution parameters and input files, accessing data available on the iExec marketplace as datasets, and producing files containing the results of the computation. The computational resources required to carry out application executions are provided by workers, i.e., machines on the iExec marketplace that download and execute applications (according to iExec).

Application providers, namely actors providing applications via the iExec marketplace, can define commercial conditions (in particular, usage fees) for the execution of their applications. Such commercial conditions are encoded into offerings, called app orders, available through the iExec marketplace.

The structure of app orders is described in Fig. 32, where:

app is a unique identifier for the application, namely the address of the smart contract managing the decentralized application;

appprice is the price for a single execution of the app;

volume is the maximum number of executions of the app referred in the order;

tags are application-specific additional computational requirements (for example, execution in a trusted environment);

datasetrestrict and workerpoolrestrict are optional conditions that restrict executions to specific datasets and/or to the specified worker pool;

requesterrestrict provides additional restrictions of execution requests, to be described later on;

salt is a random value to ensure order uniqueness;

sign is the EIP712 cryptographic signature [50] of the order.

OPEN IN VIEWER

Fig. 32.

Structure of the app order in the iExec marketplace.

Dataset providers, namely actors providing datasets via the iExec marketplace, publish dataset orders describing the commercial conditions regarding the datasets to be used in task executions. The mechanism of publishing dataset orders is analogous to that of app orders. Even the structure of dataset orders (see Fig. 33) is similar to the structure of app order, and hence their semantics fields can be easily deduced from the analogous app order fields.

OPEN IN VIEWER

Fig. 33.

Dataset order’s structure in the iExec marketplace.

Workers are grouped into worker pools, each one associated with a worker pool manager. Any application execution is performed by a worker pool by following the so-called Proof of Contribution Protocol (PoCo) [40,41]. In this phase, workers can possibly retrieve the dataset required for the execution. Each execution is started by the worker pool manager, which acts as scheduler during the corresponding PoCo protocol run. Further details about how worker pools perform application executions can be found in [72].

Commercial conditions about the usage of computational resources are defined and published by the worker pool manager on the iExec market place as worker pool orders (see Fig. 34). The structure of worker pool orders is similar to that of app orders, except for the fields category and trust that are not available in app orders. Specifically,

category describes the size of the computation in terms of maximum task execution time, ranging from XS for 4 minutes through to XL for 10 hours;

trust is a confidence level for accepting contributions of workers in the PoCo execution.

OPEN IN VIEWER

Fig. 34.

Worker pool order’s structure in the iExec marketplace.

Users who need to perform computation are called requester. Requesters retrieve app orders, worker pool orders and dataset orders from the iExec marketplace or from other sources. However, such orders are signed by their providers, so that they can be used in disputes. Once the requester has acquired an app order, a suitable worker pool order and, possibly, a suitable dataset order, he creates a request order (see Fig. 35) satisfying all the restrictions specified. The request order, together with the app and dataset order, is signed by the requester and submitted to the iExec clerk smart contract. The iExec clerk verifies the signatures and the satisfiability of the orders, and writes the agreement on the blockchain. The PoCo protocol is then started in order to perform the execution of the requested application (see [42] for details).

OPEN IN VIEWER

Fig. 35.

Request order’s structure in the iExec marketplace.

6.2. Representing the iExec marketplace

We now describe how the iExec marketplace can be modelled through the proposed ontological stack. The proposed encoding focuses on offerings of assets provided by the iExec marketplace to ease the discovery of services and commercial available conditions.

We first introduce novel classes, properties, and individuals that represent the structures of the iExec marketplace. For those entities, the namespace ixec: http://ontology.iex.ec is defined.

In order to represent items traded through the iExec marketplace, namely executions of iExec applications, we recall that they are characterized by:

the application that will be executed,

the worker pool, with the corresponding worker pool manager that has in charge the execution and, possibly,

a dataset used by the application.

As a first step, we notice that usages of applications and datasets in program execution are assets that can be traded: hence, they can be represented as instances of two novel subclasses of oasis:DigitalServiceAsset, namely iexec:Application and iexec:Dataset, respectively. Asset identifiers are encoded in individual IRIs of suitable naming schemes defined by the asset providers, the latter modelled as oasis:Agent instances.

As described above, executions are actually performed by worker pools. Worker pools are organizations of agents, coordinated by worker pool managers. For worker pools and worker pool managers, we introduce the classes iexec:WorkerPool and iexec:WorkerPoolManager. Each worker pool is connected to its manager via the property iexec:hasWorkerPoolManager.

As illustrated in Fig. 35, executions have also some optional fields represented by means of suitable properties, grouped as optional execution properties. Specifically, the model is designed as follows:

tag is represented by the property iexec:hasTag. Application providers and worker pools can provide ad-hoc taxonomies of tags for their purposes.

category, which indicates the maximum elapsed time for the execution, is represented by the object-property iexec:hasCategory.

trust, which is an integer value indicating a confidence level for the computation result, is represented by the iexec:hasTrust data-type property.

params, which indicates documents publicly available on the web used in the execution as input parameters for the application, is represented by the object-property iexec:hasParam.

We are ready to describe how to publish offerings to sell iExec assets through the ontological stack. For AppOrder, DatasetOrder, and WorkerPoolOrder, respectively illustrated in Figs 32, 33, and 34, we provide three subclasses of the class Offering of OC-Commerce, namely iexec:AppOffering, iexec:DatasetOffering, and iexec:WorkerPoolOffering, respectively. Converting iexec orders into corresponding and compliant individuals of the ontological stack is straightforward:

the order identifier must be included in the offering individual IRI, given a IRI scheme provided for this purpose;

prices are provided as instances of the class UnitPriceSpecification in OC-Commerce;

contents of the volume fields correspond to the notion of eligible quantity in OC-Commerce;

apprestrict, datasetrestrict, and requestrestrict are modelled by the properties hasAppRestrict, hasDatasetRestrict, and hasRequestRestrict, respectively;

optional properties are modelled with the optional execution properties introduced before;

salt and sign can be retrieved, if needed, by directly accessing the original order from which the offering was created.

Applications and datasets are particular assets that cannot be released or delivered, but can be used in the context of an execution and consumed by means of the related worker pool offerings. Thus, supply chains are required only for worker pool offerings that embed applications and datasets offerings. As a consequence, classes representing the app and dataset offerings, i.e., iexec:AppOffering and iexec:DatasetOffering, respectively, are not associated with supply chains. Instead, a supply chain is specified for the class representing the worker pool offering, namely iexec:WorkerPoolOffering, related with the former offerings, as described in Fig. 36. The supply chain of the worker pool offering will be explained later on. The worker pool offering is accepted by clients through a client’s accept behaviour that produces as output an instance of the class iexec:RequestOrder, representing a request order generated by requester from app, dataset, and worker pool offerings. The representation of a request order object through the corresponding iexec:RequestOrder individual is carried on similarly to order objects, except for the fields beneficiary and callback.

The iExec clerk smart contract verifies the request order and signs a corresponding deal, then stores it on the blockchain. For this reason, instances of the class iexec:RequestOrder are used by the iExec clerk agent as described in Fig. 37. For the iExec clerk agent, we define a suitable behaviour, namely iexec:establishDeal, admitting the following parameters:

an iexec:AppOffering, corresponding to an app order,

optionally, an iexec:DatasetOffering, corresponding to a dataset order,

an iexec:WorkerPoolOffering, corresponding to a worker pool order,

an iexec:RequestOrder, corresponding to the execution request.

The iExec clerk behaviour provides the action iexec:validate, so as to check that the set of orders passed as parameters is valid and to produce the iExec deal, represented by the class iexec:iExecDeal, as output.

The execution of tasks is actually performed by the worker pool agent by means of the iExec deal. The worker pool agent, whose behaviour is described in Fig. 38, accepts as input the iExec deal and computes the corresponding iExec task.

The iExec clerk agent and the worker pool agent are exploited to implement the supply chain of worker pool orders. Specifically, the OfferingProof supply chain of the worker pool order is related with the behaviour of the iExec clerk agent (see Fig. 37), whereas the release supply chain consists of an activity carried on by the behaviour of the worker pool agent (Fig. 38). Finally, the payment supply chain consists of an activity implementing the payment using the iExec digital currency RLC manager by the iEx.ec_Network_Token smart contract.

OPEN IN VIEWER

Fig. 36.

UML diagram representing the worker pool offering.

OPEN IN VIEWER

Fig. 37.

UML diagram representing the iExec clerk agent.

OPEN IN VIEWER

Fig. 38.

UML diagram representing the iExec worker pool agent.

7. Conclusions

Coherently with the goals stated in Section 1.1, this article sought a formal semantic representation that captures commercial activities carried out through smart contracts on the Ethereum blockchain. Not only is such a representation machine readable, but it also supports the interlinking with other out-of-chain information and, at a different level, with formal reasoning. A semantic behaviouristic conception of blockchains enables the automatic discovery of smart contracts, the interconnection of services running on different blockchains (i.e., cross-chain integration), and the integration between on-chain and off-chain services. Such features turn out to be more interesting when smart contracts are implemented as mechanisms for generating and exchanging tokens. A desirable means for token exchange systems is a precise and intelligent query mechanism capable of determining what, when, and how certain assets are generated, exchanged or destroyed. For example, intelligent systems may be aware of the activation of smart contracts for generating tokens with specific characteristics, e.g., the type of exchanged asset, the exchange of particular tokens at certain conditions, or their destruction. More in general, intelligent systems may be aware of the activation of smart contracts and of all the related activities over the blockchain.

This paper made the contributions outlined in Section 1.3. Specifically, it unfolded a behaviouristic approach for semantically representing blockchain-based e-commerce that uses the token generation and exchange mechanisms as decentralized and public proofs. Due to the need to account for both the distinctive blockchain features and for the typical commercial activities, the epistemological process results in an ontological stack of height three. The bottom ontology, called OC-Found, extends OASIS to describe digital identities and supply chains. The second ontology, that is OC-Commerce, captures the model of commercial offerings provided by GoodRelations and extends it with the representation system of agents and their commitments, also by including auctions. The stack culminates with the ontology called OC-Ethereum, which adopts the BLONDiE ontology for representing the constitutional elements of the Ethereum blockchain, but extending it with the modelling of Ethereum tokens and with the operational semantics of smart contracts.

However, the results presented in this article are not conclusive. A semantic search engine is under development, currently standing at TRL3. Other future work is clearly defined. OC-Found will include mechanisms for realizing digital identities for people and applications selected by the consortium. The OC-Commerce ontology will be extended to be independent of GoodRelations with new modelling approaches for bargaining offerings. OC-Ethereum will be extended with new blockchains and behaviours for managing non-standard and user-defined tokens. As in the same line of OC-Ethereum, novel ontologies for many other Turing-complete blockchains will be introduced in the stack together with the most widespread cryptocurrencies. Additionally, novel ontologies for other domains, such as health, industry, smart cities and government, will be part of the ontological stack. Another challenge is to enhance iExec offerings and transactions, as soon as they become available, by their semantic representations, for example in the style of the model presented in this paper. The experience we have gained thus far as well as the overall flexibility of our approach makes us optimistic on the successful pursuance of these research and development directions. Finally, representing the ontological stack through the decidable fragments of set-theory as in [20,24–30] is one of the future works.