That's essentially what our knowledge graph says when you hand it a question.

Naturally, you might try to ask it something. After all, it is a knowledge graph — it should be able to find relevant knowledge and produce an answer.

Yet, it doesn't understand.

Which is a bit embarrassing, because we built the graph from text — specifically, my 2025 blog posts. But while the graph remembers entities and relationships between them, it doesn't naturally know what to do with a fresh sentence dropped in front of it.

On one side we have a graph, like this conceptual graph below with red nodes depicting posts, green nodes depicting introduced concepts, and blue nodes marking abstractions.

Figure 1. Conceptual graph of my 2025 blog posts.

On the other — a question. For example: What problem does Euler's theorem solve, and what constraint makes it solvable?

These two don't align, because they "speak different languages".

And that leaves us with a problem: how do we translate a question into something the graph can actually understand?

First attempt: Just extract entities

If you recall the graph generation process, entities were extracted from fragments of my blog posts by an LLM given the ontology — the description of entity types and relationships. That worked. We got a graph, with some deduplication cleanup, but the core process was just: LLM + ontology + a simple prompt.

Let's apply the same process to this question: "What problem does Euler's theorem solve, and what constraint makes it solvable?"

Three entities are found:

• Euler's Theorem (Concept)

• Problem Solved By Euler's Theorem (Abstraction)

• Constraint That Makes It Solvable (Abstraction)

These look like entry points to the graph. Except they aren't — at least not the last two.

The reason is simple: these entities don't have to exist in our knowledge graph. So we managed to translate the question into entities, but the graph says "I know nothing about that, sorry!".

Ensuring common vocabulary

What we are trying to solve here is known as entity linking — mapping a natural language query to entities that actually exist in the graph.

Clearly, using the same language is not enough. If you wanted to borrow a "rubber" and I only had an "eraser", we wouldn't communicate very well even though we would be talking about the same thing.

The problem is not understanding the question — it's aligning it with the graph's vocabulary.

That leads to a natural extension of the prompt: tell the LLM what entities are in the graph. That way we can ensure a common vocabulary.

I set the prompt to: "Given the following user question and a list of knowledge graph nodes, identify which nodes are relevant to answering the question."

Question: "What problem does Euler's theorem solve, and what constraint makes it solvable?"

Found Entities:

• Euler's Theorem (Concept)

• Eulerian Path (Concept)

• Traversal (Concept)

• Single Stroke (Concept)

• Graph (Concept)

• Vertex (Concept)

• Edge (Concept)

• Undirected Graph (Concept)

• Node Degree (Concept)

• Odd Degree (Concept)

• Even Degree (Concept)

• abstract:Graph-Theoretic Properties and Degrees (Concept)

• abstract:Graph and Network Structures (Abstraction)

At this point we can have reasonable faith that these entities actually exist in the graph — the LLM is selecting from a known list rather than inventing names.

But wait. Where did "Node Degree" come from?

The LLM didn't translate the question. It skipped ahead and started answering it.

"Node Degree" isn't mentioned in the question — it's the kind of thing you'd need to know to answer the question. The LLM, trying to be helpful, jumped straight to reasoning about the solution rather than mapping what was asked.

On one hand, that likely produces a useful answer. On the other, it bypasses the knowledge graph entirely — which rather defeats the purpose. So what if we actually want only the entities that follow directly from the question?

Being strict on requirements

You have to give an LLM strict boundaries, or it will try to be helpful and read your mind.

So the new prompt becomes explicit:

"Given the following user question and a list of knowledge graph nodes, identify only the nodes that are explicitly or very directly named by the question itself*. Do NOT include nodes that might be useful context or related background — only nodes whose concept is clearly present in the question."*

Result:

Question: "What problem does Euler's theorem solve, and what constraint makes it solvable?"

Found Entities:

• Euler's Theorem (Concept)

One entity. From a question with two distinct sub-questions.

There's a real gap between "what one says" and "what one means," and this prompt falls entirely on the literal side. Allowing some mind reading feels beneficial — but how much before the LLM goes overboard and answers the question for us?

That's a hard line to draw. Which suggests maybe entity linking isn't the right frame at all.

Fundamentally different philosophy

Instead of asking "what entities are mentioned in the question?", we ask "what entities feel similar to this question?".

Following the GraphRAG community and, specifically, LangChain's implementation of local search in GraphRAG, here's the idea:

1. Encode all graph entities into embeddings (numeric vectors that capture meaning).

   

2. Embed a question

   

3. Calculate distance in meaning (i.e., semantic distance) between entities embeddings and the question embedding.

4. Use top k closest (e.g. k=5) as entry points to the knowledge graph.

This approach, called semantic retrieval, looks at graph entities and calculates which ones of them are the closest in meaning.

So what are those closest entities to our question?

Question: "What problem does Euler's theorem solve, and what constraint makes it solvable?"

Top 5 Entities with similarity scores:

• Euler's Question (Concept) - 0.599

• Euler's Recipe (Concept) - 0.583

• Euler's Theorem (Concept) - 0.580

• Leonhard Euler (Concept) - 0.544

• Euler 1735 Result (Abstraction) - 0.531

We now have two fundamentally different ways to enter the graph:

• map the question to known entities (entity linking)

• or map it to similar meaning (semantic retrieval)

They both produce entry points into the graph, but they get there differently. Entity linking tries to understand the question literally — and will either be too strict or too eager. Semantic retrieval doesn't try to understand the question at all; it just asks "what in the graph feels like this?"

Semantic retrieval also has a practical advantage: it returns exactly k results, no more, no less. Entity linking gives you however many the LLM decides to return.

These differences matter — but which approach actually leads to better answers? That's a harder question.

Wrapping up

The graph and the sentence speak different languages. To bridge them, I looked at two approaches: entity linking (map the question to named nodes) and semantic retrieval (find the nodes most similar in meaning).

Entity linking is precise but fragile — too literal and you get one node, too loose and the LLM answers the question for you. Semantic retrieval sidesteps that tension entirely by measuring meaning rather than matching names.

Both give us a way in. Which one leads somewhere more useful is what we'll find out next.

Over the past year, I kept returning to one idea: the graph-like nature of how we think.

When we think, we don’t retrieve isolated facts — we follow associations between things. Take two seemingly unrelated ideas, like eye scanpaths (paths our eyes make when looking) and climbing routes. At first, they feel worlds apart.

But let your brain pursue the topic for a few milliseconds longer — and boom. You found an association, a common denominator:

