// DEEP DIVE | PRODUKTDATENANREICHERUNG
Ontologie-Engineering: Daten verstehen, nicht nur speichern
Eine Ontologie ist der Unterschied zwischen einer Datenbank, die weiß, dass ein Produkt "rot" ist, und einem System, das versteht: "rot" ist eine Warnfarbe, deshalb passt das Produkt zu Sicherheitskleidung. Ontologie-Engineering verwandelt flache Tabellen in ein vernetztes Wissensmodell. Das Ergebnis sind semantische Suche, die Absicht versteht, und Recommendations, die Querverweise nutzen statt bloßer Attribute.
DAS PROBLEM
Warum Tabellen nicht mehr ausreichen
Klassische PIM-Systeme sind Datensilos. Jedes Produkt hat seine Attribute (Farbe, Material, Größe, Preis), und das war es. Wer fragt "Welche Produkte passen zu einem festlichen Anlass?", bekommt keine Antwort, weil "festlicher Anlass" kein Attribut ist. Das System sieht nur Produkte, keine Bedeutung.
Für ein Produkt mit 20 Attributen reicht das. Für ein Sortiment mit 50.000 Produkten und einem Kunden, der nach einem Outfit für eine Hochzeit sucht, nicht. Suche und Recommendation scheitern an genau dieser fehlenden semantischen Schicht. Cross-Selling-Vorschläge bleiben oberflächlich ("andere Kunden kauften auch") statt kontextgetrieben ("für Hochzeit empfehlen wir Anzug plus Krawatte plus passende Schuhe").
Die Lösung ist eine Ontologie: ein formales Modell, das nicht nur Eigenschaften, sondern auch Beziehungen zwischen Produkten und Konzepten speichert. Statt einer Excel-Tabelle entsteht ein Graph, in dem Knoten (Produkte, Anlässe, Farben, Materialien) durch Kanten ("passt zu", "ist Teil von", "ersetzt", "symbolisiert") verbunden sind.
Was ist eine Produkt-Ontologie?
Eine Produkt-Ontologie ist ein formales Modell, das nicht nur die Eigenschaften von Produkten beschreibt, sondern auch ihre Beziehungen zueinander. Sie ermöglicht es Maschinen, den Kontext von Daten zu verstehen, etwa dass eine Schraube X zu einer Mutter Y passt, oder dass eine Hochzeit ein festlicher Anlass ist und einen Anzug erfordert. Technisch wird dies über Triples (Subjekt, Prädikat, Objekt) abgebildet und in einer Graph-Datenbank (etwa Neo4j) gespeichert. Die W3C-Standards RDF (Resource Description Framework) und OWL (Web Ontology Language) bilden die Grundlage, SPARQL ist die Abfragesprache.
Vier Schritte vom Datensilo zum Wissensnetz
/ UNSER ANSATZ
01
Schritt 01
Triples als Grundbaustein
Wir modellieren Wissen als Subjekt-Prädikat-Objekt-Triples. Beispiel: Sneaker A (Subjekt) hat Farbe (Prädikat) Rot (Objekt). Weiter: Rot (Subjekt) symbolisiert (Prädikat) Gefahr (Objekt). Aus solchen Triples entsteht ein Graph, in dem die KI über Ecken Verbindungen findet, statt nur direkt verknüpfte Felder zu durchsuchen. Das ist die Mechanik des Reasoning.
02
Schritt 02
Knowledge Graph in der Datenbank
Triples landen in einer Graph-Datenbank wie Neo4j, AWS Neptune oder einer RDF-Triple-Store-Lösung. Anders als in relationalen Datenbanken sind Beziehungen hier nativ abgebildet, nicht über teure Joins simuliert. Eine Abfrage wie "alle Produkte, die zu einem festlichen Anlass passen und unter 200 Euro kosten" läuft in Millisekunden, weil das System die Beziehung "passt zu festlichem Anlass" direkt traversiert.
03
Schritt 03
Semantische Suche als Use Case
Der Kunde sucht "Outfit für Hochzeit". Ohne Ontologie findet die Suche nichts, weil kein Produkt "Hochzeit" im Namen trägt. Mit Ontologie weiß das System: Hochzeit ist ein festlicher Anlass, festlicher Anlass erfordert Anzug oder Kleid, also zeigen wir Anzüge und Kleider als Treffer, dazu Krawatten und Schuhe als sinnvolle Ergänzung. Die Suche versteht Absicht statt nur Wörter.
04
Schritt 04
Cross-Selling und Bundles durch Reasoning
Die Ontologie versteht "Anzug benötigt Hemd und Schuhe" als logische Regel, nicht als manuell gepflegte Cross-Sell-Liste. Wenn morgen ein neuer Anzug ins Sortiment kommt, bekommt er automatisch die passenden Bundle-Vorschläge ohne manuelle Pflege. Das skaliert mit dem Sortiment, statt mit dem manuellen Pflegeaufwand.
Die Bibliothek-Analogie
Stellen Sie sich eine Bibliothek vor. Ohne Ontologie liegen alle Bücher auf einem Haufen, die Suche funktioniert nur über den exakten Titel. Mit Ontologie gibt es Regale (Kategorien), Querverweise ("wer das mochte, mag auch jenes") und thematische Empfehlungen ("für dein Reise-Interesse passt dieses Reiseführer-Set"). Ihre Produktdaten werden zu einer Bibliothek, die ihre eigenen Beziehungen kennt, statt zu einem Haufen, in dem nur exakte Treffer möglich sind.
10x
schnellere Beziehungs-Abfragen gegenüber relationalen Joins
Für Abfragen, die mehrere Hops zwischen verknüpften Entitäten machen müssen (Beispiel: "finde alle Produkte, die zu Anlässen passen, die im Sommer typisch sind, im Preisbereich X"), liefert eine Graph-Datenbank gegenüber einer relationalen DB mit Multi-Table-Joins deutlich höhere Performance. Bei einfachen Single-Attribut-Abfragen ist der Unterschied geringer, dort liegt der Vorteil im KI-Reasoning, nicht in der Latenz.
Warum Ontologien bei komplexen Beziehungen überlegen sind
Merkmal
Tabelle (SQL/PIM)
Graph (Ontologie)
Struktur
Starr (Spalten und Zeilen)
Flexibel (Netzwerk aus Knoten und Kanten)
Beziehung
Schwer abzubilden, viele Joins nötig
Nativ ("ist verwandt mit", "passt zu")
KI-Fähigkeit
Gering (nur Suche nach Text)
Hoch (versteht Kontext und Inferenz)
Schema-Änderungen
Migration aller Tabellen nötig
Neue Beziehungen einfach hinzufügen
Multi-Hop-Abfragen
Performance bricht ein
Native Stärke der Graph-DB
Tech-Stack: RDF und OWL als W3C-Standards
Wir nutzen die W3C-Standards RDF (Resource Description Framework) und OWL (Web Ontology Language). Das sind die Standards, auf denen Teile des modernen Webs basieren. Speicherung in Neo4j, AWS Neptune oder etablierten Triple Stores. Abfragesprache ist SPARQL. Kein proprietäres Format, keine Vendor-Bindung.
Drei Fragen, die CDOs und AI Architects stellen
Nein. Die Ontologie liegt parallel zum PIM, nicht statt des PIMs. Das PIM bleibt die Quelle der Wahrheit für Stammdaten (Material, Größe, Preis, Lieferant). Die Ontologie ergänzt die semantische Schicht: Beziehungen, Kategorisierung, Anlass-Zuordnung. Beide Systeme synchronisieren sich kontinuierlich, das PIM-Team ändert nichts an seinem Workflow.
Initial wird die Ontologie aus bestehenden Daten generiert: Klassifikationssysteme (ECLASS, ETIM), Kategorienbäume, historische Cross-Sell-Daten und KI-gestützte Beziehungs-Vorschläge. Im laufenden Betrieb pflegen Sie nur die High-Level-Konzepte, neue Produkte werden automatisch über ihre Attribute in den Graphen eingeordnet. Manuelle Pflege ist die Ausnahme, nicht die Regel.
Drei messbare Effekte: bessere Conversion durch semantische Suche (Nullsuchen sinken), höherer Warenkorbwert durch kontextgetriebene Cross-Sells (Bundles statt Einzelartikel), und höhere Auffindbarkeit für Long-Tail-Suchanfragen, die heute ins Leere laufen. Welche Effekte bei Ihnen dominieren, hängt vom Sortiment und der Suchnutzung ab.
Verwandte Deep Dives
Taxonomie und Klassifikation
Taxonomie ist die hierarchische Baumstruktur (Kategorie, Subkategorie). Ontologie ist das Netz, das diese Hierarchien um Beziehungen erweitert.
Golden Records und Master Data
Bevor eine Ontologie aufgesetzt wird, sollten die Stammdaten konsolidiert sein. Golden Records liefern die saubere Basis.
// ONTOLOGIE-ENGINEERING
Datenmodellierung besprechen.
Zeigen Sie uns Ihr aktuelles Datenmodell und ein typisches Such- oder Recommendation-Problem, das heute schlecht funktioniert. Wir skizzieren eine Ontologie-Architektur, zeigen Ihnen anhand Ihrer Daten, wie die Beziehungen aussehen würden, und sagen Ihnen, was die Implementation kostet. In einer Woche.