Module 3. From Tables to Graphs: Ways of Representing Knowledge

Course 3. Modeling Meaning: How We Structure Humanities Data
Estimated Time: 30–35 minutes

🧭 Module Objectives

Describe the major data modeling paradigms: hierarchical, relational, and graph-based.
Compare how each structure represents entities and relationships.
Explain the advantages and limitations of each for humanities data.
Recognize why graphs have become a preferred model for representing complex cultural knowledge.
Relate these approaches to the evolution of our own Wellespring model.

Many Ways to Model the World

There is no single way to represent information. Different systems arise from different needs: efficiency, flexibility, or interpretive depth.

Humanists often encounter these three core paradigms:

Model Type	Origin	Typical Structure	Strength	Limitation
Hierarchical	1950s–60s file systems	Parent–child tree	Clear order, fast retrieval	Rigid, hard to cross-link
Relational	1970s–80s (SQL databases)	Tables joined by keys	Precise, standardized	Requires predefined schema
Graph	2000s–present	Nodes + edges	Flexible, captures context	Can be complex to design

Each is a language for expressing relationships, but each tells a different kind of story about the world.

The Hierarchical Model: The Tree

Think of a hierarchical model like a family tree or a directory of folders on your computer. Each "parent" can have multiple "children," but each child has only one parent (which doesn't fit biological reality in family-tree scenarios).

Example (Simplified Museum Archive)

Museum
├── Collection
│ ├── Artifact
│ └── Artifact
└── Staff
| ├── Curator
| └── Conservator

This approach works beautifully for data with inherent order or nesting: genealogies, taxonomies, or archival hierarchies.

But: it struggles with complexity. If an artifact belongs to two collections or connects to multiple exhibitions, the tree starts to break down. Cross-links become hard to maintain and the branches tangle.

The Relational Model: The Table

The relational model, popularized by IBM's Edgar Codd in the 1970s, organizes data into tables. Each row is a record, each column is an attribute, and tables connect via shared keys.

Example (Songs and Artists)

Table: Person

person_id	name	role
1	Jesse Welles	Singer-songwriter
2	Dave Cobb	Producer

Table: Song

song_id	title	release_date	person_id
1	War Isn't Murder	2024-04-18	1
2	Horses	2025-03-01	1
3	United Health	2024-12-12	1

The foreign key (person_id) connects songs to their creator, enabling efficient queries: "Show all songs created by Jesse Welles (person_id = 1)."

Relational databases (like the popular open-source MySQL and PostgreSQL) are powerful and standardized. But they enforce a fixed schema: the structure must be predefined, and every record must fit neatly into the same table. That rigidity can limit us when modeling fluid, ambiguous, and evolving human relationships.

The Graph Model

Graphs break free of those rigid structures. They are networks made up of nodes (entities) and edges (relationships). Each node and edge can hold its own attributes.

Example (Wellespring Fragment):

(Person {name: "Jesse Welles"})
      —[:WROTE_SONG]—> (Song {title: "War Isn't Murder"})
      —[:RELEASED_ON]—> (Album {title: "Hells Welles"})
      —[:EXPRESSES]—> (Theme {name: "war is murder"})

This graph can easily expand:

Add new people (e.g., "Producer," "Collaborator").
Link songs to performances, reactions, or audiences.
Create new relationships (INSPIRED_BY, REFERS_TO, CRITICIZED_BY).

No schema rewrite is required for these additions, just more connections.

Graphs mirror the way humanists think: through networks, associations, and meaning. They don't flatten experience into rows; they let ideas breathe and connect.

Comparing the Paradigms

Feature	Hierarchical	Relational	Graph
Structure	Tree	Tables	Network
Typical Use	File systems, archives	Business data, inventories	Social networks, knowledge graphs
Relationships	One parent only	Defined by joins	Multiple, direct edges
Schema Flexibility	Low	Moderate	High
Best For	Ordered or nested data	Consistent, transactional data	Complex, interconnected data
Example	Library catalog	Payroll system	Wellespring Project

Why Graphs Suit the Humanities

Humanities data rarely behave neatly. People have multiple roles. Events connect across time and space. Ideas spread, evolve, and contradict themselves.

Graphs allow us to:

Represent multiple perspectives simultaneously.
Trace influence, dialogue, and citation networks.
Preserve context instead of flattening it into categories.

They are ideal for modeling complexity, not by simplifying it, but by mapping it transparently.

Example:

"Which of Jesse Welles' songs about war connect to historical events, public reactions, or performances at Farm Aid?"

This query touches songs, themes, events, and audiences: precisely the kind of cross-domain question graphs excel at.

Graph Thinking Beyond Databases

Even before you use a tool like Neo4j, you can start thinking graphically about any aspect of your daily life (your bedroom or kitchen, office or campus, readings or topics studied in other courses, items in your wardrobe, your grocery store shopping cart, music or video game collection, etc.):

What are the nodes (things)?
What are the edges (connections)?
Which paths (nodes connected through a series of edges) reveal interesting meaning?

This mindset emphasizes relational thinking: an essential habit for digital humanists. We move from isolated facts to connected contexts, seeing how meaning emerges through relationships. You may already be familiar with the practice of "mind-mapping," which is a popular form of graph thinking that can be done electronically with software or hand-drawn on whiteboards or napkins.

Key Takeaways

Different modeling paradigms structure knowledge in different ways.
Hierarchical = order and containment.
Relational = consistency and control.
Graph = flexibility and connection.
Graphs best match the interconnected, interpretive nature of humanities inquiry.

Course 3. Modeling Meaning: How we structure humanities data