// DEEP DIVE | PRODUCT DATA ENRICHMENT
Ontology Engineering: Understand Data, Don't Just Store It
An ontology is the difference between a database that knows a product is "red" and a system that understands: "red" is a warning color, therefore this product fits with safety apparel. Ontology engineering turns flat tables into a connected knowledge model. The result is semantic search that understands intent and recommendations that draw on relationships rather than just attributes.
THE PROBLEM
Why tables no longer suffice
Classic PIM systems are data silos. Each product has its attributes (color, material, size, price), and that is it. Anyone asking "which products fit a formal occasion?" gets no answer because "formal occasion" is not an attribute. The system sees products, not meaning.
For a product with 20 attributes that is enough. For an assortment of 50,000 products and a customer searching for a wedding outfit, it is not. Search and recommendations fail precisely at this missing semantic layer. Cross-sell suggestions stay superficial ("other customers also bought") instead of context-driven ("for a wedding we recommend suit plus tie plus matching shoes").
The solution is an ontology: a formal model that stores not just properties but also relationships between products and concepts. Instead of an Excel table, a graph emerges where nodes (products, occasions, colors, materials) are connected by edges ("fits with," "is part of," "replaces," "symbolizes").
What is a product ontology?
A product ontology is a formal model that describes not only properties of products but also their relationships. It enables machines to understand context, for example that a screw X fits a nut Y, or that a wedding is a formal occasion and requires a suit. Technically this is represented through triples (subject, predicate, object) and stored in a graph database (such as Neo4j). The W3C standards RDF (Resource Description Framework) and OWL (Web Ontology Language) form the foundation, SPARQL is the query language.
Four steps from data silo to knowledge network
/ OUR APPROACH
01
Step 01
Triples as the building block
We model knowledge as subject-predicate-object triples. Example: Sneaker A (subject) has color (predicate) red (object). And further: red (subject) symbolizes (predicate) danger (object). From such triples a graph emerges in which the AI finds connections across nodes, instead of just searching directly linked fields. That is the mechanic of reasoning.
02
Step 02
Knowledge graph in the database
Triples land in a graph database like Neo4j, AWS Neptune, or an RDF triple store. Unlike in relational databases, relationships are natively represented here, not simulated through expensive joins. A query like "all products fitting a formal occasion under 200 euros" runs in milliseconds because the system traverses the "fits formal occasion" relationship directly.
03
Step 03
Semantic search as the use case
The customer searches "wedding outfit." Without ontology the search finds nothing because no product carries "wedding" in its name. With ontology the system knows: wedding is a formal occasion, formal occasion requires suit or dress, so we show suits and dresses as hits, plus ties and shoes as sensible add-ons. The search understands intent instead of words.
04
Step 04
Cross-selling and bundles through reasoning
The ontology understands "suit requires shirt and shoes" as a logical rule, not as a manually maintained cross-sell list. When a new suit enters the assortment tomorrow, it automatically inherits the right bundle suggestions without manual upkeep. That scales with the assortment, not with maintenance effort.
The library analogy
Imagine a library. Without ontology, all books lie in a heap, search only works on the exact title. With ontology there are shelves (categories), cross-references ("if you liked this, you might like that"), and thematic recommendations ("for your travel interest this guidebook set fits"). Your product data becomes a library that knows its own relationships, instead of a heap where only exact hits are possible.
10x
faster relationship queries compared to relational joins
For queries that must hop multiple times between linked entities (example: "find all products that fit occasions typical in summer, in price range X"), a graph database delivers significantly higher performance than a relational DB with multi-table joins. For simple single-attribute queries, the difference is smaller. The advantage there sits in AI reasoning, not latency.
Why ontologies win on complex relationships
Feature
Table (SQL/PIM)
Graph (ontology)
Structure
Rigid (columns and rows)
Flexible (network of nodes and edges)
Relationship
Hard to model, many joins needed
Native ("is related to," "fits with")
AI capability
Low (only text search)
High (understands context and inference)
Schema changes
Migration across all tables
New relationships easy to add
Multi-hop queries
Performance collapses
Native graph DB strength
Tech stack: RDF and OWL as W3C standards
We use the W3C standards RDF (Resource Description Framework) and OWL (Web Ontology Language). These are the standards parts of the modern web rely on. Storage in Neo4j, AWS Neptune, or established triple stores. Query language is SPARQL. No proprietary format, no vendor lock-in.
Three questions CDOs and AI architects ask
No. The ontology sits alongside the PIM, not instead of it. The PIM remains the source of truth for master data (material, size, price, supplier). The ontology adds the semantic layer: relationships, categorization, occasion mapping. Both systems sync continuously. The PIM team changes nothing in its workflow.
Initially the ontology is generated from existing data: classification systems (ECLASS, ETIM), category trees, historical cross-sell data, and AI-assisted relationship suggestions. In daily operation you maintain only the high-level concepts, new products are automatically slotted into the graph through their attributes. Manual upkeep is the exception, not the rule.
Three measurable effects: better conversion through semantic search (zero-result queries drop), higher basket value through context-driven cross-sells (bundles instead of single items), and higher findability for long-tail searches that today go nowhere. Which effect dominates for you depends on assortment and search usage.
Related deep dives
Taxonomy and Classification
Taxonomy is the hierarchical tree structure (category, subcategory). Ontology is the network that extends these hierarchies with relationships.
Golden Records and Master Data
Before an ontology gets set up, master data should be consolidated. Golden records deliver the clean foundation.
// ONTOLOGY ENGINEERING
Let's discuss your data mode.
Show us your current data model and a typical search or recommendation problem that does not work well today. We sketch an ontology architecture, show you on your own data what the relationships would look like, and tell you what the implementation costs. In one week.