Both are just directed path graphs.

So, in essence, knowledge can be thought of as a graph — a knowledge graph (KG) [1],[2], where things are nodes that are connected with other things through mental associations.

Since this is my first post in 2026, after a two-month break, why not create a graph of knowledge embodied in my posts in 2025?

That immediately makes me ponder three questions:

• What would such a graph look like "on paper"?

• How would one search it to find this common denominator?

• And, finally, how is such a graph helpful in reasoning?

Each question demands attention, and so the story will be divided into three chapters — three separate posts — investigating representation, retrieval, and reasoning.

This post focuses only on representation — construction of the graph itself; retrieval and reasoning will follow in subsequent posts. And while I know the ending of today's chapter, I don't know yet what is there to emerge in the follow-ups. Nevertheless, here we are, entering together the world of knowledge graphs to explore their appearance and use.

Come along as I explore this world and share my findings!

All code for graph construction and visualization is available in a public GitHub repository: https://github.com/storiesinstructure/knowledge_graphs.

What I want to achieve

The idea I have in mind is simple: take my blog posts of 2025 and transform them into a knowledge graph.

In other words: take a bunch of messy written text and transform it into nodes, that clearly must represent something, and edges, that connect these nodes for some undisclosed reason.

Let's untangle this mystery step by step.

At first, I wondered, what would I even imagine this graph to contain?

What does my Wrapped 2025 graph contain?

If knowledge is a graph, then the first practical question unavoidably becomes: what exactly should exist in that graph?

In my previous posts, the meaning of nodes and edges was simple. For example, when investigating Santa's journey over European sky to deliver Christmas presents, nodes represented waypoints, and edges represented airway segments. The graph interpretation was tightly tied to a physical structure.

Here, however, we deal with a conceptual structure, and that means we have to decide on our own:

• what kind of nodes exist,

• what kind of edges exist,

• and what those types mean.

This explicit definition of what types of entities exist and how they relate to one another is called an ontology.

I thought: what if we had two such ontologies, both describing knowledge embodied in my posts, but focused on different aspects?

Conceptual Ontology

The first ontology I considered is focused on concepts, such as paths or graph traversal, and how they relate to one another.

Each post explored several such concepts. That gives us two entity types: Post and Concept, and the relationship: Post → explores → Concept.

Some concepts were related to one another, either in the same post or across posts. That can be expressed with Concept → related_to → Concept.

Sometimes, as in the above example with the connection between scanpaths and climbing routes, two or more concepts have a common abstraction. That brings my last relation of Concept → abstracts_to → Abstraction.

## Conceptual ontology 
​
Purpose: Surface recurring abstractions across domains.
​
Node types:
* Post
* Concept (path, traversal, constraint, visibility, locality)
* Abstraction (directed graph, flow, connectivity)
​
Relations:
* Post → explores → Concept
* Concept → abstracts_to → Abstraction
* Concept → related_to → Concept

Narrative Ontology

The second type of ontology that I imagined was focused on narration. Think of it as of a selection of storytelling tools that make a story.

Each post is tackling a specific problem, like: "I want to reconstruct the structure of my 2025 writing".

The problem builds tension. The current tension could be phrased as "If knowledge is graph-like, how do I even begin to construct a meaningful graph from messy prose?"

Then, the tension is resolved, everybody starts to breathe again and smile at one another. Unlike the conceptual ontology, which captures what is being discussed, this ontology focuses on how the story unfolds and on the emotions of a reader. Tension brings uncertainty, anticipation, curiosity, desire for meaning. It is released when the reader's need for resolution is satisfied: a mystery is explained, conflict ends, or a decision is made. Hence, Tension → resolved_by → Resolution.

Finding the resolution also concludes the post.

This reasoning results in the following ontology:

## Narrative ontology
​
Purpose: Capture how things are explained. 
​
Node types:
* Post
* Problem
* Tension
* Resolution
​
Relations:
* Post → introduces → Problem
* Problem → leads_to → Tension
* Tension → resolved_by → Resolution
* Post → concludes_with → Resolution

Are my ontologies any good?

Having constructed this narrative ontology, I was still experiencing a lot of uncertainty. Shouldn't I have a story as a top entity, instead of the post? Shouldn't there be a direct relationship between the post and the tension?

And I don't know the right answers yet.

I decided to leave the ontologies as they are, instead of making them "perfect", and I expect that my further investigation on retrieval and reasoning (in the two follow-up posts) will lift the veil.

For now, I've established the types of nodes and edges, as well as their meaning. The next step is to construct the actual graphs and see what structure emerges.

First Attempt: Greedy Graph

To start, I needed to extract entities and relationships from text.

I cut my posts into ~2000-character fragments (roughly paragraph-sized). Then, I handed each piece and an ontology description to a Large Language Model (LLM). The LLM's job was to find entities (nodes) and relationships (edges) whose types appear in the ontology. This means that the LLM was not allowed to invent any new types. At the end, I added Post nodes programmatically: each post is connected to the entities extracted from its text.

For each ontology I got a graph. Knowing that my posts discussed intertwined ideas, I expected a lot of edges that link one post to another.

To my surprise, I saw very little of these connections in the conceptual graph (Fig. 1)!

Figure 1. Knowledge graph constructed with conceptual ontology from my 2025 blog posts. Nodes: red - posts, green - concepts, blue - abstractions.

The most connected Concepts were those of "Node" and "Edge", which is not surprising since I used these exact words in my every post. That also shows that when exactly the same words were used across my posts, these were unified during the graph construction.

But I wasn't satisfied! I would want the "Nodes" Concept node to be unified with the "Node" one. Yet, it wasn't. There were obvious duplicates in my graph!

The second problem I spotted are blue Abstraction nodes that are floating around, disconnected from Concepts and without a direct connection with any Post. In my conceptual ontology, Abstraction was supposed to be above the Concept , which I modelled with the relation Concept → abstracts_to → Abstraction.

Having Abstraction nodes floating around means they can’t be reached from a post or concept during traversal.

Figure 2. Most of the Abstraction nodes in the conceptual graph (marked with cyan boxes) are disconnected from the main graph component.

Before we move on, let's have a look at the narrative graph (Fig. 2), because it is even more disconnected. The graph is made of five large components (i.e. parts of a graph that are fully separated from the rest of the graph) and three disconnected nodes (which, technically, are also graph components).

