Web3.0 Commerce Ontology Experiment
------------------------------------------- Draft: starting 7/8/2023 and ending 8/1/2023 ------------------------------------------
Ontology to support Web3.0 Commerce solution development.
A clear semantic representation of Web3.0 commerce is essential to constructing future applications and composable services. A robust ontology that captures classes, relationships and constraints is foundational to:
API Development (GraphQL, JSON-LD)
Data Access (SPARQL)
Data Storage (IPFS)
Discovery (Services)
Provenance (GPDR)
AI and Machine Learning (Embeddings into AI LLM's, Tuning LLM's)
Experiment Goals:
Commerce Ontology that supports Web3.0 application development
Clear delineation between ontology boundaries (based on domain, purpose and behavior)
Clearly differentiate between planned (i.e. discovery) and executed (i.e. provenance)
Concrete and easy to understand (minimize layers of abstraction and complex patterns)
Extensible for building domain specific ontologies
Leverage ontology standards like prov-o, p-plan, owl-s, goodrelations
Solution
RichCanvas Commerce Ontology (comm-rc) is dedicated to capturing modern commerce classes and their relationships.
comm-rc Ontology fundamentally builds upon W3C Provenance and Planning Ontology principles of Agent, Entity and Activity
To keep comm-rc Ontology as simple as possible we focus on core commerce entities and associated behavior.
Web3.0 app's need to trace provenance of commerce entities back to their Blockchain counterparts. comm-rc Ontology must maintain ontological alignment with Ethereum NFT's, associated Smart Contracts, Accounts and Wallets.
comm-rc Ontology layers on top of our flow-rc Ontology. flow-rc Ontology brings together Provenance and Planning. flow-rc also brings in Ethereum Smart Contract, Transaction and NFT references.
Custom Ontologies and Knowledge Bases can be built upon comm-rc. The diagram below shows how it can be extended to create a metaverse ontology.
flow-rc Ontology
flow-rc includes the Prov Ontology concept of Influence (Agent Influence, Activity Influence, and Entity Influence). This allows for the Ontology to capture Agent Behavior and Entity Generation.
AgentBehavior represents the influence that the Agent has on the Activity
EntityGeneration represents the influence that the Activity has on the Entity
Notice the Execution layer is above the Specification layer
eth-rc Ontology is used by flow-rc to capture the Ethereum relationships for Agent, Entity and Activity. There are times when third party applications will want to query the knowledge base using blockchain terms. For example, an app might want to query for all Ethereum contract addresses which support an ERC721 Interface which can mint metaverse land NFT Assets. This query can use the eth-rc Ontology to query the Metaverse Knowledge Base. Now that's cool.
comm-rc Ontology extension of flow-rc Ontology
comm-rc Ontology extends flow-rc to introduce commerce specific entities of Asset, Offering, Category, and Catalog. It also introduces the concept of Factory which represents an Software Agent that initiates Tasks.
Notice the Execution layer is above the Specification layer.
metaverse knowledge base leverages the comm-rc Ontology
A metaverse Land Asset Creation scenario is depicted in the diagram below. Individual Instances of each of the comm-rc and flow-rc classes are shown.
Notice the Specification is above the Execution layer in this diagram below.
turtle representation of CreateAssetTask and associated Factory CreateAssetBehavior
SPARQL Query to retrieve factory specification (smart contract specification) for 'land asset' specifications
SELECT DISTINCT ?entitySpec ?generationSpec ?factorySpec ?assetTypeSpec ?assetTypeName WHERE { ?entitySpec flow-rc:qualifiedGenerationSpec ?generationSpec. ?entitySpec prov:wasAttributedTo ?factorySpec. ?entitySpec comm-rc:definedByAssetTypeSpec ?assetTypeSpec. ?assetTypeSpec foaf:name ?assetTypeName. FILTER( ?assetTypeName = 'land') }
query result:
[["r0:", "[['?entitySpec', 'commgen-test-out.landSpec_1'], ['?generationSpec', 'commgen-test-out.landGenerationSpec_1'], ['?factorySpec', 'commgen-test-out.landFactory_1'], ['?assetTypeSpec', 'commgen-test-out.landTypeSpec_1'], ['?assetTypeName', 'land']]"]]
Related Works
The challenge in building a rich commerce ontology is to make it "usable" while also maintaining the alignment to established and key abstract classes and relationships found in W3C standards for example Provenance Ontology link.
With the emergence of the Artificial Intelligence hysteria, comes a renewed focus on the semantics of data and ontology. A lesser hyped quest for composability is also driving the need for well defined API's and unification of classes and relationships behind those API's. The requirement of information provenance and control essential in uses cases like AI and GDPR.
Legacy Foundational Work
Provenance and Commerce are key areas of the comm-rc ontology.
The W3C Provenance Ontology was established around 2013 and serves as the foundation for our commerce ontology. PROV-O shown below, capture the three key classes of Agent, Entity and Activity along with all the relationships between these classes. This ontology also captures the key concept of collections.
The PROV-O ontology captures the chronology of the What, When, Why, Where, hoW, Who and Which in producing things within a system. This is sometimes referred to as the "Execution" model. These models helps capture the Execution of things.
Entity, a physical, digital, or conceptual kind of real or imaginary thing.
Activity, something that occurs over a period of time and acts upon or with entities; possibly including consuming, processing, transforming, modifying, relocating, using, or generating entities. Defines what did happen.
Agent, something or someone that bears some form of responsibility for an activity taking place, for the existence of an entity, or for another agent’s activity
Other key terms
Bundle, contains a step-by-step description of how the steps were executed
Software Agent
PLAN-P ontology, and extension of PROV-O, captures an abstract description of the workflows. Kind of a workflow template. This is sometimes referred to as the "Description" model. It describes the steps involved in a particular past execution. A Plan is intended for the discovery phase when a user would like to examine the capabilities of the system.
Plan, represents a set of actions or steps intended by one or more agents to achieve some goals. Describes what could happen.
Semantic web service description and discovery (W7 Ontology) link. Extends the P-Plan ontology to support web service description.
This model closely resembles the behavior of Ethereum Smart contracts. An NFT, in concert with its associated Smart Contract, brings together data and code.
Web Service
Plan (Explanation, Function, Precondition, Input, Output)
Open Provenance Model for Workflows
Built around 2015
Extends Prov and works along side Plan
https://www.opmw.org/model/OPMW/
OPMW extends PROV, OPM and P-Plan in order to capture the execution traces of a workflow template (process view provenance)
Good overview of different flow related ontologies
Provenance Description of Metadata using PROV with PREMIS for Long-term Use of Metadata
Community focusing on this area (more recent)
https://www.opmw.org/interoperability.html
OWL-S (formally known as DAML-S) in 2004 link
Services on the Semantic Web (Service Discovery and Invocation)
Service Profile: similar to prov-o:plan
This is a good foundation for describing the behavior and operations of an Ethereum smart contract.
EthOn (Ethereum Ontology)
Built by Consensys, Started around 2017
EthOn and BLONDiE Ontologies do a good job of representing Blockchain and Ethereum structure, but do little to capture associated behavioral mechanics.
https://github.com/ConsenSys/EthOn
https://github.com/ethereum/yellowpaper (6-9 years ago)
http://ethon.consensys.net/Contracts/v0/
example
https://finregont.com/2017/02/21/ethereum_fibo_alignment/
EthExtras (extension of EthOn)
A middleware for systems consumes Ethereum data in soft real-time: a Semantic Web approach
Focusing in on NFT and IPFS
Implementation using EthExtras, https://github.com/celiomarcio/semanticethon/blob/main/lib/semantics.py
Future work: NFT, Tokens, ENS, IPFS and somefamous Oracle Services
BLONDiE
Blockchain Ontology with Dynamic Extensibility (BLONDiE), Started in 2008
Blockchain based (sits over bitcoin and ethereum, not really factor in smart contract principles
https://arxiv.org/pdf/2008.09518.pdf
Does not cover concepts of Contract or workflow/supply chain
BLONDiE is not as detailed as EthOn with Contract extension so we are extending EthOn for our eth-rc Ontology
Solidity smart contract model
Solidity Ontology link
https://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=9548044
good overview and ties into ethon
https://ieeexplore.ieee.org/document/9548044
GBO modern Ethereum extension of EthOn (very detailed)
https://repositorio.iscte-iul.pt/bitstream/10071/25567/1/article_88890.pdf
Commerce
GoodRelations, and eClass Ontology
eClassOwl link
Aspirational Work
RichCanvas Commerce ontology builds upon work done by Daniele Santamaria and team link. Over the past few years they have developed an ontology that focuses on Web3.0 commerce. Their oasis ontology provides many of the foundational commerce class and relationship features. They build upon an abstract behavioral pattern that supports both the planning and execution. They have continually refine and enhanced their ontologies and give lots of real world examples.
This OASIS and POC4COMMERCE has a significant thought leadership position in this very specialized area. They have taken legacy ontology concepts and synthesized them into a very elegant solutions.
RichCanvas ontologies leverages many of their core principles from OASIS, but takes on a narrower scope of NFT Commerce. RichCanvas also employs a more concrete vocabulary that is relevant to the narrower scope we have on NFT Commerce.
RichCanvas ontologies also draws from PROV-O ontology. Our current narrower scope does not require the robust behavior pattern OASIS has developed.
OASIS v2.0 more recent works significantly enhanced their commercial ontology (ec-oasis) and introduced Process/Procedure extensions to support more robust planning operations and discovery. Some really good work.
A few documentation things we hope will make RichCanvas ontology simpler to understand.
Minimize Complexity (OASIS documents 4 primary classes by 4 levels of abstraction)
Behavioristic Pattern includes Agent, Behavior, Goal, Task, ....
Examples of OASIS include 3 layers of abstraction and then concrete (Base Pattern, ERC721, Bank Abs, Concrete Behavior)
Don't show inheritance hierarchy (subClassOf) in same diagram as trying to show complex relationships Agent, Account, Activity (Creation).
Don't show Blockchain, Ethereum, ERC20, ERC721 in same picture as showing relationship. Don't mix Ethereum, NFT (ERC721) and commerce classes in same visual models
Represent OASIS "Things" (offer, transfer, ownership) only in commerce model.
Modeling Simplifications
Focus only on "Asset" (NonFungibleAsset that has "DigitalToken"). OASIS then breaks out KnownFungibleAsset (I believe they mean NonFungibleAsset because it is a subclass of NonFungibleThing)
Focus only on "Offering" (Commercial Issue with Publishing Activity). Negotiation, Accepted will be handled slightly differently.
Derive from PROV-O and P-PLAN ontologies for Agent, Entity, Activity relationship. Derive from Plan and Goal from PROV-O instead of OASIS. Looking for ways to not have to include complexity of OASIS Behavior Patterns.
Don't include the Goal abstraction. Behavior --> Task, Plan --> Task. P-PLAN does not include the concept of Goal in their ontology. P-PLAN has Plan --> Step and PROV-O has Bundle -> Activity.
Don't include concept of Template. Not sure that Template adds anything to Ontology. Plan is used to describe the steps and behavior and Bundle is used to capture the actual execution flow.
OASIS Key Patterns and Abstractions
Behavior Pattern of (Agent, Behavior, Goal, Task)
Behavior to Action Relationship
Agents Capabilities to perform Actions
Thing Pattern of (Template Behavior abstract, Template Behavior for ERC721 mint, Behavior for bank ERC721 Mint, Execution for actual mint )
Description used by TemplateThings Pattern
TemplateThings are defined in terms of Description Classes (Agent, Behavior, GoalDescription, TaskDescription)
Template Pattern, general template pattern overview example shown below (first figure)
Template Abstraction for ERC721 using Pattern (ex. capture ERC721 concepts that drive all ERC721 mint behavior abstractions), ERC721 example (second figure)
Behavior Description for bank (third figure), based on ERC721 Template
Template: modeling general abstract behaviors of which concrete agent behaviors are drawn
Concrete example of execution (fourth figure)
Task has Operator (action), Input Parameter, Output parameter, Object (thing)
Atomic Operation
Plan Executions (as executed)
Sequence of behavior
Actions Performed
Plans
Sequence of behaviors being requested (entrusted agents carry out plans)
Planning vs Execution
Physical Thing (batchOfApples) is modeled separate from NFT (...)
Blockchain and Ethereum
EthereumERC20, NonFungibleBlockchain, EthereumERC721, EthereumERC1155
OASIS Commerce Analysis
ec-oasis and oc-commerce ontologies support commerce. ec-oasis looks to be a more recent ontology.
ec-oasis model (our interpretation of oc-oasis focused on commerce, not official oasis diagram)
oc-commerce is earlier work (I believe) where offering is not split off from activity. Here is my model of oc-commerce (based on diagram from oasis documents and ontology)
Similar Examples/Use-Cases that leverage NFT's and Ontology
Copyright Management associated with Metaverse
https://arxiv.org/pdf/2208.14174.pdf