The Commerce Transaction Ontology represents orders, line items, buyers, refunds, payment, fulfillment, lifecycle, revenue, and cost of goods in monetary terms shared with advertising measurement.

This is an unofficial specification of version 0.1.0 of this Inferal ontology module. The vocabulary remains a draft.

Feedback should be sent to contact@inferal.com.

The key words MUST, MUST NOT, SHOULD, SHOULD NOT, and MAY in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals.

RDF data conforms to the vocabulary when it uses the terms according to their normative meanings below. A data producer claiming closed-world conformance MUST also satisfy the SHACL graph distributed with this module. OWL and RDFS entailment do not imply that an omitted value is false.

Namespace

PrefixNamespace IRI
ctxhttps://ontology.inferal.com/modules/commerce-transaction/

Scope

This module covers completed and incomplete orders, their totals and placement times, line items and quantities, buyers and buyer status, refunds as amount-bearing events, and independent payment, fulfillment, and lifecycle axes.

Advertising attribution, blended channel revenue, buyer lifetime, payment instruments, tax, discounts, shipping, carrier events, and inventory movements are outside this module.

Competency Questions

  1. Which orders are paid but not yet fulfilled?
  2. What is the average order value?
  3. What proportion of revenue was returned as refunds?
  4. What gross margin did the sold line items carry?
  5. Which products did an order contain and in what quantities?
  6. How much revenue came from first-time buyers compared with returning buyers?

Conceptual Model

Order and line-item economics

An order records the transaction total, buyer, placement instant, and independent states. Each line item identifies one product, quantity, revenue amount, and optional cost of goods so product-level margin can be computed.

Independent state axes

Payment, fulfillment, and lifecycle answer different questions. Producers MUST state all three and MUST NOT substitute a merged schema.org order status for them. An incomplete basket is not an unpaid completed order.

Refund as an event

A refund identifies the order it reverses, the amount returned, and the refund instant. Consumers MUST NOT infer a refund amount from payment state alone because partial refunds preserve part of the original revenue.

Term Reference

Every term in this section is exported for cross-reference. Definitions state the term's meaning; the relations column summarizes declared RDFS and SKOS links. Closed-world cardinalities are specified separately in Validation.

Classes

TermKindNormative meaningRelations
ctx:Buyer Class The party an order was placed by, considered as a purchaser rather than as an organisation or a person. No local domain or range restriction.
ctx:BuyerStatus Class Whether an order was a buyer's first purchase or a later one. Subclass of: skos:Concept
ctx:FulfillmentState Class How far an order has progressed toward reaching the buyer, from nothing sent through to fully delivered or returned to stock. Subclass of: skos:Concept
ctx:LineItem Class One product at one quantity within an order, carrying what it sold for and what it cost to supply. Subclass of: schema:OrderItem
ctx:Order Class A completed purchase: what a buyer bought, at what total, when, and in what state of payment and delivery. Subclass of: prov:Entity, schema:Order
ctx:OrderLifecycleState Class Whether the order exists as a real transaction, was started and never completed, or has been discarded. Subclass of: skos:Concept
ctx:PaymentState Class How far an order has progressed toward being paid for, from awaiting payment through to settled or reversed. Subclass of: skos:Concept
ctx:Refund Class A return of money against an order, for some amount that may be less than the order's total. Subclass of: prov:Entity

Properties

TermKindNormative meaningRelations
ctx:buyerStatus Property Whether this buyer was purchasing for the first time. Domain: ctx:Buyer; Range: ctx:BuyerStatus
ctx:costOfGoods Property What supplying this line cost, so margin is the difference between it and the line's revenue. Domain: ctx:LineItem; Range: adm:MonetaryAmount
ctx:fulfillmentState Property How far this order has progressed toward reaching the buyer. Domain: ctx:Order; Range: ctx:FulfillmentState
ctx:lineItemProduct Property The product this line item sold, reusing the product the commercial vocabulary already defines so the catalogue and the sales ledger name the same thing. Domain: ctx:LineItem; Range: cmi:Product
ctx:lineItemQuantity Property How many units of the product this line sold. Required for unit economics: two of one item and one of another are not the same order. Subproperty of: schema:orderQuantity; Domain: ctx:LineItem; Range: xsd:decimal
ctx:lineItemRevenue Property What this line sold for in total, after any discount and before any refund. Domain: ctx:LineItem; Range: adm:MonetaryAmount
ctx:orderContains Property A line item within this order. Repeatable: an order of several products is several line items. Subproperty of: schema:orderedItem; Domain: ctx:Order; Range: ctx:LineItem
ctx:orderIdentifier Property The merchant's own number for this order, as they issue it. Domain: ctx:Order; Range: xsd:string
ctx:orderLifecycle Property Whether this order exists as a real transaction, an incomplete one, or a discarded record. Domain: ctx:Order; Range: ctx:OrderLifecycleState
ctx:orderTotal Property What the buyer was charged in full, reusing the shared monetary amount so revenue and advertising spend are the same kind of quantity. Domain: ctx:Order; Range: adm:MonetaryAmount
ctx:paymentState Property How far this order has progressed toward being paid for. Domain: ctx:Order; Range: ctx:PaymentState
ctx:placedAt Property The instant the order was placed, which is what a reporting window is matched against. Domain: ctx:Order; Range: time:Instant
ctx:placedBy Property The buyer who placed this order. Domain: ctx:Order; Range: ctx:Buyer
ctx:refundedAmount Property How much money this refund returned, which may be less than the order's total. Domain: ctx:Refund; Range: adm:MonetaryAmount
ctx:refundedAt Property The instant the refund was issued, which may fall in a later reporting window than the order it reverses. Domain: ctx:Refund; Range: time:Instant
ctx:refundOf Property The order this refund reverses. Domain: ctx:Refund; Range: ctx:Order