Figure 3. Knowledge graph constructed with narrative ontology from my 2025 blog posts. Nodes: red - posts, green - problems, cyan - tensions, purple - resolution.

Zooming into one post, Climbing Routes are Graphs, there were four (green) problems identified, each producing its (cyan) tension, and resolved with a (purple) resolution.

Figure 4. Narrative graph component of the "Climbing Routes Are Graphs" post. Nodes: red - post, green - problem, cyan - tension, purple - resolution.

Summarizing my first attempt: I achieved the goal of creating a graph from my blog posts, but I'm far from satisfied with the results. Maybe it's the duplicates that mess things up?

Second Attempt: Deduplicated Graph

The hypothesized major culprit were the duplicates.

To deduplicate, for each entity type (Concept, Tension, Problem, etc.), I sent the list of node names to the LLM, with the task to identify groups that are true duplicates (e.g. "SfM" and "Structure from Motion"). LLM picks a canonical name for each group, and the graph is rewired so that the edges point to the new node. Finally, old duplicated nodes are removed.

This process is called entity resolution, as it groups together entities with the same meaning, or canonicalization, as in addition to grouping — a new, canonical / standard name is assigned.

What is the visual effect of this canonicalization?

Figure 5. Canonicalized knowledge graph constructed with conceptual ontology from my 2025 blog posts. Nodes: red - posts, green - concepts, blue - abstractions.

The structure is still composed of five large components (each corresponding to a blog post), but now they are much more connected and the graph has become more spatial.

Revising a few examples of what has been merged, I'm also satisfied. See for yourselves: a new canonical name is to the left, and all merged-and-replaced nodes are to the right:

Graph Without Edges ← Point Cloud, Sparse Point Cloud, Graph Without Edges
Photos ← Photo, Photos, Few Photographs, Photographs, Additional_Photos, Set Of Flat Images
Waypoint ← Waypoint, Waypoints, Named Waypoints

The narrative graph has also improved. Posts share either a tension or a resolution, and in some cases tensions have been unified into one. For example, in How to Solve a House Puzzle, the problem of drawing a house and the problem of finding a route through all the bridges of Königsberg lead to the same tension of "Existence of an Euler Path in the Graph".

Figure 6. Canonicalized narrative graph neighborhood of the "Climbing Routes Are Graphs" post node. Nodes: red - post, green - problem, cyan - tension, purple - resolution.

Summarizing my second attempt: Deduplication fixed the obvious so the graph can actually connect. However, that hasn't solved the problem of floating abstractions.

Third attempt: Hierarchical aggregation

Why did I want abstractions?

That's a valid question to ask. I was curious what knowledge is captured in my knowledge graph without diving into details. I believe I'm not alone with the urge to have a summary or means to grasp a general idea.

Although the LLM did not succeed in linking Abstraction to Concept nodes, the hunch persists: there are groups of nodes that have something in common.

Are these groups visible in the structure of the graph itself?

I applied Louvain community detection algorithm [3] (community = dense group of nodes), and handed the results over to the LLM to summarize. That resulted in 61 communities being found in the conceptual graph:

Figure 7. Communities detected in the canonicalized conceptional graph. 337 Concept nodes and 30 Abstraction nodes were grouped into 61 communities, ranging from one member to the maximum of 35 nodes (Community 6).

Zooming in again into a single post, "Climbing Routes are Graphs", almost all the Concept nodes associated with this post were put into one community, grouping together notions around path graphs and Eulerian path existence, like so:

Community 6 (35 members)

This community links concepts from graph theory—especially Eulerian paths, node degrees, and classic problems like the Bridges of Königsberg—with analogies from rock climbing and physical structures, using routes, ropes, bolts, bridges, and airways to illustrate graphs, edges, vertices, and traversals in an intuitive, real-world way.

In the narrative graph, nodes associated with the "Climbing Routes are Graphs" post, form four communities concentrated around four different areas:

• Community 0 (3 members) ​ models a rock climbing route as a graph problem

• Community 1 (7 members) ​ centers on understanding and determining the existence of an Eulerian path in a graph

• Community 2 (3 members) ​ frames climbing as the process of turning an abstract graph of possible movements into a concrete path

• Community 3 (3 members) ​represents the modeling of visual data as sparse graphs

Figure 8. Four communities detected in the neighborhood of the "Climbing Routes Are Graphs" post node, in the canonicalized narrative graph.

Clearly, communities are the way to summarize local groups of nodes, and so each post can be briefly summarized by its communities.

Communities, however, are still not able to capture that "eye scanpath" in one post and "directed path graph" in another post are both subtypes of "directed graph", unless it is explicitly stated in the text.

Third attempt summarization: Summarization - achieved, generalization - not yet.

Fourth attempt: Generalization with hypernyms

Let me cite myself :D

Communities, however, are still not able to capture that "eye scanpath" in one post and "directed path graph" in another post are both subtypes of "directed graph", unless it is explicitly stated in the text.

What that means is that:

• "eye scanpath" IS A "directed graph"

• "directed path graph" IS A "directed graph"

• but if I never said it explicitly in the text, the connection will NOT appear in the graph.

It is telling us something: the hierarchy doesn't live in the text.

The hierarchy lives in domain knowledge.

My blog talks about specific concepts, sometimes it mentions an abstraction, but oftentimes the generalizations are implied, not stated.

So if I want to have hierarchical structure and some "super" nodes that group several concepts together into a broader domain, I have to impose this hierarchy.

Using LLM, I grouped nodes of each type into "broader conceptual categories that the members are instances or subtypes of". The LLM was free to come up with the name and the scope of these broader conceptual categories.

Effectively, I asked the LLM to cluster nodes and find a hypernym for each cluster (e.g. animal is a hypernym of elephant). Every node in a cluster is connected with IS_A edge to the cluster's hypernym.

The problem originated in the conceptual ontology, but actually it is easier to visualise the outcome in the narrative graph.

For three separate Problem nodes related to sparse spatial graphs, we got a new Problem super-node "Sparse graphs, point clouds, and spatial neighborhoods", that generalizes these three problems and also creates a new link between two posts.

Figure 9. Problems (round green nodes) and super-problems (rhombus green nodes) in the narrative graph, showing that several problems are sub-problems of a broader one. A broader problem may be discussed by more than one post (red nodes).

Similarly, for six separate Resolutionnodes, we got a new Resolutionsuper-node "Graph theory and path representations", that generalizes these six resolutions and also creates a new link between four posts.

