A Behaviouristic Semantic Approach to Blockchain-based E-Commerce

Tracking #: 3543-4757

Authors: 
Giampaolo Bella
Domenico Cantone
Marianna Nicolosi Asmundo
Daniele Santamaria

Responsible editor: 
Sabrina Kirrane

Submission type: 
Full Paper
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 the 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 its mentalistic notions. The stack is validated through appropriate metrics and competency questions, then demonstrated through the representation of a real world use case, the iExec marketplace.
Full PDF Version: 
Tags: 
Reviewed

Decision/Status: 
Accept

Solicited Reviews:
Click to Expand/Collapse
Review #1
By Roberto García submitted on 26/Oct/2023
Suggestion:
Major Revision
Review Comment:

Though the paper provides a good introduction to blockchain technologies and adequately justifies an approach based on ontologies to facilitate the interoperability of blockchain-based data, the article requires a profound restructuring to properly justify its adequacy to the proposed objectives.

Basically, the paper should start with a clear set of requirements, i.e. what specific kind of information needs the ontology should be able to address. For instance, through competency questions like those listed in Section 3.3 for the BLONDiE ontology. For instance, "Who mined a specific block?".

However, the competency questions are proposed as a way to validate the ontology and in the end, they are disconnected from clear information needs. For instance, CF2: "Which are the agents' commitments and type of actions performed during their entire lifespan?".

Following Ontology Engineering approaches like NeOn (http://neon-project.org/nw/book-chapters/Chapter-05.pdf), start with a specification section that includes the definition of realistic information needs and the corresponding competency questions. This should be defined and presented before, not after developing (and presenting) the ontology.

This competency question should be finally used to validate the ontology, for instance through SPARQL queries that can be used to respond to the question based on instance data based on the proposed ontology. Ideally, the paper should like to sample files with the instance data, so it is possible to independently test that the competence queries can be responded to using the corresponding SPARQL queries.

Review #2
Anonymous submitted on 12/Jan/2024
Suggestion:
Accept
Review Comment:

The reviewers have addressed all remarks. No further interventions from my side are needed, with the exception of a minor rephrasing: on page 29, rather than writing "also called fungible smart contract", should use the expression "henceforth called fungible smart contract" (the same applies to the non-fungible and semi-fungible ones) as this nomenclature is introduced by the authors and not necessarily commonly accepted as the "also" would suggest.

The contribution looks solid, detailed, and deep. Also, the repository with code and data is rich and well documented.