The Commercial Intelligence ontology models what an entity does, what it sells, who buys it, which use cases it supports, and how named offerings are classified against internal or external product/service taxonomies using SKOS concepts and evidence-bearing classification assignments.
This is an Inferal-authored draft ontology module.
Conforming data graphs that use this module SHOULD validate against
shapes.ttl when the application needs closed-world checks
for required labels, customer relationship parties, evidence sources,
validity date literals, and product/service category links. OWL and RDFS
entailment alone do not make missing customer evidence false.
| Prefix | IRI |
|---|---|
cmi |
https://ontology.inferal.com/modules/commercial-intelligence/ |
conf |
https://ontology.inferal.com/modules/confidence/ |
loc |
https://ontology.inferal.com/modules/localization/ |
prov |
http://www.w3.org/ns/prov# |
schema |
https://schema.org/ |
skos |
http://www.w3.org/2004/02/skos/core# |
cpv |
http://data.europa.eu/cpv/cpv/ |
This module owns the reusable commercial surface: product/service offerings, products, services, customer segments, customer relationships, use cases, revenue models, and evidence-bearing links from offerings to one or more product/service classification schemes.
PROV-O [[PROV-O]], SKOS [[SKOS-REFERENCE]], Schema.org [[SCHEMA-ORG]], the Inferal confidence module, and the Inferal Localization module [[INFERAL-LOCALIZATION]] are imported directly. External schemes such as CPV, CPA, UNSPSC, Google Product Taxonomy, Shopify Product Taxonomy, ECLASS, ETIM, or analyst-maintained market maps are used as classification sources through SKOS concepts and concept schemes. They are not redefined by this ontology.
| Term | Kind | Normative role |
|---|---|---|
cmi:ProductServiceOffering |
Class | Specific named offering that can be classified, sourced, sold, piloted, or used by customers. |
cmi:Product |
Class | Named product, software product, platform, hardware product, API, data product, or packaged offering. |
cmi:Service |
Class | Named managed, professional, implementation, advisory, or human-delivered service offering. |
cmi:BusinessActivity |
Class | Sourced description of what a seller does, such as warehouse automation or developer payments infrastructure. |
cmi:CustomerSegment |
Class | Group of buyers, users, accounts, or customer organizations served or targeted by an entity or offering. |
cmi:UseCase |
Class | Job-to-be-done, workflow, problem, or deployment scenario for a seller, offering, or customer relationship. |
cmi:RevenueModel |
Class | Commercial monetization model such as subscription, usage-based pricing, transaction fee, licensing, take rate, or services. |
cmi:CustomerRelationship |
Class | Sourced relationship connecting a seller to a customer, account, design partner, pilot, deployment, or customer segment. |
cmi:OfferingClassification |
Class | Evidence-bearing assignment of an offering to a taxonomy concept or source code. |
cmi:ProductServiceCategoryScheme
is a small SKOS concept scheme for coarse commercial facets. It is
intentionally not a complete product taxonomy. Category assertions
classify offerings with cmi:offeringCategory; they are
not class assertions and do not imply that an offering has a single
exclusive category.
Producers SHOULD use these concepts for quick cross-cutting facets such as software, hardware, API, platform, AI-enabled, or marketplace. For analyst-grade product/service taxonomy work, producers SHOULD use cmi:OfferingClassification with cmi:classificationScheme, cmi:classifiedAs, and cmi:classificationCode so external schemes and source-specific codes are preserved.
| Concept | Role |
|---|---|
cmi:SoftwareOffering |
Software sold or provided as an application, system, tool, workflow, or digital capability. |
cmi:HardwareOffering |
Physical devices, equipment, machines, sensors, appliances, or hardware bundles. |
cmi:ServiceOffering |
Managed, professional, implementation, support, outsourcing, or advisory services. |
cmi:PlatformOffering |
Reusable platform, operating layer, ecosystem, workflow hub, or developer/user surface. |
cmi:MarketplaceOffering |
Offerings that intermediate discovery, matching, procurement, liquidity, exchange, or transactions. |
cmi:DataOffering |
Datasets, data feeds, enrichment products, benchmarks, analytics outputs, or information products. |
cmi:APIOffering |
API, SDK, protocol, integration endpoint, or machine-facing service offerings. |
cmi:AIEnabledOffering |
Offerings whose value proposition materially depends on ML, generative AI, prediction, computer vision, NLP, autonomy, or decision automation. |
cmi:RoboticsOffering |
Robotic systems, autonomous machines, robot fleets, robotics software, or robotics-as-a-service. |
cmi:VerticalSaaSOffering |
SaaS designed around the workflows, data, compliance, or operating needs of a specific industry vertical. |
| Term | Role |
|---|---|
cmi:sellsOffering | Connects an entity, brand, reseller, channel, or seller to an offering it sells, licenses, provides, or makes available. |
cmi:offeringDescription | Human-readable description of what an offering does or which problem it solves. |
cmi:offeringCategory | SKOS concept category assigned to a product/service offering. |
cmi:offeringClassification | Connects an offering to an evidence-bearing taxonomy or code assignment. This is not exported as a ReSpec dfn because it differs from cmi:OfferingClassification only by case. |
cmi:classifiedOffering | Offering being classified by a classification assignment. |
cmi:classifiedAs | SKOS concept assigned to an offering by a taxonomy, source, analyst, or classification process. |
cmi:classificationScheme | Taxonomy, concept scheme, code list, or external vocabulary used for a classification assignment. |
cmi:classificationCode | Literal source code, notation, or identifier preserved for a classification assignment. |
cmi:classificationRationale | Human-readable explanation for why an offering was classified as a concept or code. |
cmi:hasBusinessActivity | Connects an entity to any sourced business activity it performs or claims to perform. |
cmi:primaryActivity | Connects an entity to the activity treated as primary in a research context. |
cmi:servesCustomerSegment | Connects a seller or entity to a customer segment it serves or targets. |
cmi:targetCustomerSegment | Connects an offering, activity, relationship, or claim to a target customer segment. |
cmi:seller | Seller, provider, channel, reseller, or partner in a customer relationship. |
cmi:customer | Customer, buyer, account, design partner, or customer segment in a customer relationship. |
cmi:purchasedOffering | Offering reportedly purchased, piloted, deployed, licensed, evaluated, or used in a relationship. |
cmi:useCase | Use-case link for an entity, offering, customer relationship, business activity, or source claim. This is not exported as a ReSpec dfn because it differs from cmi:UseCase only by case. |
cmi:revenueModel | Revenue-model link for an entity, offering, customer relationship, or operating model claim. This is not exported as a ReSpec dfn because it differs from cmi:RevenueModel only by case. |
cmi:source | Supporting source resource for a commercial claim, relationship, offering, classification, or model. Source publication, generation, and retrieval timing SHOULD be represented with PROV-O terms such as prov:generatedAtTime, prov:wasGeneratedBy, and prov:endedAtTime. |
cmi:validFrom | Inclusive start date for a customer relationship, offering state, customer segment assignment, or other state-like commercial resource. |
cmi:validThrough | Inclusive end date for a customer relationship, offering state, customer segment assignment, or other state-like commercial resource. |
cmi:confidenceAssessment | Links a commercial intelligence resource to an Inferal confidence assessment. |
A product or service offering is a concrete commercial object, not a market category. Producers SHOULD mint resources for named offerings when source material refers to a product, platform, API, marketplace, managed service, data product, hardware system, or service line that can be described, sold, classified, or attached to customer evidence. Category labels such as "robotics", "platform", or "vertical SaaS" SHOULD be represented as SKOS concepts instead of subclasses.
cmi:offeringCategory is a low-friction shortcut for attaching a
coarse SKOS facet directly to an offering. Producers SHOULD use
cmi:OfferingClassification through
cmi:offeringClassification when a classification needs source,
confidence, retrieval activity, validity, scheme, code, or rationale metadata.
This is the preferred pattern for CPA, CPV, UNSPSC, Google Product
Taxonomy, Shopify Product Taxonomy, ECLASS, ETIM, and analyst-curated
market taxonomies because an offering can be classified differently
under each scheme.
cmi:classifiedAs points to the taxonomy concept when an IRI is
available. cmi:classificationCode preserves the source notation
even when the concept IRI later changes or when a source provides only
a code. cmi:classificationRationale records the analyst or
extraction reason, and cmi:source links the assignment to the
page, filing, dataset, procurement record, or analyst note that
supports it. Source timing SHOULD use PROV-O: prov:generatedAtTime
for a source entity's publication or snapshot generation time, and a
retrieval prov:Activity with prov:endedAtTime
when the analyst needs to preserve crawl or access time.
cmi:BusinessActivity describes what a seller does at a level useful for company research. cmi:UseCase describes the job or workflow an offering supports. cmi:CustomerSegment describes the class of customers or users served. These resources MAY be local analyst concepts, source-derived labels, or mappings to external industry and product taxonomies.
A cmi:CustomerRelationship is a first-class resource so the relationship can carry source, date, offering, use-case, and confidence metadata. It is intentionally broader than a closed accounting notion of "customer": a source-supported pilot, deployment, design-partner relationship, public case study, or customer-logo claim can be modeled when the distinction matters to analysts.
SHACL requires each customer relationship to have exactly one seller, exactly one customer, and at least one source. A purchased offering is optional because many sources identify the customer but not the exact SKU, product, service line, or deployment package.
Commercial claims SHOULD point to source resources using
cmi:source. Publication or source-generation time SHOULD be
recorded with PROV-O, normally prov:generatedAtTime on a
source entity or snapshot. Retrieval SHOULD be modeled as a
prov:Activity that prov:used the source or
generated a local snapshot and records prov:endedAtTime.
cmi:validFrom and cmi:validThrough remain local validity
interval properties for commercial states; a missing end date does not
mean the relationship is still active. They declare
loc:defaultFrame loc:UTCTimeline, so ordinary
xsd:date literals remain compact while retaining a
resolvable temporal frame. If the validity timing is disputed,
estimated, range-valued, or separately sourced, producers SHOULD mint
a loc:Locus and one or more
loc:Localization resources instead of adding a
commercial-specific date claim term. Confidence values SHOULD use
the Inferal Confidence Ontology when evidence quality, extraction
certainty, or analyst judgment needs to be explicit.