Figure 10. Resolutions (round purple nodes) and super-resolutions (rhombus purple nodes) in the narrative graph, showing that several resolutions are sub-resolutions of a broader one. A broader resolution may release tensions that arose in more than one post (red nodes).

While I couldn't find the "directed graph" super-node, the generalization I obtained with hypernyms is close enough to what I envisioned.

Interestingly, investigating both, communities and hypernyms, allowed us to see different approaches to "zooming out" on the graph. Communities are based on edge density, so purely on the structure of the graph, whereas hypernyms are semantic — based on conceptual hierarchy.

Conclusion

I didn’t begin with a neatly defined pipeline. I began with a graph that didn’t look right. Each refinement step — deduplication, community detection, hierarchical grouping — emerged as a response to something that felt off.

But such a pipeline exists. The work of Darren et al. [4] defines the pipeline order for graph creation in GraphRAG (Graph Retrieval Augmented Generation): extract entities → resolve/merge duplicates → detect communities → summarize communities. Microsoft GraphRAG documentation [5] makes the pipeline even more explicit.

The biggest surprise was that structure doesn’t automatically "live in the text" and one has to decide where it comes from. Additionally, what felt natural to me (hypernyms) is not a common practice in the GraphRAG pipeline. That makes me wonder about the consequences of both designs for search and information retrieval.

Finally, what I find delightful is that we constructed a graph from texts that themselves explore graphs!

In my follow-up posts, I’ll treat these graphs as a retrieval layer and test what questions they answer.

References

[1] Quillian, M. Ross. "The teachable language comprehender: A simulation program and theory of language." Communications of the ACM 12.8 (1969): 459-476. https://dl.acm.org/doi/abs/10.1145/363196.363214

[2] Quillian, M. Ross. "Word concepts: A theory and simulation of some basic semantic capabilities." Behavioral science 12.5 (1967): 410-430. https://onlinelibrary.wiley.com/doi/abs/10.1002/bs.3830120511

[3] Traag, Vincent A., Ludo Waltman, and Nees Jan Van Eck. "From Louvain to Leiden: guaranteeing well-connected communities." Scientific reports 9.1 (2019): 5233. https://www.nature.com/articles/s41598-019-41695-z

[4] Edge, Darren, et al. "From local to global: A Graph RAG approach to query-focused summarization." arXiv preprint arXiv:2404.16130 (2024). - https://arxiv.org/abs/2404.16130

[5] Microsoft GraphRAG documentation https://microsoft.github.io/graphrag/index/default_dataflow/

Now that your presents are here (socks or not), join me for a moment to ponder the logistics of Santa Claus.

So how does Santa deliver your presents straight to your chimney?

Santa's Base → Your Chimney

For Santa to get to your house, three things are required: a starting point, an ending point, and a route between the two. Does that already sound like traversing a graph?

Starting Point

As a European child, I was made to believe that Santa Claus lives in Lapland, in northern Finland. For the sake of argument, let's stick to this childhood belief and assume Santa's base is in Rovaniemi — his "official" hometown.

Figure 1: Location of Rovaniemi. © OpenStreetMap contributors.

Ending Point

The second assumption we have to make is that you actually are in possession of a chimney. If you are not, then... well — how about considering the closest chimney as your own?

Why Europe?

The third assumption is that this chimney is located in Europe. Not because Santa prefers Europe, but because Europe makes the structure of the sky explicit. Relatively small countries fragment airspace into national volumes, and dense traffic requires cross-border coordination. As a consequence, local authorities publish their maps and regulations, making the system easier to explore — even for laypeople like us.

Europe is not special — each major world region implements the same global framework, only differently. Regardless of the implementation, Santa’s problem remains unchanged: finding a safe path through a constrained, shared, three-dimensional space.

Visual vs Instrument-Based Navigation

Finally, we have to decide whether Santa flies using visual cues — such as terrain, landmarks, aerodromes, lights, and light patterns — or relies on instruments that provide attitude, speed, altitude, navigation, communication, and system awareness. In aviation, these two navigation modes are formally codified as Visual Flight Rules (VFR) and Instrument Flight Rules (IFR).

Can Santa and his reindeer operate in both navigation modes?

Personally, I would be disappointed if they had not mastered both, given their many centuries of experience in present delivery.

Which navigation mode would be more reasonable to choose?

Flying using visual cues is a little like going off-road: it feels like freedom, but it does not scale well under time pressure, poor weather, or long distances. Flying on instruments, on the other hand, enables predictable routing through structured airspace, with defined coordination and separation.

Given that:

• there were 172,901 flights worldwide on Christmas Eve 2025 (see Figure 2),

• Christmas presents are of utmost priority,

• and so is Santa’s safety,

it is reasonable to assume that Santa relies on instruments and structured airspace whenever possible.

Figure 2: Total number of flights per day in 2025, based on statistics published by Flightradar24.

European airspace as a graph

We set forth the assumptions. We established the starting point, the ending point, and that it is plausible that Santa Claus operates in structured airspace under IFR.

To deliver presents to your chimney, Santa needs a route. And to determine that route, he needs to understand the underlying structure — the airspace graph. So let's explore it!

Nodes: Waypoints

Santa likely departs under local Air Traffic Control and then joins the airspace route network at a nearby waypoint. Looking at the chart below, you can spot ULROM waypoint nearby the Rovaniemi airport. This could be such first waypoint for Santa when heading south.

Waypoints are abstract nodes defined by coordinates (latitude and longitude) and identified by globally unique five-letter codes.

These waypoints are nodes in the airspace graph.

Figure 3: Rovaniemi enroute chart (excerpt). Source: Finavia / ANS Finland, eAIP Finland, ENR 6.1, accessed 22.12.2025.

Edges: Airways

Looking again at the Rovaniemi enroute chart above, you'll notice that some waypoints are connected. Look at the blue line that goes from OSLIT to ULROM, and then from ULROM to RENVI. This blue line, named Y86, is a defined airway. Moreover, it has a defined direction (denoted with arrows).

While there are only two defined airways in the vicinity of Rovaniemi, investigating Helsinki area uncovers a different story.

Figure 4: Helsinki area enroute chart (excerpt). Source: Finavia / ANS Finland, eAIP Finland, ENR 6.1, accessed 22.12.2025.

There are many more defined (blue) airways in both inwards and outwards directions. These defined airways are one type of edges in the airspace graph.

Did I just say one type? Does that mean that there are other types?

