Taxonomie vs ontologie: het verschil, uitgelegd op een productcatalogus

Een taxonomie deelt dingen in een hiërarchie van categorieën in, waarbij elke stap omlaag smaller is dan de stap erboven: Keukenapparatuur > Koffiemachines > Espressomachines. Een ontologie beschrijft welke soorten dingen er in een domein zijn, welke eigenschappen ze hebben en welke getypeerde relaties er tussen ze bestaan, met regels waarmee een computer kan redeneren: een waterfilter is een accessoire van een bepaalde espressomachine, een ontkalker is er een verbruiksartikel voor, de boiler is gemaakt van roestvrij staal.

In een productcatalogus komt het hierop neer: de taxonomie zegt waar een product thuishoort, de ontologie zegt hoe producten met elkaar samenhangen. De meeste webshops hebben eerst een goede taxonomie nodig, daarna attributen met vaste waardelijsten, en pas dan een kleine set getypeerde relaties waar klanten vragen stellen die over meerdere producten gaan, zoals compatibiliteit, reserveonderdelen, opvolgers en bundels. De rest van deze gids laat beide modellen zien op één catalogus, de laag ertussen, en wanneer elk model zich terugbetaalt.

Een taxonomie in een productcatalogus: één boom, één soort verbinding

Een producttaxonomie is de categorieboom waarmee je door een webshop navigeert en die je aan kanalen koppelt. De enige echte relatie is breder en smaller: Espressomachines is smaller dan Koffiemachines. De SKOS Primer van het W3C beschrijft precies dit voor thesauri, taxonomieën en classificatieschema's: begrippen verbonden met broader en narrower, plus een optionele associatieve related-verbinding zonder verdere betekenis.

Publieke taxonomieën werken op grote schaal net zo. De producttaxonomie van Google, versie 2021-09-21, telt 5.595 categorieën, van Apparel & Accessories tot losse producttypes (zie onze gids over de Google-producttaxonomie). Elke categorie is een knoop in één boom en elk product krijgt een pad vanaf de wortel.

Een taxonomie is goedkoop om te bouwen en makkelijk uit te leggen aan een merchandiser. De grens wordt zichtbaar zodra je een vraag stelt die niet over plaatsing gaat. "Welke filters passen op deze machine?" heeft geen antwoord in een boom, want een filter en een machine zitten in verschillende takken en de boom heeft geen verbinding tussen die twee.

Een ontologie in een productcatalogus: klassen, eigenschappen en getypeerde relaties

Een ontologie begint bij dezelfde klassen (een espressomachine is een soort koffiemachine) en voegt toe wat een boom niet kan zeggen. De OWL 2 Primer van het W3C noemt OWL een taal om ontologieën uit te drukken en somt de bouwstenen op: klassen en subklassen, object properties die het ene ding aan het andere koppelen, inverse eigenschappen, domein- en bereikbeperkingen en kardinaliteitsgrenzen.

Vertaald naar een fictieve espressocatalogus bevat een ontologie uitspraken als deze:

• Waterfilter WF-2 is een accessoire van espressomachine EM-200
• Ontkalker 500 ml is een verbruiksartikel voor EM-200 en EM-300
• Zeefdrager 58 mm is een reserveonderdeel voor EM-200
• EM-300 vervangt EM-200
• EM-200 is gemaakt van roestvrij staal, een waarde uit een materiaallijst en geen vrije tekst
• Elke espressomachine heeft precies één pompdruk in bar (een kardinaliteitsregel)

Elke uitspraak heeft een type waar software iets mee kan. Omdat "accessoire van" één keer gedefinieerd is, kan de webshop accessoires op de machinepagina tonen, een filter zonder gekoppelde machine signaleren en de vraag beantwoorden waar de boom geen antwoord op had. Omdat "vervangt" een richting heeft, kan de shop een bezoeker van de uitlopende EM-200 naar de EM-300 sturen, maar niet andersom.

Taxonomie vs ontologie naast elkaar

Taxonoom Heather Hedden maakt in haar vergelijking van de twee een bruikbaar punt: een taxonomie dient vooral om content te labelen en op onderwerp terug te vinden, een ontologie ook om data te vergelijken, te analyseren en vragen in meerdere stappen te beantwoorden. Beide rusten op W3C-standaarden, SKOS voor taxonomieën en OWL voor ontologieën, dus ze vullen elkaar aan in plaats van te concurreren.

