CommerceCore Ontology

CommerceCore Ontology provides the foundation for building specialized commercial domain ontologies.   Our goal is to provide a generic set of building blocks that can be extended.   Commerce is just one element of the overall digital experience so ultimately your semantics must align with that of your domain.

Transactional Provenance

Provenance answers the question of who-what-when-where by capturing information such as entities, agents, and activities.

With this information brands can create a truly immersive digital experience for their customer and enable brands to continuously enhance that experience.  

This requires the ontology capture Agent/Entity interactions and Activity Behavioristics. CommerceCore must also represent both Specification and Transactional system characteristics.  Our Ontology leverages the powerful and proven PROV-O and P-Plan Ontologies. 

API's and Interoperability

Each of these ontologies are used in defining application API's.  Interoperability between components is enhanced by applications leveraging the language of common upper ontologies.  Analytics Engines and Machine Learning eat this information up because all applications derive their language from this common foundation.

common core ontology concepts link

Packaged Business Capabilities (PBC's) and the "Commerce Operating System"

Composability of Packaged Business Capabilities is a fundamental tenant of modern e-Commerce architectures.  

Companies like Shopify, CommerceTools, SiteCore, ElasticPath and others are championing the principles of composability and PBC's.  These companies talk to the value of assembling components to build tailored commerce solutions.

The MACH Alliance takes it one step further and talks to the value of assembling multi-vendor best-of-breed component based solutions.  MACH Alliance also advocates for these components to be built with an API first mentality which hides the complexity behind a set of standard application interfaces.

Over the past few years it has become clear that these leading commerce vendors are peddling platforms that increasingly look very similar.  Innovators like Talon.One who provide focused differentiated capabilities are forced to pick their "platforms" they want to support.

This reminds us a lot of the operating system (OS) wars of the 80's and early 90's.  The big companies pushed their proprietary computers with their proprietary applications.  Each computer had their underlying proprietary operating system which their applications ran on.  What a pain.     

Well, this is where we are now in building commerce solutions.  You first pick your "platform" and then you build your solution.  What a pain.

This will change.  It has to.  Folks that live and breath commerce and who build cross platform solutions see the incredible overlap between them.  This overlap is most prevalent in their information architectures.  They use different terms but the concepts are almost identical.

The best place to start this "Commerce OS" revolution is to build out a CommerceCore ontology that draws out these commonalities and establishes a common language.  

This Ontology will help serve to address the biggest issue facing composable commerce today which is complexities inherent in integration and solution assembly.

Then we can take on the big nut of "Commerce OS" and recognize the real value is in the innovation at the edges, like Talon.One, and not the commodity platforms.  Solution developers could then select their best-of-breed Packaged Business Capabilities (PBC's) that just hook into the "Commerce OS" platform. 

Shopify talks about "offering independence for every component of the commerce operating system" link. 

"Asset" is the foundational Thing 

This Ontology is unique in that it recognizes "Asset" as the central "Thing".    Marketing crafts catalogs, categories, product abstractions, and channels to prepare the "Thing" for selling.   Commerce involve offers (buy/sell), orders, and transactions to sell the "Thing".  Supply chain operations support production and fulfillment of the "Thing".

Traditional Ontologies, like GoodRelations, have "ProductOrServiceModel" abstraction.  ProductOrServiceModel is sometimes more accurately described as a "Specification" of the "Thing" being fulfilled.   In current eCommerce solutions this specification is often referred to as "Product" and "Product Variant".

In most cases "Product" is expressed in marketing terms and only loosely associated with the "actual thing" that gets fulfilled.   Solutions will leverage Product Variant to get closer to the "actual thing", but the attributes used are often also abstract and serve only as a specification.    "Product" and "Product Variant" abstraction is then carried forward to related offers, orders, payment and fulfillment which can get even more convoluted.  It works for simple things, but falls short in more sophisticated digital experiences.

Modern systems are extending simple sell side commerce into a more comprehensive digital experiences that incorporate marketplaces (buy/sell offerings), product bunding, bartering, digital receipt, service fulfillment, and resell.

Many solutions are extending the principles of "inventory" into a sell side experience as assets.  For example, builders are now advertising and selling specific homes and not just home models in an area.  VRBO and Airbnb sell specific room night stays at specific properties while traditional hotels still offer a room type for a night.  OpenSea sells specific pieces of digital art as NFT's. 

Solutions, like airline travel, are also extending the context of an Aggregate Order.  For example a single Order can incorporate all aspects of airline travel.  The Order is created, added to, changed and eventually fulfilled and paid for.  It's adopting many principles similar to a hotel stay folio.    

Asset (the "thing") provides the foundation for defining more comprehensive description of Commerce Behavior.  

Marketplace

Online marketplaces are ecommerce sales channels that allow you to sell products and services to an active audience.

The operative word here is "sales channel".  The Marketplace provides a connection (channel) between Consumers and Providers.  This channel might be centered on a single "Company Brand" or interest like House Hunting.

CommerceCore Marketplace scope encompasses discovery, offer, negotiation, order, fulfillment, settlement, membership and loyalty.   This wide scope is required to provide an outcome-focused mindset between Consumer and Provider. 


There are lots of different types of Marketplaces.  

Types of Marketplaces

CommerceCore primarily focuses on B2C, D2C and P2P types of marketplaces. 


Marketplace Transaction Types


CommerceCore considers Money as just another Asset so by definition our focus is on Bartering Transactions. 

With our loose definition of "Bartering" we consider B2C, D2C, P2P as bartering where the Consumer is exchanging the asset of of "money" for Provider assets of goods and services. 

Also, we consider a simple company branded e-commerce site as a marketplace (based on a single Provider). This is kind of important.  Discussion at bottom of this section.


A robust commerce ontology is needed because B2C, D2C, and P2P marketplace digital experiences are doing more.  Even traditional "Retail" environments are introducing concepts like dynamic loyalty based product targeting, dynamic provider offers, attribute based pricing, and dynamic yield based pricing.

Secondary reseller markets are now finding their way into mainstream commerce.

There are even marketplaces where multiple people team up to purchase a particular asset like a painting or piece of real-estate.

Airlines are transitioning to a direct-to-customer model where carriers dynamically build tailored offers that meet specific customer wants.  These tailored offers take into account loyalty,  travel criteria and ability to spend.  These offers include bundling of flight, seat, concierge service, baggage, hotel, car, etc.   These capabilities are specified by IATA standards and now being adopted by American Airlines and United.  


We also see the marketplace as just a mechanism to connect consumers and providers.  For the purpose of this ontology the marketplace is simply a "shared" place consumers and providers engage.   Amazon, might extend this ontology to incorporate Marketplace Identity and Marketplace Business Value.  We maintain this narrower scope so that when we talk about things like Privacy and Transparency we don't get commerce concepts entangled with broader marketplace platform business dynamics.



eCommerce Site vs Marketplace

statement from Google:

"eCommerce and marketplace are two different types of platforms. An eCommerce store is an independent website built with the help of eCommerce solutions such as Shopify, WooCommerce, or Magento. On the other hand, a marketplace is a platform where customers find sellers, connect, and purchase goods."

The first statement draws the distinction between eCommerce and Marketplace based on technical platform delineation and not on platform capabilities/vocabulary. The second statement regarding marketplaces is interesting because it succinctly and accurately defines an eCommerce site if you change the plural "sellers" to "seller".

The distinction comes down to:


During the scope discussion to follow, we talk about how CommerceCore Ontology must transcend artificial platform boundaries inherent in current commercial solutions.  

We assert the distinction between "single-seller" and "multi-seller" is not a key driver in defining a commerce Ontology.    The distinction is primarily one of "brand" and not vocabulary or platform capabilities.

To this end, we refer to an "eCommerce Site" as a "Marketplace" with a single seller.


Exchange vs Marketplace

"An exchange is a marketplace where securities, commodities, derivatives and other financial instruments are traded."

Since we consider Money as a type of Asset the distinction between Exchanges and Marketplaces gets a little murky.  As we enter the digital space this distinction can get even more convoluted, hence the current regulatory quagmire. 

Coinbase supports exchange of cryptocurrency and NFT's.   The Coinbase NFT marketplace is very similar to OpenSea NFT Marketplace.  There is little difference in the behavior in the exchange of Fungible Tokens (coins/cryptocurrency) and a Non-Fungible Tokens (NFT's). 

Payment gateways are now accepting payment types of loyalty reward points, stored value, and forms of digital currency in addition to traditional credit and debit cards.

For the purposes of Ontology we consider the Exchange of Money to be the same as the Exchange of Assets so an Exchange is considered to be a type of Marketplace.

Consumer Centric and Outcomes Focused

Over the past 10 years retail commerce has driven the e-commerce user experience.   

The user searches a catalog, is presented set of items, adds items to a shopping cart and then checks out and pays for those items.

This short interaction starts with little upfront communications and ends with a singular Order that must capture everything needed to Fulfill that Order.   The goal in most cases is to get the customers money as soon as possible.  Once payment is made these sites hand the customer over to some distant and disjointed customer service experience.

As brands transition to more D2C and P2P marketplaces this antiquated retail experience must change.   Brands are transitioning hard toward loyalty based relationships that present their value in the context of desired consumer outcomes.   Desired Outcomes like having a beautiful HGTV style home that is welcoming and "happy".   Establishing a deeper connection between the brand and consumer which transcends a single retail sell.   A relationship that is possibly rooted in the customer identity and core beliefs. 

Consumer centric outcomes will be owned by the Consumer and shared with "the" Brand.  This is a kind of obvious observation, but hard for Brands to accept.


Today, most Brands believe they own 100% of the consumers next project or activity.   In the name of simplicity brands are "packaging" everything into a single "transaction" and managing the complexity for the consumer.


For the uninformed and disorganized among us these services by their nature are good and valuable.   The issue comes in the way that Brands offer these services and manage customer data.

What if a house hunter, had a rich set of data outlining their desires and made it available to "experts".  Real estate professionals could come along side them in their hunt and provide valued services.  Overtime, both the house hunter and supporting Brands grow in their understanding of consumer wants and the market.   Brand sites could leverage and contribute to the consumer owned data.   As that data is enriched other providers could contribute with proposed loans, area house pricing projections, or propose candidate home recommendations based on some special AI algorithm.  

The important thing is that the consumer and their desired outcomes stay at the center of the conversation. In today's world,  the consumer too quickly places their desired outcomes under the umbrella of a particular brands offering.  The consumer never gets exposed to that incredible experience or product.

The big Brand will quick say that their customers just cannot handle the complexity of choosing for themself and the umbrella is required.    This is where disruption comes in.   Brands will find a way "to come along side" and put the consumer truly at the center.


Decoupled Provider

 In a quest for establishing clear domain boundaries between commerce related activities CommerceCore Ontology breaks out Provider related "Things" and "Behaviors". 

A single Marketplace connects Consumers with multiple Providers.  A Provider can support multiple Marketplaces (multiple sales channels)

Key Provider Capabilities

"Sales Channel" is a key CommerceCore Ontology concept.  Given that the Catalog is owned by the Marketplace, Providers must be able to register their Offerings to Channel Catalog Item specifications.  Providers must be able to support fulfillment of Channel Orders.   These fulfillment items involve "Parties" and related owned "Assets".

Trust, Loyalty, and Membership

A two sided marketplace requires trust between Consumer and Provider.

Digital experience is significantly driven by the level of trust shared between Consumer and Provider.

Imagine the possibilities if we totally trusted each other.  We trusted that each party had the other parties best interest in mind.  That both parties understood what mattered to each other and worked toward those desired outcomes.  Imagine if that trust translated, over time, into Consumer Loyalty toward a Providers Offerings.

Ultimately, if there is "true" Loyalty between parties, built over time, then there is trust at the beginning of the onset of an engagement (discovery, sales, fulfillment, settlement). 

If there is Trust and Loyalty at the beginning of an engagement then the user experience might be very different.  Maybe even disruptively different.


Through Membership and Community a brand can build deeper trust and loyalty. 

Membership takes many forms in a commerce context.  

Membership Definition (Oxford Language)

"the fact of being a member of a group"


Association Definition (Oxford Language)

"a group of people organized for a joint purpose"


Persona Definition link

"a personalized fictional character created to represent a user type that might use a site, brand, or product in a similar way. Personas represent the similarities of consumer groups or segments."


Loyalty Definition link

"a person’s devotion or sentiment of attachment to a particular object, which may be another person or group of persons, an ideal, a duty, or a cause. "



Types of Memberships



Establishing Trust

Consumer trusting Provider

We use the term "Desired Consumer Outcomes" because the consumer ultimately is looking for a particular outcome related to an engagement.   Trust is enhanced when a Provider achieves that desired outcome.  

Building trust is a key part of the customer journey.  Trust is built over time. 

Trust building within an engagement (discovery, sales, fulfillment, settlement)

Trust building over many engagements (loyalty)

Trust and Loyalty building within a community (membership)


Provider trusting Consumer

Digital Identity

Both Consumers and Providers leverage Digital Identities to prove who they are to other websites, services and applications.  Digital Identity also consists of attribution and identifier information they can choose to share with others.   link



Identity Definition link

"Identity refers to our sense of who we are as individuals and as members of social groups. It also refers to our sense of how others may perceive and label us." 


Digital Identity link

"A digital identity is typically defined as a one-to-one relationship between a human and their digital presence. A digital presence can consist of multiple accounts, credentials, and entitlements associated with an individual." 


Self-sovereign identity (SSI) link

This is called “self-sovereign” identity because each person is in control of their own identity.

"interoperability of a user’s identity across multiple locations, with the user’s consent, but also true user control of that digital identity, creating user autonomy. "

"also allow ordinary users to make claims, which could include personally identifying information or facts about personal capability or group membership. It can even contain information about the user that was asserted by other persons or groups."


Self-sovereign Membership

Imagine a world where there is no central control of group membership.   A person receives and retains a "Membership Proof" that grants them access to Group Services and can be used to verify their Group Membership.   

Each person is in control of membership related information.

In the future, Companies or Organizations do not need to maintain custodial control over your information.   Through decentralized online "Consumer Accounts", talked about later, people can maintain full control of what information is provided to third parties and when it is provided. 

Regulations like GDPR become achievable because third parties have no custodial rights to your data.    

Choice vs. Regulatory Compliance, and Privacy vs. Transparency

This is a loaded conversation.  Especially when it comes to commerce and a two sided marketplace.


Lets first talk about what these terms mean.

Choice vs. Regulatory Compliance

Regulatory compliance is when businesses follow state, federal and international laws or regulations relevant to operations. 


Privacy vs. Transparency

Privacy is closed, Transparency is open. 

But, open to whom and closed to whom is a key question.


A two sided marketplace is between two parties:  Consumer and Provider.    Terms like Privacy, Transparency, Choice, and Regulatory Compliance have different impact when talking about different contexts.  

For example, I might think about privacy and transparency differently within the context of marriage than I would in a public forum.

CommerceCore Ontology explores three different perspectives:

Ultimately, within a digital landscape this discussion comes down to information exchange between Consumer, Provider and the Marketplace.


Privacy and Transparency are usually talked about within a public setting.  Folks like Julian Assange profess principles like "Privacy for the weak, transparency for the powerful".   

In the context of Commerce this perspective gets a little murky.    Who are "The Weak" and "The Powerful" in an engagement between a rideshare driver (Provider) and passenger  (Consumer) or within a Peer-to-Peer marketplace.  

This discussion of privacy and transparency between Consumer and Provider becomes much more manageable when you consider marketplace data ownership as under "shared custody" between Consumer and Provider and not owned by "The Marketplace".

As marketplaces become more "democratized" emphasizing the relationship between Consumer and Provider over "Platform" the issue of Privacy and Transparency implodes down to individual Choice.

Ultimately, commerce related information privacy and transparency should be controlled and governed by the Consumer and Provider.  They should be able to choose what information they share and who they share it with.

Regulatory Compliance

Governments enforce "Regulatory Requirements" to ensure a level of visibility into marketplace engagements between Consumers and Providers.  This is an example of where a third party gets involved.  How much privacy do the Consumer and Provider have to give up?


"Bad Actors"  

Exchanges and Marketplaces can be used by Bad Actors to launder Assets (Money).   Marketplace data can also be used in conjunction with other source data to catch Bad Actors (government fusion of multi-source data)


Bad stuff that happens:

In many cases the Bad Stuff that happens does not impugn or implicate the engagement Consumer or Provider actors.  

Regulatory Compliance governance is usually dictated by allowed jurisdictional civil liberties and freedoms.  

Governments need to know Assets moving between actors are clean.


Commerce DNA - DomaiN Attribution

When redesigning our living room this year we went to a well known furniture wholesale site, found and ordered this nice new leather sofa.   After several months we received delivery of a brand new sofa.  It was unwrapped and placed in our living room.  To our dismay we received delivery of a cloth sofa, not leather.   Recognizing there was a problem the delivery folks told the wholesaler who intern ordered another sofa for us.  Several months later we received delivery of another new sofa only to learn it was again cloth.  After hours of talking with multiple customer support folks we learned that the manufacturer does not produce leather sofas.  We refer to this experience as "The leather sofa that never was".

Shared domain language between providers, wholesales, resellers, and marketplaces is critical.  In the example above, shared understanding of "material" mattered.  The deeper the consumer experience becomes the more important language between participants becomes.

Breaking commerce solutions into composable pieces (PBC's) and then sourcing those pieces from multiple venders creates an enormous integration challenge.  The primary integration challenge is typically not technical, but rather maintaining integrity of language semantics between the various parts.

Domain language integrity is not guaranteed by using this CommerceCore Ontology.   In the example above integrity could only be established when all parties in the furniture marketing, sales and supply chain establish a common definition of "material". 

schema.org works to address this challenge.  Bing, Google and Yahoo started schema.org in 2011 to support data markup.  We wish the furniture's folks would have used their definition for "material"


Common markup definitions is essential to interoperability.

CommerceCore Ontology Domain Attribution Foundation

CommerceCore Ontology provides foundational vocabulary for capturing and sharing markup between parties.

Things that need common markup




Ontology Objectives




Semantic World site does a great job of capturing these stages. link


The overall Knowledge Base is captured via T-Box, A-Box and C-Box




CommerceCore Ontology (CCO) 

CommerceCore Ontological Scope

Note that Packaged Business Capabilities (PBC's) represent an architectural construct for defining components that are used in solution assembly.  Each product vendor will establish slightly different contextual boundaries for their PBC's and associated API's.

CommerceCore Ontology Activity, Entity, and Agent definitions must transcend the artificial boundaries defined by specific vendor PBC's.   Note how the CommerceCore Activities align with Shopify PBC's.

It is important to distinguish between brand site digital experience scope and commerce scope.  The CommerceCore Ontology does not attempt to capture brand site non-commerce content and behavior.  The CMS PBC is responsible for maintaining a relationship mapping between brand site Artifacts and Catalog Artifacts.


CommerceCore Ontology Overview


CommerceCore Ontology Marketplace Entities and Agents

CommerceCore Execution Provenance Foundation

CommerceCore Specification Provenance Foundation

CommerceCore Activities

We are going to first focus on operational Activities, associated Entities and Agent Behavior.   Administration tasks, although important, will be described in a different document.


Consumer Activities

A Consumer engages a marketplace with a set of desired outcomes (outcome focused).

A Consumer has a Consumer Identity. Consumer Identity created via centralized solutions like Google Identity/Google Consumer User Account and Facebook Identity/User Account or via decentralized solutions that leverage standards like Ethereum Abstract Account.

A Consumer can have multiple types of Consumer Accounts.  One Consumer Account could be used for large purchases and have a strict security profile. A second Consumer Account might be used for family vacations that support family member sub-account relationships and lower dollar value transactions.  The Consumer Account is usually independent of the Marketplace.

Once a Consumer starts Shopping at a particular Marketplace they become a Customer of that Marketplace and a Customer Account is created.   That Customer Account might start as a "Guest" Customer Account and then transition to a "Authenticated" Customer Account when the Consumer presents their Identity credentials.


Desired Consumer Outcomes and Engagement

Brands establishing a shared understanding of Desired Consumer Outcomes is key to a successful Engagement.


Marketplace is responsible for helping match Consumer Desired Outcomes (Wants) with Provider goods and services (Assets).  Marketplaces can also reach out to marketplace providers and request dynamic Offers.

Customer Offer is added to the Shopping Cart as a Customer Bid.

Once the Customer Bid is accepted by the Provider and Consumer (obligation made) an Order is constructed with its associated Provider Fulfillment.

Fulfillment is associated to Desired Consumer Outcome (wants).

Consumer Membership

Memberships play an essential role in provider and marketplace consumer engagement.

These memberships can offer product/asset availability, pricing, and fulfillment. 



Membership Proofs passed to Marketplace and/or Provider are used to determine Offerings and Offering Asset Price.

Information (Membership and Member Attributes) is made available to Organization (Marketplace or Provider) to support offering creation, negotiation and fulfillment.

Provider Activities


Offerings


Marketplace Activities



Catalog

Commerce catalog definition: "A catalog organizes your products, SKUs, and collections in a hierarchy that reflects the way users will navigate to them on your store. A catalog contains collections, which in turn, contain products."

Catalog "Things"

The Store and Store Navigation is part of the overall site content and behavior.  Note that only certain site activities result in commerce related Activities.

Catalog "Activities" (users will ...)

As the user navigates, filters, and searches the Users Session Catalog is updated.   The storefront UI updates based on state changes in the Users Session Catalog.


The Catalog Ontology supports tracing User Session Catalog changes based on User Activity. 


Specification: "an act of describing or identifying something precisely"

We use Specification as a key abstraction. Specification is defined by a set of Specification Attributes and Specification Attribute Values. 


The Specification Attributes associated with a Catalog Category or Catalog Item are sometimes referred to as the Facets.

Attribution

GoodRelations Commerce Ontology captures Product Attribution via qualitativeProductOrServiceProperty and quantitativeProductOrServiceProperty.  

Qualitative Property has a Qualitative Value providing categorization of a Product like "Small", "Medium" and "Large".

Quantitative Property has a Quantitative Value providing units type, value, min value, max value.

Datatype Property is a simple scaler like String, Integer, or Float.

CommerceCore Ontology represents these types of relationships using a single concept called Attribution.  An Attribute relationship to a thing can be either qualitative (defined by group of values) or quantitative (defined by a single value or value range).  


Things that need common attribution semantics



Offering Activities


Difference between CommerceCore Ontology and other Commerce Ontologies like GoodRelations.    

Introducing the concept of an "Asset" greatly simplifies the solution complexity.  

The Offer represents an exchange of Assets.  The Offerer posts a Listing or Bid that includes Offer Items that the Offerer Owns.  For these Items the Offerer is expecting things in return which are defined by Consideration Items.

Price/Money is just another Asset referenced within an Offer Item or Consideration Item.  The Asset has an Owner and during Settlement Activities that Ownership will get transferred.

"Cash is a current asset and is the first line-item on a company's balance sheet. Cash is the most liquid type of asset and can be used to easily purchase other assets."

Offers relate to actual "Things" and not a Specification of a "Thing". 

The "Thing" might be an anticipation of an actual "Thing" in the future without knowing the specific inventory item yet.

Compare this to scheduling. In the begining we add a scheduled task to the activity even though we might not know the specific date. So we add an Asset to the Offer even though we might not know the actual inventory item. 


"Negotiation" Activity,  Matching

At some point in their online journey the user transitions from general browsing to focused "negotiations".  In an airlines site it is when they search for a particular "flight" giving a from/to location and time frame.  In a retail site it is when they search for or select a particular product.

Negotiations starts before the user is even aware of it.  Once the user shows intent and enters some criteria defining that intent the negotiations have started.

Within CommerceCore this intent is captured as a "Bid", also known as Demand.  The Bid starts with some set of criteria that defines the users interests.  At some point the Bid includes a "Bid Consideration" that asserts that there will be an eventual Asset that aligns with some initial high level Catalog Item Specification.  

The user activity of going from a general goods or service specification to an Asset Match is called matching.   The matching processes is initially guided by Catalog information, but quickly involves providers and specific provider listings.

The Cart "Bid" is added to the "Consumer Cart" once the intent is shown.  When the user first navigates to a Nike Shoe Product Page the system asserts that a "Bid" has been initiated, but a match to the specific Provider Listed Asset is not established yet.  

As the user answers questions like shoe size and color the system can eventually establish a match to the actual Listing Asset and place a hold on that Asset.  As the user answers questions providers can present asset availability and help narrow down the remaining questions that need to be asked to get a match.

The User will also set the amount of money that they will offer for the Asset (The Offer Item). They can accept the Providers Listing Price or if allowed, set their own amount.

Once the Bid has been matched to a Provider Asset and the user has signaled their agreement (example, add to cart) the Bid enters the state of "matched".


A Bundled Catalog Item would result in a Bid with multiple Consideration Items.

A Customer Bid and a Provider Listing is considered a "Contingent Obligation".  The Provider is not Obligated to deliver the Asset and the Customer is not Obligated to acquire the Asset.  It is contingent on both showing "Commitment" to the deal.  This commitment might come during checkout when the Provider assures they have availability of that Asset and the Customer commits to paying the money.  The commitment might also be a simple customer obligation to pay later once the service is rendered.  This commitment is usually codified in an agreement like a contract.

Once Commitment is shown by both parties a deal is reached and the deal (Bid and Listing) transition into an agreement called an "Order".   Think of "Order" as a kind of digital receipt.  Note that this transition to Order is the result of a commitment that can take many different forms.


Activities


Dynamic Offer Details


Offer Negotiation Details


Good overview of negotiation

https://aisel.aisnet.org/cgi/viewcontent.cgi?article=1057&context=ecis2005


Ordering Activities

An Order is simply an Offer where all parties have Committed to Specified Obligations.   The Offer has turned into an Agreement between parties.  This Agreement is defined as the Order.

The Order is typically sent forward to an Order Management System to be fulfilled.


Fulfillment Activities

Group of Orders is associated with a desired "Customer Outcome".   Customer Outcomes like "delivered correct product", "successfully completed service", or broader outcomes like successful "wedding", "landscaping", or "purchase of home".   

Over time the Customer might entertain a number of Offers, make a number of agreements (Orders) involving a number of things (Assets) with a number of Providers that are all associated with a particular desired Customer Outcome.


This is where it gets interesting.   

We just flipped the conversation from Offer/Order centric Contractual Obligations to Customer Outcomes centric Asset fulfillment. 

This is key.  The focus now becomes the process of fulfillment of goods, services and transferring money within the context of achieving Customer Outcomes.

Traditional retail commerce stops when the Order is taken and the customer has checked out and paid.

Our definition of commerce increases this scope to include fulfillment and achieving true desired customer outcomes.  Once the customer has achieve their desired outcomes we look at a settlement where all parties are released of their contractual obligations. 

IATA (Airline standards group) has the concept of "One Order".  All aspects of the customer flight/trip (Customer Outcome) are captured in "One Order".  I don't particularly like the name because it implies a airline carrier centric thing, but really it represents all the obligations all providers have to a Customer in the context of their trip.   

In the fulfillment and settlement space the context of the "Customer Outcome" is important.  The initial commitment (buy/sell) usually happens way ahead of the actual fulfillment and settlement.  The fulfillment and settlement are usually correlated in time and space with achieving successful Customer Outcomes.


Financial Transaction

A financial transaction is an agreement, or communication, between a buyer and seller to exchange goods, services, or assets for payment.   In our model "money" is just another type of Asset.  So a Financial Transaction is a "Fulfillment Item" where two parties exchange Assets.


Settlement Activities

Settlement happens when all obligations are discharged (fulfilled).

Settlement Process involves operations leading to settlement.

"Discharge from obligation to pay"
"Discharge from obligation to deliver or fulfill"


Settlement starts when you achieve a Full or Partial Customer Outcome.

Examples of how Achieving a Customer Outcome triggers a Full or Partial Settlement


Settlement Reports:  Similar to a Folio

Innovations

Decentralized Behavior (Activities with Shared Authority)

Airline industry, and tourism in general, have been struggling with who is the authority regarding a particular service offering, selling and delivering that offering.  Suppliers like American Airline says I am the one providing the service so should control offering and pricing.  Retailers who aggregate airline with other services feel they should control the customer vacation experience.  Aggregators who bring together offerings and distribute them to Retailers feel they should be in charge. 

Blockchain solutions like Ethereum provide smart contracts which provide shared authority where providers, aggregators, retailers agree to core marketplace behavior.   

Decentralized Entities (Catalog, Category, Product, Asset, Offer, Order, Transaction)

...


Decentralized Agents

 ...

Summary

Our goal is to bring together core principles found in legacy commerce solutions and establish a unifying ontology.   This ontology will provide a map that will show where disruptive marketplace concepts align with core commerce principles.

Key commerce innovations found in Seaport, IATA Airline standards, Commercetools, TalonOne and ODOO are breaking new ground.  MACH Alliance is proposing new ways to assemble these components into commerce solutions.

All this requires a shared understanding and language of core commerce principles.  CommerceCore Ontology will provide that common language. 

Reference Ontologies


GoodRelations Ontology

good use-case for goodrelations link

Service Ontology link


Life Event Service link

OWL-S

Accounting Ontology link

T-Box and A-Box description


gist Accounting Ontology link


good overview of product sell

https://www.semanticarts.com/a-data-centric-approach-to-managing-customer-data/

https://www.semanticarts.com/videos/


google search => site:semanticworld.com commerce


https://semanticworld.com/accounting/documentation/#Liability

FIBO Ontology link

BFO Ontology

CCO - Common Core Ontology  link

middle level ontology

uses BFO upper ontology

viewer for the entire Common Core Ontology

https://matportal.org/ontologies/CCO?p=classes




Schema.org

Product.  CommerceCore has Product as simply a specification

Offer/Demand(bid).  

Order/Order Item

NFT Ontology Extensions

NFT Simple Ontology, Asset types link

NFT Taxonomy link

diagram

Airline Industry (One-Order) link