Edges: Direct connections

To answer this question, let's zoom out even more and look at the entirety of Europe. What we can see here are those defined airways (shown as black lines) that are the explicit part of the airspace graph.

Figure 5: Simplified view of the European route network. Adapted from the EUROCONTROL Route Network Chart (ERN), edition 27 November 2025. © EUROCONTROL.

But an aircraft does not always have to follow these fixed corridors.

Have you noticed curious blank spaces, for instance in France or in the Balkan area? These are the areas with no fixed corridors at all! Then how is it possible to navigate to a chimney in Rome?

What we are dealing with here is Free Route Airspace (FRA), where aircraft may fly direct between permitted waypoints while still using predefined airways where available. Green lines in the above chart depict the boundaries of FRAs, and you can easily see that free routing is possible across much of Europe.

So even though we don't get these direct edges explicitly in the charts, they are there. These implicit direct connections constitute the second type of edges in the airspace graph.

Third Dimension: Flight Levels

So far, the airspace has been described as if it were flat — defined only by latitude and longitude. In reality, aircraft also move vertically, and this vertical dimension is structured using flight levels.

A flight level is a standardized altitude reference, expressed in hundreds of feet and based on a common pressure datum. Instead of thinking in absolute altitude above sea level, aircraft operate on these shared vertical layers, allowing multiple flows of traffic to safely occupy the same geographic space.

In graph terms, flight levels extend waypoints and routes into the third dimension. The same horizontal path may exist simultaneously at multiple vertical layers, with separation enforced by assigning different flight levels to different aircraft.

Figure 6: Comparison of assorted flight level systems to scale by CMG Lee - Own work, CC BY-SA 4.0, Link.

How Santa integrates with structure

What remains to be done by Santa and his crew, is to construct a flight plan. This flight plan is exactly the path that Santa has to take to traverse a graph from the starting point to the ending point -- a sequence of named waypoints connected by a mix of predefined airways and direct segments.

In the example flight plan below, Santa departs from his base in Rovaniemi, joins the airspace structure in ULROM at flight level 280 (28,000 ft), briefly follows a published airway Y86 while climbing to FL320 by RENVI, then transitions into free-route airspace. From there, Santa completes the climb to FL340 by LUNIP and continues across Europe on a series of direct segments between waypoints, remaining at cruise altitude until leaving the en-route phase at GERVA to deliver presents to a chimney close to Rome.

F280 ULROM Y86 RENVI/F320 DCT LUNIP/F340 DCT VABER DCT NINTU DCT TUMGU DCT GERVA

This flight plan is for illustration purposes only (and is missing cruising speed). Real-world routes are validated against current airspace availability, restrictions, and traffic flows.

Nevertheless, once a flight plan is sent and approved, Santa and his reindeer can roam the airspace with no harm neither to the crew nor to the cargo.

Conclusion

The key take-away message from this post is that airspace is a directed graph with waypoints as nodes, airways (both explicit and implicit) as edges, and with flight levels that extend these nodes and edges into the third dimension.

Even if Santa Claus does not exist.

Figure 7: The hazards of chimney-based logistics. (Image generated with OpenAI’s DALL·E via ChatGPT.)

Notes

• Waypoints, along with their details, are listed in Chapter ENR 4.4 of the country’s electronic Aeronautical Information Publication -- eAIP, such as this eAIP for Finland.

• In addition to abstract waypoints, there are also legacy nodes based on physical radio infrastructure. Those radio navigation aids are listed in Chapter ENR 4.2 of eAIP and are denoted with 2- and 3-letter codes.

Have you ever wondered what you’re actually looking at when you look?

Have you ever wondered why someone would want to know what you’re looking at?

It's no surprise anymore that our behavioural data is valuable. Roughly speaking, two worlds care most about where we direct our eyes. Scientists—from psychology and neuroscience to computer vision—study eye movements to understand how the brain consumes and digests information. Meanwhile, industry uses attention as a lever: advertisers, designers, retailers, game studios, and even car manufacturers want to know what people notice first and what they miss. One side seeks understanding; the other seeks influence.

What Do You See When You Look?

So what do you actually see when you look at an image? Do your eyes sweep from left to right, top to bottom? Do they lock onto whatever sits in the center? Are you selective? Or is your curiosity evenly spread across the whole image?

To explore this, here’s a small experiment. Look at the image below for five seconds and simply notice what your eyes settle on.

Figure 1. Image from Object and Semantic Images and Eye-tracking (OSIE) dataset.

Saliency

All of us look differently, so what caught your attention might be different from what someone else fixated on, but not that different — we all tend to focus on things that stand out: colour, luminance, pattern, or size. In scientific terms, whatever stands out in a scene and attracts attention has a property called saliency.

Saliency is often visualized using saliency maps. Intuitively, you can imagine multiple people looking at the same image and each fixation increasing a kind of “attention counter” around where it landed.

In practice, rather than incrementing single pixels, each fixation is turned into a small, blurred Gaussian blob, because eye movements are never perfectly precise. By adding these blobs from many viewers and normalizing the result, we obtain a heatmap showing which parts of the image were most likely to attract attention.

Go ahead and compare what regions you looked at with what other people's eyes found attractive.

Figure 2. Left: saliency map. Right: the same saliency map overlaid on the original image.

Saliency tells us where people tend to look. But that's not the whole story. You didn’t look at all these points at once. Your eyes travelled — one point at a time.

What you looked at formed a sequence.

Scanpath

While saliency is fairly universal, the sequence your eyes constructed while jumping from one interesting region to another is much more of a personal trait. These eye jumps are called saccades, and the points your eyes land on are fixations. Alternating fixations and saccades form a scanpath.

Below are two examples of such scanpaths.

Figure 3. Examples of scanpaths from two different people on the same image.

We’ve seen something similar before.

Recall my post on climbing routes as path graphs. There, we looked at a graph where security bolts were nodes connected with a rope. Here we are also observing a graph, but this time every fixation is a node and every saccade is an edge joining two consecutive fixations. Unlike the debatable case of climbing routes, this time it is definitely a directed graph.

Interestingly, recent research shows that humans often return exactly to previous fixation locations (Kümmerer and Bethge 2021). In this light, the graph we observe is a directed graph that can include cycles.

Prediction

As I wrote at the beginning, two forces drive research on visual attention: science and industry. And both care for the same reason — our gaze is not random. It is structured. It can be measured, modeled, and, with the right tools, predicted.

