Eine Taxonomie ordnet Dinge in eine Hierarchie von Kategorien, in der jede Stufe enger ist als die darüber: Küchengeräte > Kaffeemaschinen > Espressomaschinen. Eine Ontologie beschreibt die Arten von Dingen in einem Bereich, ihre Eigenschaften und die typisierten Beziehungen zwischen ihnen, mit Regeln, aus denen ein Computer Schlüsse ziehen kann: Ein Wasserfilter ist Zubehör zu einer bestimmten Espressomaschine, ein Entkalker wird von ihr verbraucht, ihr Boiler besteht aus Edelstahl.
Im Produktkatalog lautet der Unterschied zwischen Taxonomie und Ontologie kurz gesagt: Die Taxonomie beantwortet, wohin ein Produkt gehört, die Ontologie, wie Produkte zusammenhängen. Die meisten Shops brauchen zuerst eine solide Taxonomie, dann Attribute mit kontrollierten Wertelisten und erst danach eine kleine Auswahl typisierter Beziehungen dort, wo Kunden produktübergreifende Fragen stellen, etwa zu Kompatibilität, Ersatzteilen, Nachfolgern und Bundles. Der Rest dieses Leitfadens zeigt beide Modelle an einem Katalog, die Schicht dazwischen und wann sich welches Modell lohnt.
Taxonomie im Produktkatalog: ein Baum, eine Art von Verbindung
Eine Produkttaxonomie ist der Kategoriebaum, durch den du im Webshop navigierst und den du auf Kanäle abbildest. Ihre einzige echte Beziehung ist übergeordnet und untergeordnet: Espressomaschinen ist enger gefasst als Kaffeemaschinen. Der SKOS Primer des W3C beschreibt genau das für „thesauri, taxonomies, classification schemes“: Konzepte, die über broader und narrower verbunden sind, plus eine optionale assoziative Verbindung „related“ ohne weitere Bedeutung.
Öffentliche Taxonomien funktionieren im großen Maßstab genauso. Die Google-Produkttaxonomie in der Version 2021-09-21 hat 5.595 Kategorien, von Bekleidung & Accessoires bis hinunter zu einzelnen Produkttypen (siehe unseren Leitfaden zur Google-Produkttaxonomie). Jede Kategorie ist ein Knoten in einem Baum, und jedes Produkt bekommt einen Pfad von der Wurzel aus.
Taxonomien sind günstig aufzubauen und einem Merchandiser leicht zu erklären. Ihre Grenze zeigt sich, sobald du eine Frage stellst, bei der es nicht um die Einordnung geht. „Welche Filter passen zu dieser Maschine?“ hat im Baum keine Antwort, weil Filter und Maschine in verschiedenen Ästen sitzen und der Baum keine Kante zwischen ihnen hat.
Ontologie im Produktkatalog: Klassen, Eigenschaften und typisierte Beziehungen
Eine Ontologie startet mit denselben Klassen (Espressomaschine ist eine Art Kaffeemaschine) und ergänzt, was ein Baum nicht ausdrücken kann. Der OWL 2 Primer des W3C nennt OWL „a language for expressing ontologies“ und zählt die Bausteine auf: Klassen und Unterklassen, Objekteigenschaften, die ein Ding mit einem anderen verbinden, inverse Eigenschaften, Einschränkungen für Domain und Range sowie Kardinalitätsgrenzen.
Übertragen auf den fiktiven Espresso-Katalog enthält eine Ontologie Aussagen wie diese:
- Wasserfilter WF-2 ist Zubehör zur Espressomaschine EM-200
- Entkalker 500 ml ist Verbrauchsmaterial für EM-200 und EM-300
- Siebträger 58 mm ist ein Ersatzteil für EM-200
- EM-300 ersetzt EM-200
- EM-200 besteht aus Edelstahl, einem Wert aus einer Materialliste, nicht aus Freitext
- Jede Espressomaschine hat genau einen Pumpendruck in bar (eine Kardinalitätsregel)
Jede Aussage hat einen Typ, mit dem Software arbeiten kann. Weil „Zubehör zu“ einmal definiert ist, kann der Shop Zubehör auf der Seite der Maschine anzeigen, einen Filter ohne verknüpfte Maschine markieren und die Frage beantworten, an der der Baum gescheitert ist. Ist „ersetzt“ als gerichtet definiert, kann der Shop Besucher von der ausgelaufenen EM-200 zur EM-300 leiten, aber nicht umgekehrt.
Eine Espressomaschine in Taxonomie und Ontologie
Taxonomie vs. Ontologie im direkten Vergleich
Die Taxonomin Heather Hedden bringt in ihrem Vergleich der beiden einen nützlichen Punkt: Taxonomien unterstützen vor allem das Verschlagworten und das Finden nach Thema, Ontologien dagegen das Finden, Vergleichen und mehrstufige Abfragen über Daten. Beide beruhen auf W3C-Standards, SKOS für Taxonomien und OWL für Ontologien, sie ergänzen sich also, statt zu konkurrieren.
Taxonomie und Ontologie im Vergleich am Produktkatalog
| Form | Baum (manchmal ein Produkt in zwei Ästen) | Graph aus Klassen, Eigenschaften und Beziehungen |
|---|---|---|
| Beziehungen | Über- und untergeordnet, eventuell eine untypisierte Verbindung „related“ | Typisierte Beziehungen, die du definierst: Zubehör zu, besteht aus, ersetzt |
| Typische Frage | Wohin gehört dieses Produkt? | Welche Produkte passen zu diesem, ersetzen oder ergänzen es? |
| W3C-Standard | SKOS | OWL |
| Beispiel im Katalog | Kategoriebaum im Webshop, Google-Produkttaxonomie | Kompatibilitäts- und Ersatzteil-Verknüpfungen, Materiallisten, Klassenregeln |
| Wer pflegt sie | Category Manager oder E-Commerce-Manager | Produktdaten- oder Katalogarchitekt, zusammen mit den Category Managern |
Die Tabelle zeigt auch, wie sich die Arbeit unterscheidet. Eine Taxonomie ist fertig, wenn jedes Produkt seinen Platz hat. Eine Ontologie ist nie fertig, und das ist in Ordnung, solange jeder Beziehungstyp, den du ergänzt, eine echte Frage beantwortet.
Attribute und kontrollierte Vokabulare: die Schicht zwischen beiden
Die meisten Kataloge, die glauben, eine Ontologie zu brauchen, brauchen zuerst diese mittlere Schicht. Sie hat zwei Teile.
- Attribute pro Produktklasse. Eine Espressomaschine hat Pumpendruck, Boilertyp, Wassertankvolumen und Leistung. Eine Mühle hat Mahlwerkstyp und Mahlwerksdurchmesser. Die Attributmenge pro Klasse (oft Produktfamilie oder Attributset genannt) ist bereits eine kleine Ontologie: Sie legt fest, welche Art von Ding welche Eigenschaften hat.
- Kontrollierte Vokabulare für Attributwerte. Das Material ist Edelstahl, Aluminium, Kunststoff oder Messing, nicht „inox“, „RVS“ und „stainless“ nebeneinander. Erst eine kontrollierte Liste macht einen Wert filterbar, übersetzbar und über Lieferanten hinweg vergleichbar.
Unser Leitfaden zu Referenzdaten zeigt, wie du diese Wertelisten steuerst, und der Leitfaden zur Attributmodellierung behandelt, welche Attribute zu welcher Klasse gehören. Steht beides, sind typisierte Beziehungen zwischen Produkten nur noch ein kleiner Schritt, weil die Dinge, die du verbindest, schon sauber definiert sind.
Wo ein Knowledge Graph ins Spiel kommt
Die drei Begriffe werden oft verwendet, als wären sie austauschbar. Tatsächlich sind es Schichten:
- Taxonomie: die Hierarchie der Kategorien.
- Ontologie: das Schema, also Klassen, Eigenschaften, Beziehungstypen und Regeln.
- Knowledge Graph: die Ontologie, gefüllt mit echten Instanzen, also die tatsächlichen Datensätze von EM-200, WF-2 und Entkalker und die Verbindungen zwischen ihnen.
Ein Produktkatalog mit typisierten Verknüpfungen ist ein kleiner Knowledge Graph, auch wenn ihn niemand so nennt. Unser Glossareintrag zum Produkt-Knowledge-Graph geht tiefer auf Graphdatenbanken und Abfragesprachen ein; bei den meisten Katalogen können die Beziehungen im PIM direkt bei den Produkten liegen.
Welches Modell dein Katalog braucht: Signale, auf die du achten solltest
Wähle das Modell nach den Fragen, die Kunden und Kanäle an deine Daten stellen:
- Eine Taxonomie reicht, wenn Produkte meist für sich stehen (Basics in der Bekleidung, Wohndeko, Bücher) und die Hauptaufgaben Navigation und das Mapping auf Kanalkategorien sind.
- Ergänze Attribute und kontrollierte Vokabulare, wenn Kunden nach technischen Daten filtern und vergleichen oder wenn du auf Marktplätzen verkaufst, die strukturierte Werte pro Kategorie verlangen.
- Ergänze typisierte Beziehungen, wenn ein relevanter Teil der Fragen über ein Produkt hinausgeht: „Passt das?“, „Was ersetzt das?“, „Was brauche ich dazu?“. Ersatzteile, Verbrauchsmaterial, Werkzeuge mit Zubehör, Elektronik mit Ladegeräten und Hüllen sowie B2B-Kataloge mit Nachfolgeprodukten gehören hierher.
- Zieh eine eigene Graphdatenbank nur in Betracht, wenn die Beziehungen selbst das Produkt sind, etwa in einem Ersatzteilkatalog, in dem ein Teil zu Tausenden Maschinenmodellen und Konfigurationen passt und die Verknüpfungstabellen im PIM nicht mehr ausreichen.
Typisierte Beziehungen in fünf Schritten in einen bestehenden Katalog bringen
Du musst nicht den ganzen Bereich modellieren, bevor sich die erste Beziehung auszahlt. Fang bei den Fragen an, nicht beim Schema:
- Sammle die produktübergreifenden Fragen. Lies die Kundenservice-Tickets, Produktfragen und Suchanfragen auf der Website eines Monats und sortiere die Fragen heraus, bei denen es um zwei Produkte geht: passt, ersetzt, braucht, füllt nach. In einem Katalog für Kaffeezubehör sind das typischerweise Kompatibilität, Ersatzteile und Verbrauchsmaterial.
- Wähle zwei oder drei Beziehungstypen und definiere jeden in einem Satz. „Zubehör zu: ein optionales Produkt, das nur mit dem Zielprodukt funktioniert.“ Halte die Richtung fest und welche Produktklassen auf jeder Seite stehen dürfen, damit ein Entkalker nie versehentlich Zubehör zu einer Mühle wird.
- Befülle die Verknüpfungen aus Daten, die du schon hast. Lieferantendateien enthalten oft Kompatibilitätslisten, und alte Beschreibungen sagen oft „passt zu EM-200“. Mach daraus einmal Verknüpfungen und streich den Satz dann aus der Beschreibung.
- Ergänze eine Vollständigkeitsprüfung. Jedes Produkt in der Kategorie Wasserfilter braucht mindestens eine Verknüpfung „Zubehör zu“; jede ausgelaufene Maschine braucht eine Verknüpfung „ersetzt“, die auf sie zeigt. Ein Produkt, das die Prüfung nicht besteht, hat eine Datenlücke, kein Stilproblem.
- Veröffentliche die Beziehungen dort, wo sie gelesen werden. Der Zubehörblock auf der Produktseite, der BMEcat- oder Kanalexport und strukturierte Daten auf der Seite. Eine Beziehung, die nur im Backoffice liegt, beantwortet niemandem eine Frage.
Rechne damit, dass der erste Durchlauf die meistverkauften Maschinen und ihr Verbrauchsmaterial abdeckt, nicht den Long Tail. Dort liegen meist auch die Fragen.
Warum typisierte Beziehungen für Suchmaschinen und KI-Shopping-Agenten zählen
Ein Kunde, der einen KI-Assistenten fragt „Welcher Wasserfilter passt zu meiner EM-200?“, braucht eine Antwort aus Daten, nicht aus einer Beschreibung, die „kompatibel mit den meisten EM-Modellen“ sagt. Mit solchem Fließtext kann eine Maschine nichts anfangen. Mit einer typisierten Beziehung von WF-2 zu EM-200 schon.
Das Vokabular, um diese Beziehungen zu veröffentlichen, gibt es bereits. Der Typ Product von Schema.org hat isAccessoryOrSparePartFor, isConsumableFor, isSimilarTo und isRelatedTo, dazu material, category und isVariantOf. Jede davon ist eine typisierte Beziehung im Sinne einer Ontologie. Deshalb lässt sich ein Katalog mit typisierten Verknüpfungen in einer Form veröffentlichen, die Crawler und Agenten lesen können, ein Katalog mit nur einem Kategoriebaum dagegen nicht. Unser Leitfaden zur Schema.org-Taxonomie zeigt, wie Kategorien und Produkttypen zugeordnet werden.
Kein Standard garantiert, dass ein bestimmter KI-Assistent heute eine bestimmte Eigenschaft liest. Klar ist die Richtung: Strukturierte Attribute, kontrollierte Werte und explizite Beziehungen sind die Teile eines Katalogs, die eine Maschine ohne Raten nutzen kann.
Sechs Arten, wie Kataloge Taxonomie und Ontologie vermischen
- Attribute als Kategorien getarnt. Eine Kategorie namens Rote Espressomaschinen ist ein Filterwert, der sich als Knoten ausgibt. Die Farbe gehört in ein Attribut; der Baum bleibt beim Produkttyp.
- Marketing-Kollektionen in der Taxonomie. Geschenke unter 50 und Neuheiten sind nützliche Kollektionen, aber in den Klassifikationsbaum gemischt, machen sie das Mapping auf Kanalkategorien kaputt.
- Beziehungen im Beschreibungstext. „Passt zu EM-200 und EM-300“ in einer Beschreibung lässt sich nicht filtern, prüfen oder als Verknüpfung exportieren.
- Eine einzige Sammelverknüpfung „related“. Landen Zubehör, Alternativen und Nachfolger alle unter „verwandt“, kann der Shop sie auf der Seite nicht unterschiedlich behandeln, und ein Crawler auch nicht.
- Freitextwerte, wo eine Liste hingehört. Drei Schreibweisen eines Materials erzeugen drei Filteroptionen und drei Übersetzungen.
- Beziehungen ohne Richtung. „Ersetzt“ und „wird ersetzt durch“ sind verschiedene Aussagen. Speichere die Richtung einmal und leite die Umkehrung daraus ab, statt beide von Hand zu pflegen.
Kategorien, Familien und typisierte Produktverknüpfungen in WISEPIM
WISEPIM deckt die drei Schichten an einem Ort ab. Der Kategoriebaum ist die Taxonomie, mit KI-Kategorisierung, die zu über 95 % genau ist, und einem Kategorie-Mapping auf die Google-Produkttaxonomie. Produktfamilien halten die Attributmenge pro Klasse, mit Vererbung von übergeordneten Familien und optionalen ETIM-Klassen. Option sets (Optionssets) sind die kontrollierten Vokabulare: gemeinsame Listen erlaubter Werte für Auswahl- und Mehrfachauswahl-Attribute, jeweils mit einer Regel für unbekannte Werte beim Import (hinzufügen, hinzufügen und zur Prüfung markieren oder überspringen).
Typisierte Produktverknüpfungen sind die Ontologie-Schicht. Im Produkteditor verknüpfst du Produkte als Cross-sells, Upsells, verwandte Produkte, Ersatzprodukte oder Zubehör, und Bundle-Artikel tragen eine Menge. Die Typen überstehen den Export nur dort, wo das Format einen Platz für sie hat: Der BMEcat-Export im Feed Hub schreibt sie als typisierte Artikelreferenzen, Zubehör als accessories, Ersatzprodukte als Folgeartikel (followup) und Bundle-Artikel als consists-of. Shop-Verbindungen sind enger: Die Verbindung zu Lightspeed eCom sendet nur die Verknüpfungen Related Products, als verwandte Produkte in Lightspeed, und die übrigen Shop-Verbindungen senden keine Produktverknüpfungen. Wenn du Produktdaten für KI-Shopping-Assistenten vorbereitest, zeigt unsere Seite zu Agentic Commerce, was WISEPIM für sie veröffentlicht.
