Abstract
Electronic commerce and finance are progressively supporting and including decentralized, shared and public ledgers such as the blockchain. This is reshaping traditional commercial activities by advancing them towards Decentralized Finance (DeFi) and Commerce 3.0, thereby supporting the latter’s potential to outpace the hurdles of central authority controllers and lawgivers. The quantity and entropy of the information that must be sought and managed to become active participants in such a relentlessly evolving scenario are increasing at a steady pace. For example, that information comprises asset or service description, general rules of the game, and specific technologies involved for decentralization. Moreover, the relevant information ought to be shared among innumerable and heterogeneous stakeholders, such as producers, buyers, digital identity providers, valuation services, and shipment services, to just name a few.
A clear semantic representation of such a complex and multifaceted blockchain-based e-Commerce ecosystem would contribute dramatically to make it more usable, namely more automatically accessible to virtually anyone wanting to play the role of a stakeholder, thereby reducing programmers’ effort. However, we feel that reaching that goal still requires substantial effort in the tailoring of Semantic Web technologies, hence this article sets out on such a route and advances a stack of OWL 2 ontologies for the semantic description of decentralized e-commerce. The stack includes a number of relevant features, ranging from the applicable stakeholders through the supply chain of the offerings for an asset, up to the Ethereum blockchain, its tokens and smart contracts. Ontologies are defined by taking a behaviouristic approach to represent the various participants as agents in terms of their actions, inspired by the Theory of Agents and the related mentalistic notions. The stack is validated through appropriate metrics and SPARQL queries implementing suitable competency questions, then demonstrated through the representation of a real world use case, namely, the iExec marketplace.
Introduction
Electronic commerce (e-commerce) refers to the various activities revolving around the electronically buying or selling of products through online services [61]. The term was first used in the California’s Electronic Commerce Act, enacted in 1984. From the 1990s, e-commerce experienced a huge, continuous evolution. More recently, commerce – as well as finance – embraced the blockchain as a platform to deploy and exchange digital decentrally managed certificates, called tokens, each associating the owner of a product or service with some predetermined rights. The blockchain is a peer-to-peer public ledger maintained by a distributed network of computational nodes without the need for trusted entities [34]. Blockchains provide several benefits such as ownership, transparency, traceability, public availability, continuity, and immutability of digital assets, all in an efficient and trustless environment where censorship is not achievable. Some blockchains such as Ethereum [96] are equipped with an execution environment allowing Turing-complete programs,1
We refer to such blockchains simply as Turing-complete blockchains.
DApps have grown particularly as an exchange tool for nonfungible tokens (NFTs), which are mainly used to provide ownership rights on unique assets, such as physical or digital products and services, in general for those whose uniqueness is hard to demonstrate (for example, digital images). NFTs are used for commercial purposes, as they provide a decentralized albeit public certificate for the underlying physical or digital good and as an incontrovertible witness that a commercial transaction occurred: at the end of 2020, the market capitalization of NFTs reached the amount of 338 million U.S. dollars [93]. Together with NFTs, blockchain systems are adopted to manage other types of tokens, such as fungible and semi-fungible tokens. While non-fungible tokens are valued on the basis of their scarcity and of their distinctive properties, fungible tokens may be exchanged with another asset of the same kind: for example, fiat currencies such as US Dollars are fungible assets since one dollar can be traded with another dollar regardless of the physical or digital coin owned.
However, some fungible tokens may become unique at a certain moment: they are known as semi-fungible tokens. For example, a guitar that is initially fungible (it is indistinguishable from any other guitar of the same type) becomes non-fungible when owned by famous musicians since it can be considered as musical heirloom.
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.
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
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.
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
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].
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
Related work
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.
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.
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
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.
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
A comparative analysis can be found in [70].
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
Preliminaries
In this section we briefly illustrate the main features of the ontologies adopted by the ontological stack, namely
The OASIS ontology
We present in detail the main features of the
The Ontology for Agents, Systems and Integration of Services (in short,
Hence,
Representation of agents and their interactions in
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 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
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,
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
Main classes and properties of
In
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 and representing the actions (e.g., produce, sell, …).3
Instances of Action are introduced in the OASIS-Abox ontology [23].
A possible 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 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
UML diagram representing
Summarizing, the main classes characterizing an agent template are the following ones:
AgentBehaviorTemplate. This class comprises all the individuals representing templates of agents. Instances of such class are connected with one or more instances of the class Behavior by means of the OWL object-property hasBehavior.
Behaviour. 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 composing them and represented by instances of the class TaskDescription through the object-property consistsOfTaskDescription.
TaskDescription. This class describes the atomic operations that agents can perform. Atomic operations are the most simple actions that agents are able to practically execute and, hence, they represent what agents can do within the considered 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 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 characterizes 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. The tasks are connected with task operators using 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 extensible vocabulary defined by the OASIS-Abox ontology [23].
TaskOperatorArgument. This class defines operator arguments that represent 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 example the type of asset on which a quality valuation is performed. The tasks are possibly connected to 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.
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:
The instance of class AgentBehaviorTemplate gives way to an instance of class Agent, representing a concrete agent in the knowledge domain. Concrete agents are connected with templates of agents by means of the object-property adoptsAgentBehaviorTemplate.
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 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:
The instance of the class TaskDescription of the concrete agent is connected by means of the object-property overloadsTaskDescription with the instance of the class TaskDescription of the agent template.
The instance of the class TaskObject of the concrete agent is connected by means of the object-property overloadsTaskObject with the instance of the class TaskObjectTemplate of the agent template.
The instance of the class TaskOperator of the concrete agent is connected by means of the object-property overloadsTaskOperator with the instance of the class TaskOperator of the agent template.
The instance of the class TaskFormalInputParameter of the concrete agent is connected by means of the object-property overloadsTaskInputParameter with the instance of the class TaskInputParameterTemplate of the agent template.
The instance of the class TaskFormalOutputParameter of the concrete agent is connected by means of the object-property overloadsTaskOutputParameter with the instance of the class TaskOutputParameterTemplate of the agent template.
Analogous object-properties are defined for the behaviour and goal of the agent.
UML diagram representing
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:
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.
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:
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.
UML diagram representing
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.
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
a clearly specified instance, called Individual, or
a set of anonymous instances of a given type, called SomeItems, or
a product model specification, namely ProductOrServiceModel.
An offering may be linked to multiple price specifications that specify alternative prices for non-overlapping sets of conditions that can be characterized by:
the lower and upper limits of the eligible quantity,
the monetary amount per unit (in combination with a currency), and
whether this price includes local sales taxes (VAT).
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:
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?
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:
The block-header of a block. This is the section summarizing the block itself. It includes some metadata such as the difficulty of the block and the time when the block was mined, the Merkle root of the included transactions, nonce, and so on.
The block. Blocks are containers for all transactions. In BLONDiE, a block is represented by means of all the information concerning the block itself, such as the node miner and the block height, and it is associated with the transactions contained by means of its payload. Blocks are specialized according to the type of blockchain (Ethereum or Bitcoin) they belong to.
The payload. It represents the data of the block and is specialized for each type of blockchain. Payloads in BLONDiE are associated with the related transactions.
The transaction. Transactions consolidate state passages and are specialized, depending on the type of the transaction. In Ethereum, there are three types of transactions: normal transactions (associated with transfers of Ether), contract creations (associated with smart contract creation) and message calls, i.e., passages of messages from one account to another, possibly including data.4
We recall that Ether is the cryptocurrency associated with the Ethereum blockchain.
Account. Accounts are referred to wallets used to store cryptocurrencies, to pay for executing and to authorize transactions.
The ontological stack adopts and extends state-of-the-art ontologies suitably selected for the blockchain-based commerce domain with a behaviouristic vision of its essentials: commercial actors, offers, products, and tokens emitted on the Ethereum blockchain as digital witnesses of exchanged assets. Specifically, the stack adopts and extends three ontologies, one for each underlying subdomain of knowledge, i.e., OASIS for the representation of commercial participants and smart contracts, GoodRelations for representing commercial offerings, and BLONDiE for describing Ethereum constitutional elements. By extending them, the stack constructs three novel ontologies; the first ontology is OC-Found, modelling the stakeholders of the blockchain-based commerce ecosystem and leveraging the
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.
Which are the participants currently available (including the associated digital identities and operations they can perform)?
The competency question CF1 is introduced to allow people and applications to probe the knowledge base for agents available to provide products and services, and the type of actions they can perform on client’s request.
Which are the agents commitments and type of actions performed during their entire lifespan?
The competency question CF2 is designed to find all the actions committed by agents so as to check who executed the actions and the type of operations performed during the lifespan of the available agents. Hence, CF2 allows one to understand how the environment evolved as a consequence of the available agents’ commitments.
Given the resource resource, which is, if any, the supply chain of resource?
The competency question CF3 is introduced to enable clients to discover the supply chain of a desired resource. Thanks to the supply chain, the resource can be consumed by the clients.
Given the resource resource, how the supply chain of resource is constituted?
The competency question CF4 can be seen as a specialization of CF3 and permits to look up for the specifications of the supply chain of a given resource.
Given the resource resource, which are the agents responsible for resource’s supply chain activities?
In line with CF3 and CF4, the competency question CF5 investigates on the agents that are responsible for the supply chain of a given resource. The identity and the behaviour of the agent is useful for the clients to establish whether they may trust the supply chain and, hence, if the resource is reliable.
Given the resource resource, which are the valuations (including the valuer agents) performed on resource?
In line with CF5, the competency question CF6 assists the client to settle his trustworthiness on a given resource by providing valuations performed on it together with the agent that performed them.
To achieve the objective, OC-Found applies the behaviouristic approach pursued by
In this section, we describe the ontological core of OC-Found and how it extends
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
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
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
SupplyChainOfferingProofActivity. This class describes the activities connected with the process of releasing some proofs related with the consummation of the offering, such as digital tokens emitted to witness the transferring of ownership of the resource.
SupplyChainDeliveryActivity. This class describes the process related with the delivery of the considered resource.
SupplyChainPaymentActivity. This class describes the process related with the payment activity required to acquire the resource.
SupplyChainReleaseActivity. This class describes the process related with the release mechanisms of the resource, such as manufacturing, production, assembling, and so on.
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
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
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:
the first activity (individual appleReleaseActivity) describes how the apple batch is produced, by connecting the activity with the behaviour responsible for producing apples, and is associated with the farmer agent (individual appleProducerAgent);
the second activity introduces a token release mechanism entrusted to the smart contract of the apple producer (individual appleProducerSmartContractAgent), in order to provide a proof of transferring of the batch’s ownership;
the third activity (individual appleDeliveryActivity) describes the delivery activity of the batch, which is carried out by the agent fedex:fedexCourierAgent;
the fourth activity (individual applePaymentActivity) is related with activities concerning the payment for the product, entrusted to the agent paypal:paypalPayAgent.
If dependency relationships among supply chain activities are required, the object-property of
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).
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
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
The ontology namespace is
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:
Which are the available offerings (including related details)?
Competency question CC1 provides a complete set of the available offering that clients can consume.
Given an offering offering, which is the supply chain related with offering?
Competency question CC2 is introduced to show the supply chain related with a given offering, explaining how clients should consume the asset traded.
Which are the accepted offerings?
Answers to competency question CC3 are intended to describe which offerings were consumed, thus providing a glue on how the market moved during its lifespan, and hence what type of resources have been traded.
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.
Hierarchies of classes in the OC-Commerce ontology.
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:
request, if the agent is enabled to seek for an offering;
modify, if the agent is enabled to change some features of a previously published offering;
retract, if the agent is enabled to cancel a previously published offering, meaning that it is no longer available due to some unexpected errors on the life-cycle of the asset or on the publication mechanism;
close, if the agent is enabled to close a previously published offering, meaning that the offering is expired or the publisher autonomously decided to close the offering;
accept, if the agent accepts the offering and the related selling condition and supply chain as it is (only counter-offerings or offerings for unique assets can be accepted);
decline, if the agent rejects a proposed offering.
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.
UML diagram representing OC-Commerce offering publishing.
UML diagram exemplifying the production of apple batch 2563 in the OC-Commerce ontology.
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.
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.
UML diagram representing OC-Commerce offerings.
There are currently four types of offerings in OC-Commerce:
Standard offerings, represented by instances of the class StandardOffering. In standard offerings, assets are traded by paying through crypto of FIAT currencies. Hence, supply chain activities of payments involve agent behaviours for transferring crypto of FIAT currencies, respectively. Offerings, in turn, may receive counter-offerings, represented by instances of Offering and connected with the initial offering by means of the object-property isBidOnOffering.
Exchange offerings, represented by instances of the class ExchangeOffering and implementing bartering. In exchange offerings, assets are traded in exchange of other assets. The offering is related with the exchanged asset by means of the object-property isOfferedFor. Supply chain activities of payments related with exchange offerings involve the exchanged asset instead of an agent behaviour.
Auctions, represented by instances of the class Auction. Auction bids are represented by instances of Offering and connected with the related auction by means of the object-property isBidOnOffering.
Counter-offerings, represented by instances of the class Offerings, are offerings bid on standard offerings or exchange offerings. The object-property isBidOnOffering is used to connect the counter-offering with the offering it is bid on.
Moreover, offerings are also classified as
UniqueOffering, when the traded asset is uniquely identifiable, such as second-hand objects, and
NonUniqueOffering, when the traded asset comes from a stock of identical or indistinguishable objects.
Offerings are connected with the traded assets (instances of the class CommercialAsset, subclass of the
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:
AcceptedOffering, if the offering has been accepted (only unique offerings or counter-offerings can change their status to accepted);
ClosedOffering, if the offering has been closed;
DeclinedOffering, if the offering has been declined (only counter-offerings can change their status to declined);
DeprecatedOffering, if the offering has been replaced in favour of a new offering and hence is no longer valid;
RetractedOffering, if the publisher has retracted the offering.
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.
UML diagram exemplifying the full details of an offering for apple batch 2563 in the OC-Commerce ontology.
UML diagram exemplifying the offering acceptance for apple batch 2563 in the OC-Commerce ontology.
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.
UML diagram exemplifying the shipment confirmation for apple batch 2563 in the OC-Commerce ontology.
UML diagram representing OC-Commerce offering modification.
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:
Which are the tokens minted and not destroyed, the related asset, minter, and current owner?
The competency question CE1 is defined to show the tokens available on the Ethereum blockchain and their type, providing an overview of the current arrangement of the token market.
Which are the block and the transaction hash that mint a given token?
The competency question CE2 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.
Which are the smart contracts that emit tokens related to a specific type of asset?
The competency question CE3 allows users to access the smart contracts that generate the tokens associated with the desired type of digital or physical asset.
Which is the number of tokens and the type of the related assets owned by wallets?
The competency question CE4 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 hence have the potential to manipulate their valuations on the market.
To achieve the expected results, OC-Ethereum defines the classes and properties depicted in Figs 25 and 26, respectively.
Hierarchies of classes in the OC-Ethereum ontology.
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
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
UML diagram representing OC-Ethereum smart contracts.
Specifically, OC-Found identifies five types of Ethereum smart contract agents, suitably represented by the following classes:
EthereumFungibleSmartContractAgent, representing smart contracts for trading fungible tokens (henceforth called fungible smart contracts) and containing the class EthereumERC20SmartContractAgent that represents smart contracts compliant with the ERC20 standard protocol;
EthereumNonFungibleSmartContractAgent, representing smart contracts for trading non-fungible tokens (henceforth called non-fungible smart contracts) and containing the class EthereumERC721SmartContract-Agent that represents smart contracts compliant with the ERC721 standard protocol.
EthereumSemiFungibleSmartContractAgent, representing smart contracts for trading semi-fungible tokens (henceforth called semi-fungible smart contracts) and containing the class EthereumERC1155SmartContract-Agent that represents smart contracts compliant with the ERC1155 standard protocol;
CustomEthereumSmartContractAgent, representing user-defined smart contracts that are not compliant with the ERC standards.
For example, the smart contract generated by our apple producer is represented by means of the fragment in 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:
fungible tokens, represented by instances of the class EthereumFungibleToken, containing the class EthereumTokenERC20 that represents fungible tokens compliant with the ERC20 standard protocol;
non-fungible tokens, represented by instances of the class EthereumSemiFungibleToken, containing the class EthereumTokenERC721 that represents non-fungible tokens compliant with the ERC721 standard protocol;
semi-fungible tokens, represented by instances of the class EthereumSemiFungibleToken, containing the class EthereumTokenERC1155 that represents semi-fungible tokens compliant with the ERC1155 standard protocol;
custom user-defined tokens, not compliant with the ERC standard protocols and represented by instances of the class EthereumCustomToken.
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
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:
the changed perdurant feature, which is also an instance of the class DeprecatedEthereumTokenPerdurantFeature by means of the object-property hasEthereumTokenFeatureModificationSource;
the new perdurant feature, by means of the object-property hasEthereumTokenFeatureModificationResult.
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.
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.
The ontological stack was evaluated during the entire life-time of its design and development through four main KPIs. To begin with, the consistency check of the stack was carried on by means of three main OWL reasoners, thus demonstrating the soundness of the ontologies. Then, structural metrics of the stack that depicts the number and type of elements used to define the ontologies, such as number of classes and object-properties, were computed, providing a general evaluation of how much the ontologies are large and complex. Protégé was used to compute the structural metrics on the ontologies.
Furthermore, ontological metrics were computed on the ontologies root of the stack, i.e., the novel fragments of the ontologies excluding the imports from the external ones (namely
OntoQA is a feature-based method for evaluating ontologies by applying techniques that do not require data training and that involve users minimally.
The proposed competency questions are implemented by suitable SPARQL queries in order to be performed against the developed ontologies. SPARQL queries also constitute regression and integration tests for the ontological stack.
In what follows, we report the results of the evaluation methodology, including the SPARQL queries implementing the competency questions, adopted and applied to the three ontologies, OC-Found, OC-Commerce, and OC-Ethreum, together with a discussion of the results obtained.
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.
Metrics
To begin with, we discuss the results of the evaluation of the OC-Found ontology. Consistency of OC-Found has been checked by the reasoners Pellet [92], HermiT [60], and FaCT
Structural metrics on OC-Found
Structural metrics on OC-Found
The ontological metrics computed on OC-Found are reported in Table 2 and compared with those computed on
OC-Found exhibits a relationship richness of 57.14%, indicating a well-balanced mix of generic relationships and class hierarchies. The value obtained from OC-Found is higher than the one computed on
Ontological metrics on OC-Found
We are ready to introduce the SPARQL queries that implement the competency questions
Which are the participants currently available (including the associated digital identities and operations they can perform)?
The answer to
Which are the agents commitments and type of actions performed during their entire lifespan?
The answer to
Given the resource resource, which is, if any, the supply chain of resource?
The answer to
Given the resource resource, how the supply chain of resource is constituted?
The answer to
Given the resource resource, which are the agents responsible for resource’s supply chain activities?
The answer to
Given the resource resource, which are the valuations (including the valuer agents) performed on resource?
The answer to
Given the resource resource, which is the average score of valuation of resource and how many valuations are there?
The answer to
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.
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
Structural metrics on OC-Commerce
Structural metrics on OC-Commerce
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.
Ontological metrics on OC-Commerce
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.
We now discuss the SPARQL queries that implement the competency questions
Which are the available offerings (including related details)?
The answer to
Given an offering offering, which is the supply chain related with offering?
The answer to
Which are the accepted offerings?
Answers to competency question
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.
Metrics
As in the case of OC-Found and OC-Commerce, consistency check has been carried out by the reasoners Pellet, HermiT, and FaCT
Structural metrics on OC-Ethereum
Structural metrics on OC-Ethereum
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.
Ontological metrics on OC-Ethereum
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.
We are now ready to present the implementation of the provided competency questions
Which are the tokens minted and not destroyed, the related asset, minter, and current owner?
The answer to
Which are the block and the transaction hash that mint a given token?
The answer to
Which are the smart contracts that emit tokens related to a specific type of asset?
The answer to
Which is the number of tokens and the type of the related assets owned by wallets?
The answer to
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.
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:
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.
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,
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).
Request order’s structure in 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:
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:
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
optional properties are modelled with the optional execution properties introduced before;
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
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.
UML diagram representing the worker pool offering.
UML diagram representing the iExec clerk agent.
UML diagram representing the iExec worker pool agent.
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
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.
Footnotes
Acknowledgements
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.