From scanpaths to sequences

A scanpath isn’t just a collection of points — it’s a sequence. Each fixation depends on the ones before it, just as each step in a sentence depends on earlier words.

This is why predicting gaze is conceptually similar to how language models work:

given the context and the sequence so far, what comes next?

In text, the next element is a word.

In visual attention, the next element is a fixation.

From sequences to spatial graphs

But unlike text, scanpaths live in space. Every fixation is a node located somewhere in this space, and the saccades your eyes make form a directed graph through this space. Predicting attention, then, becomes a graph problem:

choose the next node, given the whole scene and the path so far.

This graph-based view lets us reason about attention as a spatial process — something language models don’t have to deal with.

Why this matters for shopping

Now consider what this means in the real world — especially in late November, when retailers run the world’s largest attention experiment. Saliency tells you what stands out, but it is your scanpath that determines which products you consider first, which you compare, and which you never see.

Retailers care because it affects revenue, but that's only a narrow slice of what gaze enables. Our gaze is central to exploration, communication, navigation, coordination, and social connection. So, ultimately, what you look at is extremely powerful in almost every domain of life.

Summary

Your gaze leaves a trace: a directed graph constructed as your eyes traverse from one salient point to another. This graph can be learned, modeled, and predicted.

And that is precisely why your attention is valuable and in high demand.

So go enjoy letting your eyes wander across those Christmas presents!

Next time, we'll see how Santa manages to deliver all of them down your chimney. Ho ho ho!

Further Reading

Scanpath prediction models

• Yang, Zhibo, et al. "Unifying top-down and bottom-up scanpath prediction using transformers." Proceedings of the IEEE/CVF Conference on Computer Vision and Pattern Recognition. 2024. [Article at CVPR 2024]

• Li, Peizhao, et al. "UniAR: A Unified model for predicting human Attention and Responses on visual content." Advances in Neural Information Processing Systems 37 (2024): 106346-106369. [Article at NeurIPS 2024]

• Cartella, Giuseppe, et al. "Modeling Human Gaze Behavior with Diffusion Models for Unified Scanpath Prediction." Proceedings of the IEEE/CVF International Conference on Computer Vision. 2025. [Article at ICCV 2025]

• Kümmerer, Matthias, Matthias Bethge, and Thomas SA Wallis. "DeepGaze III: Modeling free-viewing human scanpaths with deep learning." Journal of Vision 22.5 (2022): 7-7. [Article in Journal of Vision]

• Kümmerer, Matthias, and Bethge, Matthias. "State-of-the-art in human scanpath prediction." arXiv preprint arXiv:2102.12239 (2021). [Article on arXiv]

Consumer choice

• van der Laan, Laura N., et al. "Do you like what you see? The role of first fixation and total fixation duration in consumer choice." Food Quality and Preference 39 (2015): 46-55. [PDF]

• Nordfält, Jens, and Carl-Philip Ahlbom. "Utilising eye-tracking data in retailing field research: A practical guide." Journal of Retailing 100.1 (2024): 148-160. [Article in Journal of Retailing]

Saliency in Neuroscience

• Foulsham, Tom, and Geoffrey Underwood. "What can saliency models predict about eye movements? Spatial and sequential aspects of fixations during encoding and recognition." Journal of vision 8.2 (2008): 6-6. [Article in Journal of Vision]

• Veale, Richard, Ziad M. Hafed, and Masatoshi Yoshida. "How is visual salience computed in the brain? Insights from behaviour, neurobiology and modelling." Philosophical Transactions of the Royal Society B: Biological Sciences 372.1714 (2017): 20160113. [Article link]

OSIE Dataset

• Xu, Juan, et al. "Predicting human gaze beyond pixels." Journal of vision 14.1 (2014): 28-28. [Article in Journal of Vision]

In this short guide, you’ll run a Structure-from-Motion pipeline using Meshroom, a free and open-source photogrammetry tool that recreates 3D geometry from photographs.

On our agenda:

• Run a Structure-from-Motion pipeline step by step.

• Troubleshoot common issues (like the “white mesh” bug).

• Explore further resources and projects that shaped photogrammetry.

DIY

Software

My preferred software for photogrammetry is Meshroom. It performs the entire pipeline and is free and open source.

(You can find links to other software and related tutorials in the resources section.)

Steps

What you'll need: a computer with a decent GPU and at least 10 GB of free disk space.

1. Download Meshroom for your operating system.

2. Download the photo set of The Waiting sculpture (≈ 610 MB).

   Link to Google Drive

   Unzip it into a folder — you’ll load this into Meshroom in step 5.

3. Start Meshroom and select Photogrammetry from the available pipelines.

4. Save the project.

5. Drag and drop the folder of images.

6. Hit Run and grab yourself a drink. It will take a moment for the pipeline to complete.

   Observe the colours of the pipeline’s steps — green = success, orange = in progress, blue = awaiting, red = error.

7. Once the pipeline completes successfully, you will see the sparse cloud.

8. To view the mesh, double-click the Meshing component. It will appear in the Scene menu on the right-hand side, where you can toggle it on and off. If the mesh is white or not visible, head to the It Doesn’t Work 😱 section.

9. To view the textured mesh, double-click the Textured Mesh component. It will also appear in the Scene menu. If the mesh is white or not visible, head to the It Doesn’t Work 😱 section.

10. To view the dense point cloud, go to the Meshing component, scroll down to Dense Point Cloud, and double-click it. It will appear in the Scene menu on the right-hand side, where you can toggle it on and off.

It Doesn’t Work 😱

❗ Unfortunately, the current Meshroom release has a bug — the meshes sometimes appear completely white. The meshes are fine, but we’ll need different software to render them.

If your meshes are white or do not show up:

1. Install MeshLab.

2. In Meshroom, click the Meshing step and copy the path to your mesh.

3. In MeshLab, go to File → Import Mesh, and paste the path you just copied from Meshroom.

4. In Meshroom, click the Texturing step and change the File Type to PNG. Copy the path to your Mesh.

5. Recompute the Texturing step.

6. Once it completes, go back to MeshLab, choose File → Import Mesh, and paste the path you just copied.

Further Exploration

If you’ve made it this far — congratulations, you’ve built your first reconstruction 🎉

If you’d like to go deeper, below are a few excellent resources worth exploring.

Computer Vision Theory

• Szeliski, Richard. Computer Vision: Algorithms and Applications. Springer Nature, 2022. Free download. See Section 11.4: Multi-frame Structure from Motion.

