CommerceCore Ontology

CommerceCore Ontology provides the foundation for building specialized commercial domain ontologies.   Our goal is to provide a generic set of semantic building blocks that can be extended.  

Transactional Provenance

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

This requires the ontology capture Agent/Entity interactions and Activity Behavioristics. Our Ontology leverages the powerful and proven W3C PROV-O and P-Plan Ontologies. 

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

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

Companies like Shopify, CommerceTools, SiteCore, and ElasticPath 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 components.  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.  Composability allows for niche innovators, like Talon.One who provide focused differentiated capabilities, to pick their "platforms" they want to support.

Over the past few years the leading monolithic commerce platforms like Salesforce Commerce Cloud, SAP Commerce Cloud and  Oracle Commerce  look increasingly similar.  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 it was.     

The best place to start this "eCommerce OS" revolution is to build out a CommerceCore ontology that draws out these PBC Interfaces and establish 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.

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.   eCommerce 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 sold and 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.  

Marketplaces (eCommerce Channels)

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.  

A marketplace scope encompasses discovery, offer, negotiation, order, fulfillment, settlement, membership and loyalty. 

Businesses can leverage one or more marketplace "sales channels" to serve their customers. 

CommerceCore Ontology focuses primarily on Consumer Facing Channels

Types of Consumer facing Marketplaces

• Business-to-Consumer (B2C)
  Online platform where multiple businesses list and sell their products to consumers

• Direct-to-Customer (D2C)
  Allows brands or manufacturers to sell their products directly to consumers, bypassing third-party retailers or intermediaries.

• Peer-to-Peer (P2P)
  Allow individuals to buy and sell goods or services directly with each other, often through a third-party platform that facilitates transactions.

Business-to-Consumer (B2C) Marketplaces

Larger Marketplace (i.e. Amazon and eBay)

Advantages

• Lower customer acquisition cost (CAC). Customer base and search traffic

• Lower startup costs.  Easy to setup and manage

• Lower operating costs. Handle Payment, Handle fulfillment (shipping)

• Built to scale with the business growth

• High volume, lower margin

Disadvantages

• Reduced direct loyalty to brand.  Transactional.  Lower Lifetime Value (LTV)

• Risk of de-platform

• Risk of competitor squeezing margins

• Limited ability to re-market and develop customer relationship

• Platform fee’s

Social Marketplace (i.e. TikTok, Instagram Shopping, Facebook Marketplace), Social Shopping

Advantages

• Built-in audience.  Potential low Customer Acquisition Cost (CAC)

• Product discovery and social engagement.  Influencers

• Early-stage advantages of things like free shipping. Coupons to jump-start adoption. 

• Community driven with higher conversion rates.  Trust in influencers.  Viral nature of community.

• Life-Time-Value (LTV) is dependent on building community around product or brand.  Opportunity to build brand communities

Disadvantages

• Competition for attention to product or value proposition

Managed Marketplace or Vertically integrated marketplace (i.e. TripAdvisor, Carvana, Zillow Offers, RedfinNow)

Involved in the transaction process, often handing logistics, pricing, quality control and or fulfillment.

Advantages

• Actively manages transaction.  

Two-sided Marketplace (i.e. OpenTable, Airbnb, Uber, Etsy)

Platform that connects buyers and sellers but does not take ownership of inventory or heavily manage transactions.

Advantages

• Matchmaker

Agent-Intent Driven Marketplaces and Digital Assistants
(i.e.  OpenAI Operator, Google Assistant, Microsoft Copilot)

Personalized, automated, and real-time shopping experiences tailored to individual user intent rather than just broad product discovery.

An agent-intent driven marketplace is an eCommerce ecosystem where AI-powered digital assistants act as intermediaries between consumers and brands. Instead of consumers manually searching for products, intelligent agents predict needs, engage in natural conversations, and curate recommendations based on real-time intent.

Advantages

• Value (Desired outcomes driven). Personalization. Understands customer preferences, purchase history, and contextual needs.

