How Knowledge Graphs Store Relationships
Session 0.5 · ~5 min read
To build recognition signals effectively, you need to understand how the target system actually stores information. Google's Knowledge Graph, Wikidata, and the data structures behind AI training sets all use the same fundamental model: entities as nodes, relationships as edges, and attributes as properties. This is not computer science theory for the sake of theory. It is the map that tells you exactly which signals to build.
The Node-Edge-Property Model
A knowledge graph is a network where every piece of information is stored as one of three things:
- Node: An entity. A person, organization, place, concept, or creative work. Each node has a unique identifier.
- Edge: A relationship between two nodes. "Works at," "is known for," "located in," "created by." Edges have types and sometimes weights.
- Property: An attribute of a node. "Founded in 2015," "has 50 employees," "specializes in entity SEO." Properties describe a single node, not a relationship.
In this example, Jane Smith's entity has five edges connecting it to other nodes. Each edge tells the system something specific about who Jane is and what she does. The more edges, the richer the system's understanding. The quality of the connected nodes matters too: being connected to MIT carries different weight than being connected to an unknown entity.
How Google Builds These Graphs
Google does not wait for you to declare your relationships. It constructs them from multiple data sources, cross-references them, and assigns confidence scores. The sources include:
| Data source | What Google extracts | Confidence level |
|---|---|---|
| Wikidata / Wikipedia | Structured entity attributes, relationships, categories | High (editorial, structured) |
| Schema.org markup on websites | Self-declared entity properties and relationships | Medium (self-declared, needs corroboration) |
| Web page content (NLP extraction) | Co-occurrence patterns, named entity recognition | Medium (statistical, depends on source quality) |
| Google Business Profile | Business category, location, services | Medium-high (verified by Google) |
| Authoritative third-party sites | Entity mentions, co-citation, editorial descriptions | High (independent validation) |
| Social platform profiles | Title, bio, expertise claims, connections | Low-medium (self-declared, but cross-referenced) |
The key insight is the confidence column. Not all sources are equal. Self-declared information on your own website is a starting signal, but the system does not fully trust it until independent sources corroborate it. This is why cross-platform reinforcement (Pillar 4) and earned media matter so much for recognition.
Edge Types That Matter for Recognition
Not all edges are equal for recognition purposes. Some relationship types carry more weight in determining what your entity is about.
The edges that define your entity's meaning are topical edges: "known for," "works in," "expert in," "author of." Identity edges like "located in" and "founded in" support existence. Topical edges build recognition.
The most important edge types for recognition are:
- knowsAbout / expert in: Direct topical associations
- author of / creator of: Content connected to your entity, especially on specific topics
- affiliated with: Connections to recognized organizations in your field
- mentioned alongside: Co-occurrence with other entities in your niche (statistical, not declared)
- cited by: Third-party references to your work or expertise
Wikidata as a Readable Example
Wikidata is the most transparent knowledge graph available. Unlike Google's Knowledge Graph, which is proprietary, Wikidata's data is public and browsable. It uses the exact same node-edge-property model, and Google's Knowledge Graph directly consumes Wikidata as a source.
Looking up any well-known entity on Wikidata shows you the model in action. Take any author, company, or public figure. You will see a structured list of properties (instance of, occupation, field of work, employer) and values (each pointing to another Wikidata entity). The relationships form a web that machines can traverse.
Every property in Einstein's Wikidata entry is a relationship that helps the system understand not just who he is, but what he is about. Your entity will not have a Nobel Prize, but it should have equivalent structural clarity: occupation, field of work, notable works, affiliations.
What This Means for Your Strategy
Understanding the data model changes how you approach recognition. Instead of thinking "I need more content" or "I need more backlinks," you can think in terms of the graph:
Each module in this course targets specific edge types. Module 1 builds relationship edges (co-occurrence, co-citation). Module 2 builds content and topical edges (through hub architecture). Module 3 makes all of these edges machine-readable through structured data. Module 4 validates them across platforms.
When you publish a blog post about your topic, you are creating content edges and co-occurrence data for topical edges. When a journalist mentions you alongside a peer, that is a validation edge strengthening a relationship edge. When you add knowsAbout to your schema, you are declaring a topical edge directly.
Every action in this course maps back to the graph. That is how you build recognition systematically instead of randomly.
Further Reading
- Introduction to Wikidata (Wikidata)
- Knowledge Graph Search API (Google for Developers)
- Knowledge Graph (Wikipedia)
- Schema.org Full Hierarchy (Schema.org)
Assignment
- Look up a well-known entity in your niche on Wikidata. List every property and relationship. Count the total number of edges.
- Try looking up your own entity on Wikidata and the Knowledge Graph API. Document what exists and what is missing.
- Map out every relationship edge your entity currently has. Include: topics you are associated with, organizations you are connected to, people you are co-cited with, and content attributed to you.
- Compare your edge count and types to the well-known entity from step 1. Identify the three biggest structural gaps.