• A 4-minute video explaining the problem solved by Structure-from-Motion (from First Principles of Computer Vision).

• Lecture on Structure-from-Motion — deriving a sparse point cloud and calibrated cameras (CVRP Lab, NUS).

• Lecture on Multi-View Stereo — algorithms that estimate pixel-wise depth to densify the point cloud (CVRP Lab, NUS).

• Two classic surface-reconstruction algorithms: Poisson Surface Reconstruction and the Ball-Pivoting Algorithm.

Projects that Changed the Landscape

• Building Rome in a Day — a University of Washington project that showed it was possible to reconstruct an entire city from thousands of publicly shared tourist photos.

Between Lectures and Tutorials

• Excellent video on Topographic Point Clouds and Structure from Motion by Ramon Arrowsmith (OpenTopography).

Software Tutorials and Documentation

• AliceVision Photogrammetry Pipeline — documentation describing each step and the algorithms behind it.

• Faraglione with Agisoft Metashape (by Chelsea Scott) — introduces a drone photo dataset from Vulcano Island, Italy you can also process in Meshroom.

• RealityScan (formerly RealityCapture) — now free for individuals earning under $1 million USD per year. What’s remarkable about RealityScan is that it connects directly to the Unreal Engine ecosystem, letting you bring your 3D scans straight into interactive environments and games.

  • RealityCapture to Unreal Engine: Beginner’s Guide

  • Crafting 3D Models with RealityCapture – Unreal Fest Prague 2024

Next Investigation

Every reconstruction is a small investigation — a way of recovering structure and understanding how things connect.

Next time, we'll put our own brain under scrutiny: we'll follow our eyesight and observe how picky, and how seemingly disordered, it is.

In other words, we'll look into the mechanisms of visual attention.

Have you watched the Bellingcat film? In case you haven’t, it follows a group of investigative journalists who uncover what really happened during the 2017 Atarib bombing in Syria. As tragic as the event was, their work is truly astonishing. They managed to create a time-aware 3D reconstruction of the street from videos and photos recorded by local people during the attack.

That was mind-blowing. Don’t we need 3D scanners or LiDAR to do that? Can we really just stitch together a handful of imperfect photos to recover the geometry of an object — or of a city?

To see what I mean, explore these 3D models of the recently destroyed Al-Shati and Jabalia districts in Gaza, also produced by Bellingcat.

Figure 1: Screenshot of the Al-Shati 3D model from "Killing the Journalist Won’t Kill the Story" — Documenting the Destruction in Gaza From the Sky.

Mind you, I watched the Bellingcat film seven years ago. Technology has evolved: AI models have become remarkably good at guessing plausible 3D forms from just a few shots, especially for familiar object classes. But they still struggle to reconstruct arbitrary objects or large scenes faithfully.

Today, I’d like to invite you to join me in an investigation — to see whether we can preserve one valuable thing in its three-dimensional form, and whether there’s something curious about the structure we uncover.

In other words, let’s see how far curiosity and a few photographs can take us.

Investigator's Toolbox

How do you rebuild a shape when all you have are photos? Think of this as the first step in any investigation: draw what you know, and see what’s missing.

Sketching the Truth

Let’s have a look at a photo of The Waiting sculpture to guide our thinking.

Figure 2: The Waiting sculpture in Wrocław, Poland.

From a single viewpoint, the sculpture is flat. Since we already have an idea of what people and armchairs look like, we can make an informed guess about its geometry — and this is exactly what AI models do: they make an informed guess based on the chairs and humans they were trained on.

To improve our certainty that the sculpture’s structure is as we imagine it, we would need more photos. Ideally, we would put our camera into motion and take photos from various angles and levels.

Figure 3: The Waiting from various viewpoints.

Even if you’ve never seen this sculpture in the real world, you can form a pretty good idea of how it looks by analyzing this handful of photos.

We can even follow features — or simply characteristic points — of the sculpture as they move through the photos. For instance, look at the right elbow (yellow dot) and the left knee (red dot) of the woman, and observe how their visibility, locations, and distance change as the camera moves.

These are just two sample points; nothing prevents us from choosing more: the ear, the nose, a finger, a specific hair “bubble,” the arms of the armchair, bumps on the back of the armchair, and so on. For each pair of features, we can again investigate their visibility, location, and distance for each camera position.

That gives us a lot of constraints — a lot of equations. And then it’s like solving a Sudoku puzzle: the solution tells us that the knee has to be exactly here and the elbow exactly there — otherwise, the constraints wouldn’t be satisfied and the whole puzzle would be wrong.

Once we solve the puzzle, we obtain a point cloud of features extracted from the photos. As if we were Claude Monet, sketching the sculpture in impressionist dots.

Figure 4: The Waiting sparse point cloud.

So far, we've drafted the truth and established the key facts. What comes next is the core of an investigator's job — we need to connect the dots.

Refinement

A sparse point cloud is truth reduced to coordinates — a graph without edges. Enough to prove existence, not enough to reveal form.

The next step is simple: connect the nodes.

At this stage, the process is straightforwards. We look at known facts — our features, our characteristic points — and they serve as anchors (undeniable truth). Between those anchors lie pixels, and we can estimate where in space those pixels fall between the anchors. That’s how we densify the point cloud.

Figure 7: The Waiting dense point cloud.

Every 3D point also shares a spatial relation with points beside it — they are spatial neighbors. In our graph, that relation is represented by an edge. Curiously, we are not interested in pairs of neighbors, but in trios. We aim to discover small communities of three mutual neighbors and connect them in a triangle.

Figure 8: Closer look at the knee of the The Waiting sculpture mesh.

From the standpoint of graph theory — this triangle is a small, three-node cycle. So the refined picture of truth is a graph filled with cycles, each cycle formed by three nodes, and every node belongs to at least one such cycle.

From the standpoint of computer graphics — this triangle is a mesh face. So the refined picture of truth is a mesh that can be rendered, 3D-printed, and stored on a hard drive.

Figure 9: The Waiting as a textured mesh.

Summary

We’ve followed the path of an investigation.

Starting with fragments — photographs, viewpoints, features — we reconstructed structure.

At its core was Structure-from-Motion: the algorithm that relates features and cameras, solving the optimization puzzle that reveals both a 3D point cloud and the positions and orientations of the cameras.

Around it, a sequence of other techniques helped refine the result: feature extraction, feature matching, Multi-View Stereo for densification, surface reconstruction for meshing, and texture mapping for color.