De tabel laat ook de vorm van het werk zien. Een taxonomie is af als elk product een plek heeft. Een ontologie is nooit af, en dat is prima zolang elk relatietype dat je toevoegt een echte vraag beantwoordt.

Attributen en vaste waardelijsten: de laag tussen de twee

De meeste catalogi die denken een ontologie nodig te hebben, hebben eerst deze middelste laag nodig. Die bestaat uit twee delen.

• Attributen per productklasse. Een espressomachine heeft pompdruk, type boiler, inhoud van het waterreservoir en vermogen. Een koffiemolen heeft type maalschijf en diameter. De set attributen per klasse (vaak productfamilie of attribuutset genoemd) is al een kleine ontologie: hij zegt welk soort ding welke eigenschappen heeft.
• Gecontroleerde vocabulaires voor attribuutwaarden. Materiaal is roestvrij staal, aluminium, kunststof of messing, niet "inox", "RVS" en "rvs-staal" door elkaar. Een vaste lijst maakt een waarde filterbaar, vertaalbaar en vergelijkbaar tussen leveranciers.

Onze gids over referentiedata gaat over het beheer van zulke waardelijsten, en de gids over attribuutmodellering over welke attributen bij welke klasse horen. Staan die twee, dan zijn getypeerde relaties tussen producten een kleine stap, want de dingen die je verbindt zijn al goed gedefinieerd.

Waar een kennisgraaf in beeld komt

De drie termen worden vaak door elkaar gebruikt. Het zijn lagen:

• Taxonomie: de hiërarchie van categorieën.
• Ontologie: het schema, dus de klassen, eigenschappen, relatietypes en regels.
• Kennisgraaf (knowledge graph): de ontologie gevuld met echte exemplaren, dus de werkelijke records van EM-200, WF-2 en de ontkalker en de verbindingen ertussen.

Een productcatalogus met getypeerde koppelingen is een kleine kennisgraaf, ook als niemand hem zo noemt. Voor de meeste catalogi kunnen die relaties gewoon in het PIM naast de producten staan; een aparte graafdatabase is pas nodig bij uitzonderlijk veel verbindingen.

Welk model jouw catalogus nodig heeft: signalen om op te letten

Kies het model op basis van de vragen die klanten en kanalen aan je data stellen:

• Een taxonomie is genoeg als producten grotendeels op zichzelf staan (basiskleding, woondecoratie, boeken) en navigatie en het koppelen van kanaalcategorieën het belangrijkste werk zijn.
• Voeg attributen en vaste waardelijsten toe als klanten filteren en vergelijken op specificaties, of als je verkoopt op marktplaatsen zoals bol die gestructureerde waarden per categorie vragen.
• Voeg getypeerde relaties toe als een flink deel van de vragen over meerdere producten gaat: "past dit", "wat vervangt dit", "wat heb ik er nog bij nodig". Reserveonderdelen, verbruiksartikelen, gereedschap met accessoires, elektronica met laders en hoesjes, en B2B-catalogi met opvolgers horen hier.
• Overweeg een aparte graafdatabase alleen als de relaties het product zelf zijn, zoals een onderdelencatalogus waarin één onderdeel op duizenden machinemodellen en configuraties past en de koppeltabellen van het PIM tekortschieten.

Getypeerde relaties toevoegen aan een bestaande catalogus in vijf stappen

Je hoeft niet het hele domein te modelleren voordat de eerste relatie iets oplevert. Begin bij de vragen, niet bij het schema:

1. Verzamel de vragen die over meerdere producten gaan. Lees een maand klantenservicetickets, productvragen en zoekopdrachten in je webshop, en zet apart wat over twee producten gaat: past, vervangt, heb ik nodig, navulling. In een catalogus met koffieapparatuur zijn dat meestal compatibiliteit, reserveonderdelen en verbruiksartikelen.
2. Kies twee of drie relatietypes en definieer elk in één zin. "Accessoire van: een optioneel product dat alleen werkt met het doelproduct." Leg de richting vast en welke productklassen aan elke kant mogen staan, zodat een ontkalker nooit per ongeluk een accessoire van een koffiemolen wordt.
3. Vul de koppelingen met data die je al hebt. Leveranciersbestanden bevatten vaak compatibiliteitslijsten, en oude omschrijvingen zeggen vaak "past op EM-200". Zet die één keer om in koppelingen en haal de zin daarna uit de omschrijving.
4. Voeg een volledigheidscontrole toe. Elk product in de categorie Waterfilters heeft minstens één accessoire-van-koppeling nodig; elke uitlopende machine een vervangt-koppeling die ernaar wijst. Een product dat de controle niet haalt, heeft een datagat, geen stijlprobleem.
5. Publiceer de relaties waar ze gelezen worden. Het accessoireblok op de productpagina, de BMEcat- of kanaalexport en gestructureerde data op de pagina. Een relatie die alleen in de backoffice bestaat, beantwoordt niemands vraag.

