In the first two articles of the Ontology series, we built the foundation. Part One introduced ontology, which has become essential in the AI era: it grounds machine intelligence in deterministic semantics, eliminates data fragmentation, and provides the shared understanding that operational AI systems require. We also showed how graph databases serve as the natural engine for making ontology practical.

Part Two moved from theory to practice. We identified the five warning signs that signal an urgent need for ontology (multi-system fragmentation, high compliance demands, long decision chains, high heterogeneity, high inference cost) and outlined the four‑stage maturity journey—from local pilot to intelligence‑driven enterprise brain.

Now we turn to real‑world action. In Real World Example #1, we explored how ontology transforms fraud detection. We showed that fraud is a relationship problem: attack patterns hide in connections between devices, accounts, and legal entities. With ontology, suspicious patterns become machine-readable rules; with NebulaGraph, those rules execute in milliseconds at a global scale.

Now we shift from risk to revenue: recommendation systems. Here, the core challenge is different but equally semantic: not all relationships carry the same meaning.

What This Post Covers:

• Why Ontology Matters for Recommendations: Traditional systems treat every relationship as interchangeable. Ontology defines explicit relationship types, so algorithms can weight connections by semantic meaning, not just existence.

• Case Study – Snapchat: How the social platform uses ontology-driven graph queries to generate friend recommendations for 432 million daily active users, leveraging multi-hop traversals at sub-second latencies.

• Industry Extension: Why ontology is essential for solving the cold-start problem across social, e-commerce, and content platforms—and how "ontology + graph databases" is becoming the new standard for recommendation infrastructure.

The Core Insight: Relevance Depends on Typed Relationships

Recommendation systems at scale face a challenge that is obvious only after you state it: not all relationships are the same. A "friend" relationship implies a different affinity than a "follower" relationship. A "colleague" connection suggests different recommendations than a "family" connection. A "purchased" edge between a user and a product is qualitatively different from a "viewed" edge.

Traditional recommendation systems treat all relationships as interchangeable. They store edges without typing them semantically. They compute affinity scores based on raw interaction counts—five views of a product is "five," regardless of context.

This approach works adequately at a small scale. But as the graph grows to billions of nodes and trillions of edges, the lack of semantic typing becomes a scalability and accuracy bottleneck. The system cannot distinguish between a user who watched a product video for ten seconds and a user who made five repeat purchases—unless the ontology explicitly defines these as different relationship types with different semantics.

Ontology solves this by making relationship types explicit and enforceable. The ontology for a recommendation system defines:

• Node types: User, Product, Category, Device, Session

• Edge types: PURCHASED, VIEWED, ADDED_TO_CART, SHARED_WITH, FOLLOWS, IS_FRIEND_WITH

• Properties: timestamps, duration, frequency, affinity scores

• Inheritance: PREMIUM_USER is a subclass of USER, inheriting all user properties while adding LoyaltyTier and PurchaseHistoryDepth.

• Constraints: Friend recommendations should not suggest direct family members in certain contexts. Product recommendations should prioritize PURCHASED edges over VIEWED edges by a configurable factor.

With these semantic definitions in place, the graph database can compute recommendations that are not just fast but contextually accurate. The recommendation algorithm can weight different edge types differently. It can follow relationship hierarchies. It can apply the ontology's constraints automatically.

How Ontology and Graph Databases Work Together in Recommendations

Before diving into the case study, let’s clarify how ontology operates inside a recommendation system.

Humans define the ontology; the graph database executes it automatically. Domain experts build the ontology once: they specify entity types (User, Product, Content), relationship types (FRIEND_WITH, PURCHASED, VIEWED), properties (interaction_frequency, recency), and constraints (“a FRIEND_WITH edge with no interaction for 90 days is deprecated”). This is a design‑time activity.

Once deployed, the graph database (NebulaGraph) stores the ontology as an enforceable schema. Every write—a new friendship or a product view—is automatically validated. Every query uses the ontology to know which edges to traverse and how to weight them.

Critically, ontology solves the cold‑start problem. A new user has no interaction history, but their attributes (company email domain, location, device type) map to existing semantic categories. The system can immediately recommend what similar users like, making personalization possible from the first login.

Case Study: Snapchat – Friend Recommendations at 432 Million Daily Active Users

Snapchat, the social media platform, serves over 432 million daily active users worldwide. To generate friend suggestions at this scale, the system must compute heuristics that leverage user relationships—often requiring multiple traversals across a dense, interconnected social graph. This is a task where graph databases excel and traditional relational databases fail.

The Challenge: Relationship Semantics at Scale

Snapchat’s recommendation engine doesn’t just need to know who is connected to whom. It needs to know how they are connected. A user who exchanges Snaps daily with a friend should influence recommendations differently than a user who exchanged a single message three months ago. Without an ontology, all FRIEND_WITH edges look identical; the system cannot prioritize close friends over distant acquaintances.

