How Do You Connect Product Variants, Accessories and Compatible Equipment Without Duplicate Records?

First decide whether two records describe one thing or two things

Relationship modelling begins after identity resolution, not before it. Two supplier rows may be alternate descriptions of the same physical product, while two nearly identical products may be genuinely different sellable variants. Merging the second pair loses important distinctions; keeping the first pair separate creates duplicates that spread through search, stock, recommendations and reporting.

Use stable identifiers and product-defining attributes to make the decision. A Shopify product ID identifies the product inside one store, while a Shopify variant ID identifies a sellable version. An ERP item ID identifies the operational record. A GTIN or manufacturer part number may provide external evidence, subject to the way the manufacturer or standards owner assigns it. Titles, handles and descriptions are labels, not durable identity keys.

Record the match decision and its basis. A source record should resolve to one canonical entity, remain separate, or enter a review queue. Never let a fuzzy title match silently create or merge an entity. That decision must be reproducible when the next supplier file arrives.

Model the product family separately from its sellable variants

A product family describes the shared concept; a variant represents a version distinguished by options or other approved dimensions. Shopify describes variants as combinations of option values such as size and colour. Each variant can also carry its own inventory. That is a strong operational reason not to flatten every version into one generic product record.

Schema.org uses ProductGroup with hasVariant and the inverse isVariantOf relationship. Its model treats the group as a template for products that vary on explicitly defined dimensions. That distinction is useful inside a business knowledge model even when the final database is not RDF.

Store shared attributes on the family only when they are genuinely inherited. Put variant-specific SKU, barcode, price, dimensions, colour, size and availability on the variant. If an attribute differs, the variant value must win without overwriting the family definition or its siblings.

• Family: hydraulic hose assembly range H100
• Variant: H100, 1/2-inch bore, 1.5-metre length
• Shopify product ID: attached to the family record for that store
• Shopify variant ID: attached to the sellable variant
• ERP item ID and SKU: attached at the level the ERP actually manages

Use precise relationship types instead of one related-products field

A generic related-to link cannot safely answer operational questions. A seal kit that is a spare part for a pump is not the same as oil that is consumed by the pump, a newer pump that supersedes it, or a mounting bracket that makes it compatible with a machine. Applications need the actual meaning.

Define a small governed vocabulary. For each relationship, state the allowed source and target entity types, its direction, whether the inverse is stored or calculated, whether duplicates are allowed, and which qualifications or evidence are required. Schema.org distinguishes isAccessoryOrSparePartFor from isConsumableFor and variant relationships; that separation illustrates why one undifferentiated product association is insufficient.

Prefer business language that reviewers understand, then map it to external vocabularies where useful. The internal term fits-machine-model might require serial range and mounting position, while is-accessory-for may not. A standards mapping should clarify meaning, not force several business relationships into the nearest convenient label.

Make direction part of the relationship definition

Direction changes the question a graph can answer. Cartridge C10 is a consumable for printer P20 does not mean printer P20 is a consumable for cartridge C10. Variant V belongs to family F is the inverse of family F has variant V, but the two forms should not become unrelated assertions.

The W3C RDF data model expresses a relationship as a subject-predicate-object triple. It also treats the predicate as the property that relates the subject to the object. This provides a useful design test: can a reviewer read the relationship in one direction as an unambiguous sentence?

Choose one canonical storage direction and generate safe inverse views where required. Document which relationships are symmetric, such as is-equivalent-to after approval, and which are not. Never assume that compatibility or replacement is automatically bidirectional.

Treat compatibility as a qualified assertion

Compatibility is rarely a permanent yes-or-no fact between two product IDs. It may depend on machine model, build year, serial-number range, engine, region, mounting position, firmware or an adapter. Store those conditions with the assertion rather than in an unstructured note.

Create a relationship record containing the subject product, relationship type, target equipment or model, qualifications, evidence reference, reviewer, status and valid period. Use confirmed, excluded and unknown as distinct states. The absence of a confirmed link is not evidence that a product is incompatible.

When a supplier revises fitment, close or supersede the old assertion instead of rewriting history. The W3C notes that a relationship may hold at one time and not another. Effective dates protect product pages, support answers and downstream applications from silently treating an expired relationship as current.

Keep source-system IDs attached to the canonical entity

A knowledge graph should connect the identifiers used by each application, not replace them with a display name. One canonical product can carry a Shopify product ID for one store, a different ID for another store, a NetSuite or Sage item ID, supplier codes and approved external identifiers. Each identifier needs its namespace and scope.

A value such as 12345 is meaningless without knowing whether it is a Shopify product, a Shopify variant, an ERP item or a supplier row. Store provider, account or store, object type, identifier, validity and discovery source. Enforce uniqueness within the correct scope.

Every read or write to Shopify must resolve the exact connected store and use its Shopify ID. Do not search by title and take the first result. The same rule applies to ERP and supplier records. If an ID is missing or points to a different canonical entity, stop the change and present an exception.