• Increased conversion rate.  Makes proactive recommendations suggesting the right products at the right time. 

• Adjust pricing on a real-time bases.   Negotiating trade-offs (price vs quality) on the consumer's behalf.  Taking into account promotions, membership and loyalty programs.  Interfacing with pricing agents

• Integrated with backend provider dynamic availability

• Enhanced privacy.  Privacy by Design - only sharing the minimum necessary data between agents to achieve the outcome.  Privacy preserving through sharing attestations and verifiable credentials.

• Enhanced trust through Consumer and Business Identity Management

• Reaches into other parts of value chain. Demand forecasting, inventory, fulfillment, and customer service.

Disadvantages

• Transactional.  Reduced visibility to brand. 

Direct-to-Consumer (D2C) Marketplace

Allows brands or manufacturers to sell their products directly to consumers, bypassing third-party retailers or intermediaries.

Advantages

• Build relationship and loyalty to brand.  More control

• Supports relationship and loyalty development.  Potential for higher lifetime value (LTV)

• Operating costs can be lower.  Depending on eCommerce technology strategy.  No middleman

• Easier to integrate brick-and-mortar retail or wholesale partnerships (additional revenue streams)

• Complements Two-Sided and Agent Intent Driven Marketplace

• Support multiple products and services under company brand

• Higher Margin, Lower volume

Disadvantage

• Cost-of-Customer Acquisition is higher because no built in platform audience.  Cost of digital ad’s, email marketing, etc. is high.  Require omni-channel approach.

• Life-time-value is more difficult.  Product and Brand must be sticky to bring them back.  

• Development and operating costs are higher, but much lower do to platforms like Shopify and Square.

SaaS Platforms (Shopify, Square, ...)

Monolithic eCommerce Platforms

Custom Built Platforms based on MACH or Open Source

Peer-to-Peer (P2P) Marketplace

Traditionally P2P has referred to centralized marketplaces like eBay, Etsy and Facebook Marketplace where individuals can connect and transact on specific items (Assets).

More modern concepts of P2P include Decentralized P2P Marketplaces where there is no central authority.    Offers, Bids, Negotiations, Settlements involving multiple assets between multiple parties can happen through these decentralized platforms. As AI continues to advance, Agent-Intent Driven Engagement will transform decentralized P2P marketplaces by making them smarter, faster, and more secure. 

With increasing adoption of Web3, AI agents, and blockchain technology, the next generation of P2P marketplaces could become fully autonomous ecosystems where intelligent agents handle everything from search and negotiation to verification and dispute resolution—ushering in a new era of decentralized commerce.

Marketplace Transaction Types

• Traditional Transaction, example Retail Storefront (asset for money)

• Bartering (trade goods and service without the use of money)

• Auction (goes to the "highest price" buyer is willing to pay - the bid)

  • English or Open Ascending Auction (bids happen in real time and are visible to all, starts at an initial value and goes up)

  • Penny Auction (People pay to participate in the auction and bid starts at penny)

  • Dutch Auction or Open Descending Auction.  Bid starts at a high value and comes down until someone is willing to bid.

  • Japanese Auction. They all join in the bid and at some point leave.  The last person standing gets the item.

  • Reverse Auction or Buyer-Determined Auction.  It is the sellers instead of the buyers that make the bid.

  • Sealed Bid Auctions or Silent Auction.   They don't see what other bidders bid.  Highest bid wins.

  • Reserve Auction.  Seller determines the minimum bid they are willing to sell at.

  • Absolute Auction.  Seller will take any price bid

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.   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.

