Inferal Commerce Transaction Ontology

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

Prefix	Namespace IRI
`ctx`	`https://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

Which orders are paid but not yet fulfilled?
What is the average order value?
What proportion of revenue was returned as refunds?
What gross margin did the sold line items carry?
Which products did an order contain and in what quantities?
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, whole-line revenue and optional whole-line cost of goods. A declared source selection and eligibility policy qualify known-comparable product/currency subtotals; missing costs remain visible in coverage.

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.

Identifier Scope and Inference

A merchant order number and placement instant qualify a purchase without establishing universal identity across merchant scope. An order and refund instant also leave native refund event identity unassessed: distinct partial refund events can occur at the same instant. Consumers SHOULD retain source-qualified order and refund IRIs and provenance. Monetary fields and the independent payment, fulfillment and order lifecycle axes retain their meaning.

The qualification boundary is fresh OWL RL closure over the selected graph containing this vocabulary and its addendum together with the advertising measurement vocabulary and addendum. Synthetic purchases and reversals share named instant objects, with restored-key positive controls exercising identity inference. RDFLib and Jena SELECT execution on the same standard RDF transport view of that closure qualifies query answers; Jena is not a second OWL reasoner. Full import closure, client adoption and observed production collisions require independent evidence.

Withdrawing identity keys cannot retract stored owl:sameAs, reconstruct merged records or disable older keys still loaded from another graph. Consumers SHOULD establish fresh closure from selected asserted sources and review provenance-aware reconstruction before persistent adoption. Classifying buyers across successive purchases requires separate purchase-context and history evidence.

The full reasoning closure remains available for identity and SHACL checks. Transport omits only derived literal-subject triples and retains every legal RDF triple, including literal objects, blank-node lists and source links. The qualification rejects malformed asserted RDF. RDFLib verifies round-trip graph parity; Jena independently verifies SELECT answer bags, with no independent OWL reasoning by Jena.

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

Term	Kind	Normative meaning	Relations
`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

Term	Kind	Normative meaning	Relations
`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

Term	Kind	Normative meaning	Relations
`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

Term	Kind	Normative meaning	Relations
`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.

An order MUST have exactly one identifier, buyer, placement instant, total, payment state, fulfillment state, and lifecycle state.
An order MAY contain multiple line items and MUST NOT use the inherited schema.org merged order-status property.
A line item MUST identify exactly one product, quantity, and revenue amount; it MAY identify one cost-of-goods amount and MUST NOT use the merged item-status property.
A buyer MUST have exactly one buyer status.
A refund MUST identify exactly one order, refunded monetary amount, and refund instant.

Examples

@prefix ctx: <https://ontology.inferal.com/modules/commerce-transaction/> .
@prefix adm: <https://ontology.inferal.com/modules/advertising-measurement/> .
@prefix ex: <https://example.com/commerce-transaction/> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .

ex:order a ctx:Order ;
    ctx:orderIdentifier "NW-10241" ;
    ctx:placedBy ex:buyer ;
    ctx:placedAt ex:ordered-at ;
    ctx:orderTotal ex:total ;
    ctx:paymentState ctx:partlyRefunded ;
    ctx:fulfillmentState ctx:delivered ;
    ctx:orderLifecycle ctx:placedOrder ;
    ctx:orderContains ex:line .

ex:line a ctx:LineItem ;
    ctx:lineItemProduct ex:jacket ;
    ctx:lineItemQuantity "1"^^xsd:decimal ;
    ctx:lineItemRevenue ex:line-revenue .

ex:refund a ctx:Refund ;
    ctx:refundOf ex:order ;
    ctx:refundedAmount ex:refund-amount ;
    ctx:refundedAt ex:refunded-at .

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.

Qualified margin generation

Revenue and cost of goods are whole-line amounts and MUST NOT be multiplied by quantity again.

Consumers MUST select the explicit retained source and assessment graphs; a default union is not a qualified accounting source.

Missing costs and currencies MUST remain unknown evidence rather than zero or an inferred currency.

Merchant selection, accounting policy and currency support remain caller declarations; currency shape conformance does not verify ISO membership.

Known-comparable subtotals MUST NOT establish net profit, refund-adjusted margin, advertising attribution, currentness or complete history.

Generated datasets, answer bags and output hashes MUST be reproduced from the actual queries and source recipe; editing outputs is not a replay.

Placement qualification supports timezone-bearing Gregorian timestamps in years 0001 through 9999 with exact microsecond precision; unsupported precision remains unassessed and unsupported supplied bounds are rejected.

Receipts MUST NOT be treated as independent source attestation; qualified answers require re-execution over the pinned sources and interpretation package.

Qualified selected-order refund share

The selected order set uses the full buyer charge as its denominator. Eligible orders with no observed refunds remain in that denominator, and distinct qualified refund events contribute once each.

Merchant scope, native identity keys, revision evidence, currency support and completeness are supplied declarations. A source handle or matching amount and instant does not independently establish native purchase or refund identity.

Refund history is declared for each order through the explicit refund-event cutoff. Missing records, uncertain owners, identity conflicts, unsupported values and partial history remain diagnostic evidence and block a complete selected-set ratio when their relevance cannot be ruled out.

Order selection coverage and refund history are independent. Even a caller-declared complete order selection produces a ratio for the selected order set and does not establish all purchases or a complete merchant-window ledger.

Selected represented revisions supply the observed values and current represented admission states. They do not reconstruct historical revisions or establish the payment state at purchase time; refunds on older unselected order revisions retain their raw ownership and remain unassessed when reconciliation is unsupported.

Amounts qualify only with unique finite decimal values and exact supported currency tokens. Missing currencies remain unknown, mixed currencies are not converted, and spelling conformance does not establish ISO currency membership.

A zero denominator has no defined ratio and retains a diagnostic. An explicitly admitted signed algebra retains its signed exact pair; it is not an economic returned share, and over-refund diagnostics require a positive charge and nonnegative return basis.

The exact numerator and denominator are authoritative. The decimal approximation is a convenience and does not replace the exact rational pair or establish completeness.

Source assertions qualify before inference. Consumers use the explicit retained source and assessment graphs, and independently rerun the pinned sources and interpretation queries; receipts preserve integrity without independent source attestation.