Deep Dive into the world of ODPs - Knowledge Graphs Nodes
- Carolyn Klein
- 4 hours ago
- 3 min read
# Nodes (Vertices): The "Things"
What they are:
Nodes represent entities - any object, person, place, concept, or event that exists in your domain. They're the nouns of your knowledge graph.
Examples:
- People: Carolyn, employees, customers, vendors
- Organizations: Companies, departments, teams
- Systems: Applications, databases, servers, APIs
- Concepts: Business capabilities, architectural patterns, data domains
- Documents: Policies, specifications, contracts
Node Properties:
Nodes carry attributes as key-value pairs. These describe the entity's characteristics:
Node: Carolyn
Properties:
- name: "Carolyn Klein"
- role: "Principal Enterprise Architect"
- location: "Home"
- department: "Architecture"
Properties can be any data type: strings, numbers, dates, booleans, arrays.
---
Edges (Relationships): The "Connections"
What they are:
Edges connect two nodes and describe how they relate. They're the verbs of your knowledge graph. Without edges, you just have a pile of disconnected facts.
Edge Labels:
The label on an edge defines the semantic meaning of the relationship:
- WORKS_FOR
- MANAGES
- DEPENDS_ON
- INTEGRATES_WITH
- OWNS
Example:
(Carolyn) --[WORKS_AT]--> (Company)
(Application A) --[DEPENDS_ON]--> (Database B)
(Team) --[OWNS]--> (Service)
---
Directed vs Undirected Edges
This is critical for modeling real-world relationships correctly.
Directed Edges (Most Common):
Have a start node and end node with directionality. The relationship flows one way.
(Carolyn) --[REPORTS_TO]--> (Manager)
This means Carolyn reports to the manager. The reverse is NOT implied - the manager doesn't report to Carolyn.
Real-world examples:
- FOLLOWS (on social media - you follow someone doesn't mean they follow you back)
- DEPENDS_ON (App A depends on Database B, but Database B doesn't depend on App A)
- PURCHASED (Customer purchased Product)
Undirected Edges (Less Common):
Represent symmetric relationships where direction doesn't matter.
(Person A) --[MARRIED_TO]-- (Person B)
(System A) --[CONNECTED_TO]-- (System B)
If A is married to B, then B is married to A. The relationship works both ways equally.
---
Edge Properties
Just like nodes, edges can have properties too. This adds rich context to relationships:
(App A) --[DEPENDS_ON {
type: "database",
latency_ms: 45,
last_checked: "2026-01-29",
criticality: "high"
}]--> (Database B)
Useful edge properties:
- since - When the relationship started
- strength - How strong the connection is (0-1 scale)
- weight - Importance or cost
- type - Subcategory of the relationship
- confidence - How certain you are about this relationship (for ML-derived graphs)
---
Putting It Together: A Real Enterprise Architecture Example
Let's model a simple slice of an enterprise system:
(API Gateway)
|--[ROUTES_TO {protocol: "HTTPS"}]--> (User Service)
|--[ROUTES_TO {protocol: "HTTPS"}]--> (Order Service)
(User Service)
|--[DEPENDS_ON {type: "read/write"}]--> (User Database)
|--[CALLS {frequency: "high"}]--> (Auth Service)
(Order Service)
|--[DEPENDS_ON {type: "read/write"}]--> (Order Database)
|--[CALLS {frequency: "medium"}]--> (Inventory Service)
(Carolyn)
|--[OWNS]--> (User Service)
|--[OWNS]--> (Order Service)
|--[HAS_GOAL]--> (Learn Knowledge Graphs)
This small graph captures:
- System architecture (which services connect to what)
- Dependencies (databases, external services)
- Ownership (who's responsible)
- Metadata (protocols, frequencies, types)
Query examples you could run:
- "What services does Carolyn own?"
- "What databases does the Order Service depend on?"
- "Show me all services that call the Auth Service"
- "Find all high-frequency API calls"
---
Key Insights
1. Nodes = Entities, Edges = Relationships
The power comes from modeling both explicitly.
2. Direction matters
Most real-world relationships are directed (one-way). Choose carefully.
3. Properties add context
Don't just model that things are connected - model how they're connected.
4. Schema flexibility
Unlike relational databases, you can easily add new node types, edge types, and properties without breaking existing data.
5. Multiple edges between nodes
Two nodes can have several different relationships:
(Carolyn) --[WORKS_AT]--> (Company)
(Carolyn) --[LIVES_NEAR]--> (Company)
---
Resources for Deeper Learning
Comprehensive guides:
Node and edge specifics:
Directed vs undirected:
---
Next steps: Once you've digested nodes and edges, Task #3 (real-world examples) will show you how companies like Google and enterprise architects use these building blocks to solve actual problems.
The universe may be fundamentally unknowable, but at least we can model small slices of it with nodes and edges.
---
Sources:
Comments