CommerceCore Ontology classifies a Single Business Commerce Site as a type of Marketplace (D2C 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:

• eCommerce commercial platforms support a single seller

• marketplaces commercial platforms support multiple sellers

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.

CommerceCore Ontology classifies an Exchange as an Asset 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.   Where 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.

Emerging AI-driven personalization and chat-based eCommerce.

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.

• Brands need to come along side consumers in their quest for particular outcomes. 

• Recognize Consumer Privacy.  Consumer data, desired consumer outcomes, plans, artifacts, etc. in a consumer owned location like "digital wallet".  Customer will securely share information as needed with brands.

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.

• Realtors believe they own 100% of a house hunters search.  Sometimes requiring a contract to that effect.

• Airline owns 100% of a customers airline travels.  Providing a full roundtrip "ticket" to destination and back.   Airlines are now trying to consolidate airline tickets with car rental, hospitality and vacation activities.  Which on its surface would be good but they are centralizing the transactions at the airline.

• Landscaper owns 100% of the next project.  The bigger the better.  They will source the design, labor and material needed.  One stop shopping.   50% down.

• Wedding planner owns 100% of the wedding experience.  They own the plan, purchases and execution.

• Expedia, packages the whole vacation experience for you.  You select the package and then show up.   You are provided a list of vacation options that Expedia has pre-qualified as being good. 

Emergence of the "AI Digital Natives".  These shoppers act differently.  

They expect the conversation to start with: "What can I help you do?"

Consumer facing Agentic AI Solutions (Shopping Assistants) like ChatGPT Operator.  

Agentic AI refers to AI systems that can operate with a degree of autonomy, making decisions, executing tasks, and adapting dynamically based on real-world feedback.

Traditional D2C storefronts are struggling

D2C (direct-to-consumer) eCommerce websites have faced significant challenges in recent years, leading some to declare their decline. Here are some key reasons for this shift:

Rising Customer Acquisition Costs (CAC)

• Paid digital ads (Google, Facebook, Instagram) have become more expensive and less effective due to increasing competition.

• Browser cross site cookie tracking and Apple’s iOS 14.5 privacy updates have limited tracking, making targeted ads harder to optimize.

• Brands now struggle to acquire new customers profitably.

Emergence of AI-driven personalization and chat-based eCommerce.

Shift to B2C Marketplaces (Amazon, Walmart, Target)

• Consumers prefer convenience and trust from established marketplaces.

• Free shipping, fast delivery, and easy returns on marketplaces outcompete most D2C brands.

• Many D2C brands are now forced to list on Amazon or other platforms to stay relevant.

Consumer Behavior Shift

• Online shopping preferences have evolved, with more consumers choosing to buy through social media (TikTok Shop, Instagram, Facebook Marketplace).

• Live shopping and influencer-driven sales have become more effective than traditional D2C storefronts.

Increased Competition

• The rise of Shopify and other eCommerce tools made launching D2C brands easier, leading to market saturation.

• Generic products with private-label branding have flooded the market, reducing differentiation.

Omnichannel strategies are needed.
Lifetime Value via Loyalty programs, outcomes driven engagement (end-to-end relationships) and extended product offerings are needed
Build brand IP, customer base and product innovation and differentiation 

Decoupled Provider

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

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

Key Provider Capabilities

• A Marketplace Catalog is associated with Offerings from multiple providers.  Marketplace Catalog must be described (specifications - categories, product specs, variant specs) in a way Providers can classify their Things in terms of.

• A Provider publishes Offerings to a Marketplace.  Catalog Product availability is driven by Provider Offerings.

• A Marketplace can request Dynamic Offers from Providers based on Consumer wants. 

• A Marketplace can validate Catalog Product and Variant availability.

• A Marketplace manages Customers, Provider Listings, Customer Bids, Customer Carts and creates Customer Orders.  A Provider fulfills against these Marketplace Orders.

"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.

• Consumer trusting Provider to meet Desired Consumer Outcomes

• Provider trusting Consumer to meet agreed upon Obligations (usually payment) 

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

• What if you as a Customer totally trusted the Provider to deliver on your desired outcomes?

• What if you as a Provider totally trusted the Consumer to honor their agreed upon obligations?

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

• Community and Identity

  • Sporting Fan Groups

  • Member of Pacific Crest Trail Association

  • Member of Political Party

  • Member of Boulder Country Club, Social Clubs

  • Member of Marketplace, Wine, Golf

  • Decentralized Autonomous Organization (DAO)

• Loyalty Programs

  • United Club Membership

  • Lowe’s MVPs Pro Rewards Program

  • Starbucks Odyssey Membership

• Trust and Worthiness

  • Privacy Pools via "association sets" (we can be trusted as being "not bad actors")

  • Proof-Of-Stake (we can be trusted)

  • Credit Membership Pool (we can be trusted to pay)

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)