Together, they turned a set of flat images into a geometry of truth — a structure that lets us hold a fragment of reality in digital form.

That same logic is used by investigative journalists to recover what war or disaster tried to erase. But anyone can use it — to preserve a place, an object, or simply to see the hidden geometry of the world.

And as every investigation ends, a few new questions arise:

• What happens when we hand this process to AI?

• How do we scale it up, and how do we reference our geometry to the real world?

• What would it mean to look not just at what is there, but at what we notice?

Because in the end, every reconstruction begins with attention — where we choose to look, and what we decide to connect.

Before we turn to perception, in my next post we’ll take a brief detour into practice — a DIY reconstruction you can try yourself.

And after that, we’ll pay our attention to visual attention itself.

I understand your confusion. We were supposed to talk about graphs, and here I am, talking about rock climbing and climbing routes instead. I am a climber. Be it indoors or outdoors, be it rocks or mountains — doesn’t matter too much. But I’m not going to talk about climbing per se. Instead, let me show you where you can find graphs in this sport.

From Rock to Graph

It is still (kinda) warm outside, so let’s enjoy the sunshine and inspect this rock below.

Figure 1: Route “Pesce d'Aprile”, Massone - Sector A, Arco, Italy. More show-off photos available on the Planet Mountain website.

I gave you no other choice but to notice the graph immediately — you can easily spot the red nodes and lime edges.

The red nodes are where metal bolts are located. These bolts are part of the climber’s safety system: you clip the rope into them using a climbing quickdraw. In principle, if you accidentally fall, the last bolt clipped into is what you'll be hanging from.

Figure 2: Climbing security system — bolts, quickdraws, and rope.

Bolts are conceptually connected by the imaginary path that goes from one bolt to the next. This path gives the climber an idea of where the route goes and guides them on which direction to take next.

When a climber ascends the route, the rope connects each bolt in sequence — and the imaginary graph becomes traversed.

In that moment, the graph stops being abstract. You’re not just observing the structure — you're moving through it, edge by edge.

Recap on Graphs

Let’s look back at what we’ve talked about in the introductory post on graphs. What can we tell about this graph?

We observe a simple structure: two end nodes have degree 1, and all the nodes in between have degree 2. It's a textbook example of a path graph (Gross and Yellen, 2003, p.18). A path graph is a type of tree, and all the nodes and edges can be laid out on a straight line — like the rope a climber takes from the bottom to the top.

Since there are exactly two nodes with odd degree, there exists an Euler path in this graph (see the introductory post on graphs!) That's good news, because Euler's theorem proves that getting to the top is doable! (Now it is “merely” a matter of one’s skills…)

Finally, is it a directed graph? It’s a bit of a philosophical question. Typically, one would go up, in which case — yes. But you can't really prevent anyone from going down if they wish. Unusual? Sure. Impossible? Definitely not.

Conclusion

When we map a climbing route, we're not just building a graph — we're building a specific kind of graph: a path graph.

You could say that climbing is about traversing an abstract graph and turning it into a concrete one — from its root to its head.

Finally, you’ve probably noticed that the graphs discussed in this post are sparse, with few nodes and few edges. Next time, we’ll go to extremes and strip away all the edges 😱 We’ll explore point clouds and how to generate them using Structure from Motion.

From there, I dive into computational methods for analyzing these structures — how we model them, extract meaning, and sometimes even use them to build augmented reality experiences. You'll find posts on everything from Structure from Motion, LIDAR mapping, and GNSS tracking, to visual attention modeling and the way our eyes and minds respond to the environments we move through.

While much of this blog is grounded in geospatial systems (yes, feet on the ground — pun intended), I’ll occasionally take you beyond that scope to explore more abstract structures: airways in the sky, climbing routes, even family trees.

Whether it’s visible or abstract, if it has structure, it has a story - and I’ll try to tell it.

How this blog works

I aim to publish a new post every 2–3 Tuesdays — sometimes a deeper conceptual piece, sometimes a more hands-on follow-up where you can explore things yourself in Python or using open data.

Posts are grouped into themes such as:

• Graphs & Graph Neural Networks (GNNs)

• 3D Reconstruction

• GNSS & Positioning

• Climbing

• Visual Attention & Perception

• Graphs × GenAI

You'll see these tags on posts to help you navigate across topics or follow the threads that interest you most.

👉Curious? Start with How to Solve the House Puzzle

---

Thanks for being here. If you’d like to follow along, subscribe or check back every few Tuesdays. I hope you’ll find ideas here that feel both familiar and a little unexpected.

Depending on which dot you choose as your starting point — you’ll either succeed or fail. But why?

What we’re doing here is traversing a graph. This is our house graph:

A graph is a structure made of nodes (also called vertices) and links (or edges), with each link connecting a pair of nodes. In this case, we have five nodes: A, B, C, D, and E, and 8 edges: A-B, A-D, A-E, B-C, B-D, B-E, C-D, D-E.

What’s more, the house graph is an undirected graph, meaning you can traverse each link in either direction — from A to B or B to A.

Now, back to the question: why does starting from node A let you draw the house in one go, but starting from B doesn’t?

To answer this, we need to look at something called node degree — the number of links connected to each node in an undirected graph.

Back in 1735, Leonhard Euler showed that in order to traverse such a graph in a single go — without retracing steps — you must start at a node with an odd degree and end at another node with an odd degree. All other nodes must have an even degree. He actually proved it here.

Since there are exactly two nodes with an odd degree (A and E) and all other nodes (B, C, and D) have even degrees:

• There is an Eulerian path in the house graph, meaning it is possible to draw all edges in one go.

• You must either start drawing from A and end at E, or start at E and end at A.

Check your knowledge: Bridges of Königsberg

To test your understanding, try this rule on the famous Bridges of Königsberg. This is the problem that led Euler to formulate the rule in the first place. His question:

\> Can you walk through the city, crossing each bridge exactly once?

When we translate the city into a graph, pieces of land become nodes and bridges become edges, like so:

Let me know in the comments what the node degrees are, and whether you found the solution to Euler’s question!

Summary

That was the shortest intro to graphs I could come up with :)

We've touched on:

• Nodes (vertices)

• Edges (links)

• Undirected graphs, where movement is allowed in both directions

• Node degree, and how it affects traversal

• Euler’s recipe for drawing a graph in a single stroke — the Eulerian path.