Controlled concepts

TermKindNormative meaningRelations
ctx:authorised Concept Funds are reserved against the buyer's method but not yet captured. Scheme: ctx:PaymentStateScheme
ctx:awaitingCollection Concept Everything is ready and waiting for the buyer to collect it. Scheme: ctx:FulfillmentStateScheme
ctx:awaitingPayment Concept Payment is due and has not been taken. Scheme: ctx:PaymentStateScheme
ctx:cancelledOrder Concept A real transaction that was called off. Distinct from an incomplete one, which never became a transaction, and from a refund, which returns money on one that stands. Scheme: ctx:OrderLifecycleScheme
ctx:delivered Concept Everything has reached the buyer. Scheme: ctx:FulfillmentStateScheme
ctx:discardedOrder Concept Removed from the working set by the merchant. Its history may survive it. Scheme: ctx:OrderLifecycleScheme
ctx:firstTimeBuyer Concept Had not bought before. The acquisition cost of this order is what a new-customer figure measures. Scheme: ctx:BuyerStatusScheme
ctx:fullyRefunded Concept Everything taken has been returned. The order still happened, and its line items still sold, which is why this is a payment state rather than a lifecycle one. Scheme: ctx:PaymentStateScheme
ctx:incompleteOrder Concept Started and never completed, such as an abandoned basket. Not a sale, and counting it as an unpaid order overstates outstanding revenue. Scheme: ctx:OrderLifecycleScheme
ctx:inTransit Concept Everything has been despatched and is on its way. Scheme: ctx:FulfillmentStateScheme
ctx:paid Concept The full total has been taken. Scheme: ctx:PaymentStateScheme
ctx:partlyFulfilled Concept Some lines have been sent and others have not. Scheme: ctx:FulfillmentStateScheme
ctx:partlyPaid Concept Some of the total has been taken and some remains outstanding, as with a deposit. Scheme: ctx:PaymentStateScheme
ctx:partlyRefunded Concept Some money has been returned and some retained. The amount lives on the refund; this records only that the order is in that condition. Scheme: ctx:PaymentStateScheme
ctx:paymentVoided Concept An authorisation was released without ever being captured. Scheme: ctx:PaymentStateScheme
ctx:placedOrder Concept A real transaction, whatever its payment and fulfilment states. Scheme: ctx:OrderLifecycleScheme
ctx:returnedToStock Concept Goods came back and were restocked. Whether money followed is a separate question answered on the payment axis. Scheme: ctx:FulfillmentStateScheme
ctx:returningBuyer Concept Had bought before. Selling to them costs less than winning them did, which is why blending the two hides both numbers. Scheme: ctx:BuyerStatusScheme
ctx:unfulfilled Concept Nothing has been sent. Scheme: ctx:FulfillmentStateScheme

Concept schemes

TermKindNormative meaningRelations
ctx:BuyerStatusScheme Concept scheme Whether a purchase was a buyer's first. No local domain or range restriction.
ctx:FulfillmentStateScheme Concept scheme How far an order has progressed toward reaching the buyer. No local domain or range restriction.
ctx:OrderLifecycleScheme Concept scheme Whether an order exists as a real transaction. No local domain or range restriction.
ctx:PaymentStateScheme Concept scheme How far an order has progressed toward being paid for. No local domain or range restriction.

Validation

The module's SHACL constraints provide the closed-world conformance profile. The following requirements summarize the constraints that affect ordinary data producers.

Examples

Extension and Interoperability

Controlled vocabularies use SKOS so provider profiles MAY add narrower or matched concepts without replacing the shared classes. Extensions MUST preserve the meanings and constraints of terms they reuse. A mapping MUST NOT assert equivalence merely because two provider fields have similar labels.

Privacy and Security Considerations

Order identifiers, buyer links, purchase history, and refund events can be personal or commercially sensitive. Publishers SHOULD use pseudonymous buyer resources where possible and enforce applicable retention and access policies.