• Company brand, ability to deliver, history of delivery

• Other customer reviews

• Quality of experience (physical and digital)

• ...

Trust building over many engagements (loyalty)

• Desired Consumer Outcomes are met or exceeded during Consumer Event

• Desired Customer Outcomes are met or exceeded during Customer Engagement with Provider

• Provider gives Loyalty related Rewards (points, ...) relating to Customer Engagement

Trust and Loyalty building within a community (membership)

• Establishing Identity among a group of people.  Badges, Certifications, Achievements

• Sharing that membership externally to folks outside community

Provider trusting Consumer

• Consumer can meet obligations (proof of "line-of-credit")

• Consumer committed to engagement journey (learn together with provider)

• Consumer becomes ambassador for Provider Offerings (and outcomes achieved).  Positive Reviews,  Tell-a-friend, ...

• ...

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." 

• Digital ID as credential.

• Digital ID as user.

• Digital ID as character.

• Digital ID as reputation.

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.

• Person maintains their own "Membership Proof".  Proof they are a member of a Group and receive associated benefits.   The Group does not know who the members are.  The group might originally grant the person a "Membership Proof", but does not keep track of their membership.

• Person maintains Membership Information and Claims that the Group can reference.  The Group maintains no identifying data.  Person maintains 100% custodial control over 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

• Choice: Choose to do something based on my beliefs and values

• Regulatory Compliance: Regulated to do something based on others beliefs and values

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:

• Consumer

• Provider

• Marketplace (shared custody between Consumer and Provider)

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

• Can data be captured, stored and exchanged securely?  No other parties involved.

• Who has custody of the data?  Customer Data, Provider Data, Marketplace Data.

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:

• Asset theft: An Asset was stolen or extorted from its owner.  Possession "Ownership" Transferred

• Bad Assets:  Curtain types of Assets are indicative of bad behavior.  Like "escort service" transaction.  This data is fused with other source data indicating "bad" behavior.

• Bad Actors:  Actor relationship to Assets or other Actors.  Person buys a ticket to Columbia.  Bad guy transacts with suspicious guy.  This data is fused with other sources data indicating "bad" behavior.

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.

eCommerce 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

• Product, Variant Specifications

• Category (Taxonomy) Profiles

• Asset Profiles

• Facetted Filter

• Offer Criteria

• Person, Organization, Company Profiles

Ontology Objectives

• Clear contextual boundary for all things "Catalog" that capture the traditional commerce grouping and product abstractions of Category, Product and Product Variant.  Catalog also characterizes relationships between products like accessory, cross-sell, and up-sell.

• Separate Offerings (Provider Listings, Customer Bids), from Catalog, to capture all sell/buy requests.  Offerings will drive Catalog availability.   A home owner might post "accepting offers" without even posting a price (similar to "coming soon").  Then a potential buyer could post an offer to buy the house even in the "coming soon" state.  There are numerous types of marketplace interactions that are captured by this Offering metaphor.

• Specific Customer Order semantics that capture what is committed to and needs to be fulfilled.  Order starts to be defined during the shopping phase and gets finalized once all things are fulfilled.   A customer shopping period might be minutes, days, weeks or months.  A Wedding Order might start with consulting services and ends with the customer applying a tip to say thanks. 

• Fulfillment of Order Obligations.  Providers are obligated to provide goods and services.  Customers are obligated to pay for those goods and services.  This is the most underserved phase in most commerce solutions.  Currently customers have very little visibility to what they really bought (digital receipt), how it will be fulfilled and by whom, how they can modify or cancel things.  Currently brands have very little visibility into the fulfillment process and no visibility into how their delivered asset play in the re-seller marketplace.   