Do not turn accessories, consumables and replacements into variants

A variant is a member of a product family that differs on declared dimensions. An accessory is a separate product used with another product. A consumable is depleted through use. A replacement or supersession expresses lifecycle or substitution. These relationships can all appear near one product page, but they carry different commercial and safety consequences.

If a filter cartridge is modelled as a pump variant, inventory, pricing and customer selection become misleading. If a superseding part is labelled merely similar, a support agent may miss an approved replacement. If two compatible accessories are merged because they share a title, stock and order history can attach to the wrong item.

Make the relationship explicit, keep each sellable item as its own entity and define whether the relationship is advisory or approved for automated use. High-risk substitutions should remain recommendations for human review unless the business has approved the necessary rules and evidence.

A concrete example: one excavator, three filters and two suppliers

Imagine an excavator model E200 with two engine generations. Supplier A lists oil filter OF-10 for every E200. Supplier B lists OF-10 for early serial numbers and OF-11 for later machines. The ERP contains both filters, while Shopify has one product for OF-10 with pack-size variants and a separate product for OF-11.

The graph creates canonical entities for the excavator model, its engine generations, the two filters, the OF-10 product family and its pack-size variants. Shopify product and variant IDs remain attached to the matching entities. Supplier rows and ERP item IDs are linked as source records; they do not become extra products.

Compatibility is represented through qualified assertions. OF-10 fits the early engine generation within its approved serial range. OF-11 fits the later generation. Supplier A's broad claim remains visible but conflicts with the more specific evidence and enters review. The pack of six remains a variant of OF-10, not a different compatible filter.

Now the storefront can show the correct sellable variant, the support team can answer which filter fits a serial number, and a catalogue import can update the right Shopify object. Each application uses the same entities and approved relationships without copying the whole record into a new local truth.

Prevent duplicate relationships as well as duplicate products

Even with clean entities, repeated imports can create duplicate edges. Define a relationship key from the canonical subject, relationship type, canonical object and any qualifiers that change its meaning. A source reference should support that assertion rather than create another indistinguishable assertion every time it appears.

Multiple sources can support one approved relationship, while conflicting sources can remain as separate claims awaiting resolution. Distinguish the business assertion from the evidence records behind it. That lets reviewers see agreement without inflating the apparent number of relationships.

Make ingestion idempotent. Reprocessing the same supplier row or webhook should update its evidence state, not add another product or link. Read the stored result back and compare canonical IDs, relationship keys and qualifiers before marking the run complete.

Design the graph for the questions applications must answer

Start with a small set of customer and operational questions: which variant is sellable, which consumable fits this model, which spare part replaces the discontinued item, and which Shopify ID should receive the approved change? Model only the entities and relationships needed to answer them safely.

M.I.A.I Knowledge Graph is designed to connect canonical entities, relationships and evidence so applications can reuse a consistent business view. Its approved capabilities include canonical entities, relationship modelling, evidence provenance and reusable knowledge access. The graph remains most useful when those controls serve a defined workflow rather than an attempt to connect every field at once.

Return answers with identifiers and context. A product recommendation should include the canonical product, destination product or variant ID, relationship type, relevant qualifications and review state. If the relationship is unresolved, applications should receive an explicit unknown or review-required result rather than a guessed link.

Preview relationship changes before publication

A safe preview shows the current and proposed entities, all source-system IDs, relationship direction, qualifiers, evidence and every destination that would consume the change. Summarise new links, removed links, conflicts, unresolved identities and affected products.

Test difficult cases: one source record matched to two entities, one Shopify variant ID reused across stores, a product that is both accessory and consumable in different contexts, a compatibility range with a boundary, and a supersession that is not reversible. Confirm that failures stay isolated.

Approve a controlled batch, write using stable destination IDs and read the result back. Keep the prior relationship state so an incorrect batch can be reversed without rolling back unrelated prices, stock or product copy.

1. Resolve every source record to a canonical entity or a visible exception.
2. Validate each identifier within its provider, account and object scope.
3. Apply the approved relationship type, direction and qualifications.
4. Deduplicate assertions while preserving all supporting evidence.
5. Preview affected product, variant and application views.
6. Approve a limited batch and write by exact destination ID.
7. Read back the stored relationships and public output.

Product-relationship modelling checklist

• Give every real product, variant, model and organisation a stable canonical ID.
• Attach Shopify, ERP, supplier, SKU, GTIN and part-number identifiers with scope.
• Separate product families from sellable variants.
• Use precise types for variants, accessories, consumables, compatibility and supersession.
• Define relationship direction, inverse behaviour and allowed entity types.
• Store compatibility qualifications and validity dates as structured data.
• Keep multiple evidence records behind one business assertion.
• Make repeated imports idempotent for both entities and relationships.
• Stop destination changes when the exact platform ID cannot be resolved.
• Preview, approve, write and read back controlled batches.