Product knowledge graph
A product knowledge graph is a machine-readable model of a catalog in which every product, attribute value, category, manufacturer, and standard is an explicit entity connected by named relationships. Instead of storing "1/2 in. NPT brass ball valve" as a description, it records the product as a node linked to brass, to NPT, to a nominal size, and to the fittings it mates with. That structure lets software answer questions keyword search cannot.
What a product knowledge graph actually stores
A graph is built from three parts. Entities are the things worth naming on their own: a SKU, a manufacturer, a category, a standard like MSS SP-110, an attribute value like Grade 8. Edges name how two entities relate — fits, replaces, requires, conforms to. Attributes hang off either one.
The move that matters is making attribute values entities rather than strings. In a spreadsheet, brass is text in a Material column, repeated across thousands of rows in inconsistent spellings. In a graph, brass is one node that every brass SKU points at, carrying its own facts: alloy family, temperature ceiling, whether it is lead-free.
Written out, the graph around a single half-inch brass ball valve looks like this:
| Subject | Predicate | Object |
|---|---|---|
| Ball valve SKU | hasMaterial | Brass, alloy C46400 |
| Ball valve SKU | hasEndConnection | NPT, female |
| Ball valve SKU | hasNominalSize | 0.5 in |
| Ball valve SKU | hasPressureRating | 600 PSI (WOG) |
| Ball valve SKU | conformsTo | MSS SP-110 |
| Ball valve SKU | isVariantOf | Parent series SKU |
| Ball valve SKU | matesWith | Nipple SKU, 1/2 in. NPT |
| Ball valve SKU | supersedes | Prior SKU (discontinued) |
Every line in that table is a fact a machine can join, filter, or contradict.
Rows and columns vs. nodes and edges
A flat catalog stores products in isolation. Each row knows about itself and nothing else. It has no way to express that a valve mates with a nipple, or that a discontinued SKU has a successor. Those facts live in a salesperson's head or a PDF cross-reference chart.
| Question a buyer asks | Flat catalog | Product knowledge graph |
|---|---|---|
| "What fits this 1/2 in. NPT nipple?" | Keyword search on "1/2 NPT" returns anything containing those characters | Traverse matesWith edges from the nipple node |
| "What replaced the discontinued valve?" | Someone opens a spreadsheet | One hop back along supersedes |
| "Lead-free valves rated above 400 PSI" | Works only if both fields exist and are typed | Filter on typed attribute nodes |
| "Which SKUs conform to MSS SP-110?" | Search the description field and hope | Every product linked to the standard node |
The difference is not search quality. It is whether the relationship was ever recorded at all.
What the structure buys you
Once relationships are explicit, a set of expensive manual jobs become queries:
- Substitution and cross-reference. A competitor's part number resolves to your equivalent through a
crossReferencesedge, instead of a rep thumbing through a binder. - Compatibility and kitting. Accessories, replacement seals, and mating fittings are derived from edges rather than hand-maintained related-product lists that go stale.
- Faceted search that holds up. Facets read from attribute nodes, so "Brass" is one filter option, not four near-duplicates.
- Grounded AI answers. An assistant answering "will this valve take 500 PSI?" reads a typed rating linked to a standard.
- Consistency enforcement. If a SKU claims a 600 PSI rating but links to a body material that cannot hold it, the contradiction is visible.
The prerequisite nobody wants to talk about
A graph is only as good as the facts inside it. You cannot draw a matesWith edge between a valve and a nipple if neither record has a thread standard populated. You cannot make brass a single node while the catalog spells it brass, Brass, BRS, and "brass body."
Structure does not create data. It exposes the absence of it. The real work sits upstream:
- One taxonomy, so comparable products land in the same category and inherit the same attribute set.
- Controlled vocabulary, so every attribute value resolves to exactly one node.
- Typed values with units, so 600 PSI is stored as a number plus a UoM, not the string "600psi max".
- Filled attributes, because an edge cannot be inferred from a blank field.
- Resolved identity, via GTIN and MPN matching, so one physical product is not three nodes.
Most teams discover this in the wrong order. They buy graph tooling, load the catalog, and get a graph that faithfully represents how incomplete the catalog was.
Where the PIM fits, and where the work happens
Your PIM is the system of record. It stores the attributes, holds the taxonomy, manages workflow and governance, and it is the right place to source a graph from. Anglera works alongside Akeneo, Salsify, Syndigo, inriver, and Pimberly.
What a PIM does not do is fill the fields. It will show you that thread pitch is empty across most of your fastener catalog. It will not go read the manufacturer's spec sheet and populate it.
That gap is what Anglera closes — reading source documents and completing the fields the graph needs.
A product knowledge graph is the end state that becomes possible once the underlying facts are actually there. Get the attributes complete and normalized, and the edges are largely mechanical. Skip that step, and the graph is an expensive picture of what you are missing.
Frequently asked questions
What is a product knowledge graph in plain terms?
It is your catalog stored as a network of connected facts instead of a table of rows. Each product, attribute value, category, manufacturer, and standard is a node, and the links between them — fits, replaces, conforms to — are edges. Software walks those links to answer a question, rather than pattern-matching text inside a description field.
How is a product knowledge graph different from a PIM?
A PIM is a system of record: it stores attributes, enforces taxonomy, and manages workflow and approvals. A knowledge graph is a representation — a way of modeling that same data as entities and relationships so machines can traverse it. Most teams source the graph from the PIM. They sit at different layers, and neither one fills in missing attribute values.
Do I need a graph database like Neo4j to have one?
Not necessarily. The graph is a data model you can express in RDF triples, a property graph, or JSON-LD published on your product pages. The choice matters far less than whether your attribute values are normalized, typed, and complete. A graph database sitting on dirty data is still dirty data, only more expensive to query.
Does a product knowledge graph help with AI search?
Yes. A graph gives an assistant typed facts to retrieve — a pressure rating with its unit, a material linked to a standard — so every answer traces back to a specific record someone can check. Published as JSON-LD on your product pages, those same entities and relationships give crawlers and answer engines something explicit to lift.
What is the first step to building one?
Fix the taxonomy and the vocabulary, then fill the fields. Pick one category — hex bolts, say — collapse its attribute spellings into a controlled list, type the numeric values with units, and complete what is blank. Once a single category holds up, adding the edges is a small job. Starting with graph tooling instead is the common and expensive mistake.