• Ledger Transactions (Settlement) are clearly separated from Offering, Order and Fulfillment.  These debit and credit operations can involve many types of transactions in the settlement process.  The Order captures the agreed upon parts of the exchange.  The Transaction captures when the various parts of the transaction are put on the general ledger.

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

• T-Box (“T” for “terminology” or perhaps “theory”) 

• A-Box (“A” for “assertion”),  John hasChild Mary

• C-Box ("C" for "category"), hierarchical taxonomy

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).

• I want new tires that work well in the snow

• I want help planning my wedding

• I want to trade my Taylor Swift Concert ticket for today for a Concert in a week from now   

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.

• The Consumer is at the Center (Outcome focused). 

• Brands come along side Consumer in reaching Desired Consumer Outcomes (wants)

Desired Consumer Outcomes and Engagement

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

• Consumers do not always know what they want at the beginning

• Consumers do not always know who can best support them

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. 

• Veteran

• Senior Citizen

• Chase Sapphire Preferred Card

• TPC Premier Golf Membership

• 20% Colorado Golf Discount Pass

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"

• store

• store navigation

• collections (category)

• products, product variants (SKUs), assets

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 ...)

• Taxonomy Navigation (Category, Product, Product Variant (SKU), Asset) to set Context

• Natural Language Search within Context

• Facetted Filtering (filter based on attribution) within Context

• Sort

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

• Product, Variant Specifications

• Category (Taxonomy) Profiles

• Asset Profiles

• Facetted Filter

• Offer Criteria

• Person, Organization, Company Profiles

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

• Provider publishes Listings to Store,  viewed in conjunction with Store Catalog

  • Provider publishes a listing to a store.  Includes Catalog Item specification.

  • Reseller publishes a listing to a store.  Includes Catalog Item specification.

• Customer places a Bid (demand) for goods and services presented in the Store Catalog

  • Store Provider Listings are matched against those Bids based on Bid criteria

  • Provider can dynamically build a tailored offering to Bid (or Demand)

• Customer places a Bid for a specific Asset or Demands directed toward specific Provider

  • Customer sends bid directly to Asset Owner

  • Customer places an criteria based Bid and Providers respond.  Loosely based on Store Catalog.  Leverage Natural Language Search and matching.

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

• Correct product is delivered and customer is happy.  Customer relieves Provider of obligation.  

• Service Obligation is fulfilled to Customers satisfaction. 

• Wedding is fully booked and planned (partial settlement).  Wedding is complete (full settlement)

• Landscaping design is complete (partial settlement).  Landscape project is complete (full settlement)

• Trip is fully booked (partial booking settlement).  Trip is complete (full folio settlement)

• Sofa has been delivered (full 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

Enterprise Ontology (not gist)

https://www.aiai.ed.ac.uk/project/pub/projects/enterprise/ontology/v1-md31-pub.pdf

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

examples of use

https://www.youtube.com/watch?v=lbR8UzlF9B8

why ontology

good overview

https://www.google.com/search?q=gist+ontology&sca_esv=556757575&rlz=1C1RXQR_enUS1021US1021&source=lnt&tbs=qdr:y&sa=X&ved=2ahUKEwjp17GSqdyAAxUjM30KHY7LBE4QpwV6BAgDEAs&biw=1470&bih=701&dpr=2.5#fpstate=ive&vld=cid:7ef755ce,vid:pgRztFdv4aI

Schema.org

Product.  CommerceCore has Product as simply a specification

• Product is a tangible "Thing" and ProductModel (derived from Product) is a specification.  

• Product can be a variant with a sku

• ProductGroup (derived from Product) is the thing that groups Products (variants)

• ProductCollection.  (not derived from Product) is a collection of Products

Offer/Demand(bid).  

Order/Order Item

NFT Ontology Extensions

NFT Simple Ontology, Asset types link

NFT Taxonomy link

diagram

Direct-To-Consumer Focus

https://futureonchain.com/direct-to-consumer-web3-tech-stack/

Airline Industry (One-Order) link