Reken erop dat de eerste ronde de best verkochte machines en hun verbruiksartikelen dekt, niet de lange staart. Daar zitten meestal de vragen.

Waarom getypeerde relaties tellen voor zoekmachines en AI-shoppingagents

Een klant die een AI-assistent vraagt welk waterfilter op zijn EM-200 past, heeft een antwoord nodig dat uit data komt, niet uit een omschrijving die zegt "geschikt voor de meeste EM-modellen". Zulke tekst geeft een machine niets om te volgen. Een getypeerde relatie van WF-2 naar EM-200 wel.

De woordenschat om zulke relaties te publiceren bestaat al. Het Product-type van schema.org kent isAccessoryOrSparePartFor, isConsumableFor, isSimilarTo en isRelatedTo, plus material, category en isVariantOf. Elk daarvan is een getypeerde relatie in de zin van een ontologie. Daarom kan een catalogus met getypeerde koppelingen gepubliceerd worden in een vorm die crawlers en agents kunnen lezen, en een catalogus met alleen een categorieboom niet. Onze gids over schema.org als taxonomie laat zien hoe categorieën en producttypes daarop aansluiten.

Geen enkele standaard garandeert dat een bepaalde AI-assistent vandaag een bepaalde eigenschap leest. De richting is wel duidelijk: gestructureerde attributen, vaste waarden en expliciete relaties zijn de delen van een catalogus die een machine kan gebruiken zonder te gokken.

Zes manieren waarop catalogi taxonomie en ontologie door elkaar halen

1. Attributen vermomd als categorieën. Een categorie Rode espressomachines is een filterwaarde die zich voordoet als knoop. Kleur hoort in een attribuut; de boom blijft over producttype gaan.
2. Marketingcollecties in de taxonomie. Cadeaus onder de 50 euro en Nieuw binnen zijn nuttige collecties, maar in de classificatieboom maken ze het koppelen van kanaalcategorieën kapot.
3. Relaties in omschrijvingen. "Past op EM-200 en EM-300" in een omschrijving kun je niet filteren, controleren of als koppeling exporteren.
4. Eén verzamelbak voor gerelateerd. Gaan accessoires, alternatieven en opvolgers allemaal in "gerelateerd", dan kan de shop ze op de pagina niet verschillend behandelen, en een crawler ook niet.
5. Vrije tekst waar een lijst hoort. Drie schrijfwijzen van één materiaal geven drie filteropties en drie vertalingen.
6. Relaties zonder richting. "Vervangt" en "wordt vervangen door" zijn verschillende uitspraken. Leg de richting één keer vast en leid de omgekeerde af, in plaats van beide met de hand bij te houden.

Categorieën, families en getypeerde productkoppelingen in WISEPIM

WISEPIM dekt de drie lagen op één plek. De categorieboom is de taxonomie, met AI-categorisering die voor 95%+ klopt en een categoriekoppeling met de producttaxonomie van Google. Productfamilies bevatten de attribuutset per klasse, met overerving van ouderfamilies en optioneel ETIM-klassen. Option sets zijn de vaste waardelijsten: gedeelde lijsten met toegestane waarden voor select- en multiselect-attributen, elk met een regel voor onbekende waarden bij een import (toevoegen, toevoegen en markeren voor controle, of overslaan). Meer daarover op de pagina attributen beheren.

Getypeerde productkoppelingen zijn de ontologielaag. In de producteditor koppel je producten als cross-sell, upsell, gerelateerd product, vervanger (Replacement) of accessoire, en bundelartikelen hebben een aantal. De types blijven bij de export alleen behouden waar het formaat er een plek voor heeft: de BMEcat-export in Feed Hub schrijft ze als getypeerde artikelreferenties, met accessoires als accessories, vervangers als follow-up en bundelartikelen als consists-of. Winkelkoppelingen doen minder: de koppeling met Lightspeed eCom stuurt alleen de Related Products-koppelingen, als gerelateerde producten in Lightspeed, en de andere winkelkoppelingen sturen geen productkoppelingen. Bereid je productdata voor op AI-shoppingassistenten, dan laat onze pagina over agentic commerce zien wat WISEPIM daarvoor publiceert.