The Ontology-Driven Solution

Snapchat’s infrastructure team chose NebulaGraph after evaluating multiple graph databases. What makes their implementation ontology-driven is how they model relationship semantics:

• Typed edges with properties. The graph stores not just “User A – connected – User B” but typed relationships: FRIEND_WITH (mutual follow), COWORKER_OF (inferred from contact uploads), and  SHARED_INTEREST_IN (derived from content interactions). Each edge carries ontology-defined properties: interaction_frequency, recency_of_interaction, mutual_friend_count.

• Ontology-defined constraints. The ontology specifies that a FRIEND_WITH edge with no interaction for 90 days should be deprecated for recommendation purposes. A COWORKER_OF edge inferred from a single contact upload requires additional validation.

• Inheritance. A “CloseFriend” is a subclass of “Friend” that inherits all Friend properties but adds higher default affinity weight and shorter recency windows. The same traversal query—“find friends of friends”—behaves differently depending on whether the starting user has a “CloseFriend” relationship type.

• Runtime execution. When a user opens Snapchat, the graph database executes a query: “Starting from this user, traverse FRIEND_WITH edges (prioritizing those with high interaction_frequency and recency), then traverse one more hop to retrieve candidates, then filter by mutual friend count > 2.” The ontology tells the system which edges to follow and how to weight them; NebulaGraph executes the traversal in milliseconds across billions of nodes.

Snapchat plans to leverage NebulaGraph for ML edge feature storage, eliminating the overhead of materializing costly multi‑hop features for real‑time inference. This is ontology in action: the ontology defines what features matter; the graph makes them queryable in production.

Industry Extension: Why Every Social Platform and E‑Commerce Site Needs Ontology

Snapchat is not alone. The entire social media industry has discovered that social graphs without typed edges are just dense clusters of identical connections. LinkedIn’s “People You May Know” relies on an explicit ontology of professional relationships (COLLEAGUE_OF, ALUMNI_OF). Spotify’s “Discover Weekly” distinguishes between LISTENED_FULLY, SKIPPED_EARLY, and  ADDED_TO_PLAYLIST—each with different semantic weight. Pinterest’s “More Like This” uses an ontology of visual and contextual relationships.

The lessons from Snapchat extend far beyond social media. E‑commerce platforms face an analogous problem: recommending products to users based on complex behavioral relationships. An ontology‑based e‑commerce recommender system combines symbolic reasoning with deep semantic matching, using graph databases to capture structured product relationships. By exploiting ontologies—structured frameworks defining links between concepts in a domain—recommendation systems can capture semantic meanings lying behind both product qualities and user preferences, making the recommendation process more aware of the context.

What makes ontology essential in this domain is the cold start problem. New users have no interaction history. New products have no purchase data. Without ontology, recommendation systems cannot make meaningful suggestions for cold entities. With ontology, the system can fall back on semantic relationships defined in the ontology: a new user who signs up with a corporate email domain might inherit preferences from other users in the same organization; a new product in the "wireless headphones" category inherits relationship patterns from existing headphones in that category.

This is the power of ontology in recommendation: it makes knowledge transferable. Relationship semantics defined once can be applied to new entities without retraining models. The ontology becomes the knowledge base that every recommendation algorithm shares, eliminating the need for each algorithm to rediscover what "similar" means.

For any platform with a social graph or user‑item interactions, the lesson is clear: without relationship typing, you are drowning in undifferentiated connections. Investing in an ontology layer is the difference between generic recommendations and truly personalized engagement.

Conclusion: Relationship Semantics Are the Future of Recommendation

In this article, we’ve shown that recommendation is also a relationship problem—but with a crucial twist: the type of relationship matters as much as its existence. A close friend is not an acquaintance. A repeat purchase is not a casual view. Ontology makes these distinctions explicit, machine‑readable, and enforceable.

When ontology is embedded in a graph database like NebulaGraph, the system becomes operationally intelligent. Queries that would require dozens of joins become single traversals. Cold‑start users receive relevant suggestions based on their ontological attributes. Recommendation algorithms can weight different relationship types automatically—without hard‑coded logic scattered across application code.

If your organization runs a recommendation system—for friends, products, content, or ads—the path forward is clear: move beyond treating all relationships as equal. Define what your connections mean. Embed that ontology in a graph database that can execute those definitions at a global scale.

Contact us today to learn how NebulaGraph Enterprise Edition can help you operationalize ontology across your recommendation workflows!

What’s Next in This Series

In the third and final article, we turn to supply chain intelligence. You will see how ontology‑driven graph technology transforms fragmented supplier data into multi‑tier visibility. Ontology doesn’t stop at fraud or recommendations; it builds the resilient supply chains that modern enterprises depend on.