At first, I thought in pages
A normal website is organised around pages, so that was how I first imagined Culture Atlas too.
There would be a page for a place, a page for a language, a page for a tradition, a page for a person. Each page would contain text, images and links to other pages.
That works for reading. But when I started thinking about the connections I wanted Culture Atlas to make, I realised the information underneath those pages needed a different structure.
A language is not really a page. It is a thing the system knows about. So is a place. So is a community, a tradition, a person, a story and a source.
The page is only one way of showing that thing to a visitor.
Then come the relationships
Once I separated the “thing” from the page, the next part became clearer.
A language can be spoken in a place. A tradition can be practised by a community. A story can be told in a language. A person can be connected to a tradition. A source can support information about any of them.
So instead of thinking only about pages, I started thinking about entities and relationships.
I learned that a system like this can be described as a graph. The entities are often called nodes, and the relationships are the edges between them.
I do not need a visitor to know any of those words. But I need the structure behind the product to understand them.
A way of storing things and the meaningful connections between them. I picture the things as dots and the relationships as labelled lines.
A simple example becomes complicated quickly
Imagine I add one tradition.
I need its name and a description. Then I might need to connect it to one or more places, one or more communities, a language, people associated with it, stories about it, images or recordings, and sources that support the information.
Now imagine that one of those places has its own languages, people, traditions, stories and sources. Each connection creates more possible paths.
That is exciting because it is exactly what I want exploration to feel like.
It is also dangerous because the structure can become complicated very quickly.
The graph cannot mean “connect everything to everything”
One of the easiest mistakes would be to assume that a richer Atlas simply needs more relationships.
I do not think that is true.
If every record has dozens of vague links, the graph becomes noisy. The visitor sees a lot of options without understanding why any of them matter. The database also becomes harder to maintain because nobody knows what a connection is supposed to mean.
So I am trying to start with a smaller vocabulary of relationships that I can understand and explain.
For example, “spoken in,” “practised by,” “located in,” “associated with,” and “supported by” are different ideas. Some are much more precise than others. I need to be careful about when each one is appropriate.
The direction of a relationship matters too
If the Atlas stores “Tradition A is practised by Community B,” the visitor looking at Community B should also be able to discover Tradition A.
That sounds obvious on screen. Underneath the screen, it means I need to think about whether relationships work in one direction, both directions, or differently depending on the type.
This is the kind of problem I did not see when Culture Atlas was only an idea for an interactive map.
Sources belong in the graph as well
I also do not want sources to sit in a bibliography that has no connection to the claims they support.
If a source helped establish information about a record or a relationship, I want the system to be able to preserve that connection.
Eventually, that could make it possible for a visitor to move from “What does the Atlas say?” to “Why does the Atlas say this?” without leaving the structure of the product.
I am not claiming I have solved that yet. But designing the graph without sources would make it much harder to add them properly later.
What should become a node?
This is one of the questions I am still working through.
If I turn every noun into its own entity, the database becomes huge and confusing. If I turn too few things into entities, important relationships disappear inside paragraphs of text.
My current test is whether something needs its own identity and connections. A place clearly does. A language does. A person does. A source does. But there will be many harder cases, and I expect the model to change as I work with real records.
I think that is healthier than pretending I can design the perfect cultural data model before I have tested it.
The graph is a model, not culture itself
There is another problem with dots and lines: they can make culture look neater than it really is.
A database needs categories. Real life does not always respect them. Something I call a tradition might also be a performance, a community practice, a form of knowledge or all of those at once. So the graph is my way of organising evidence; it is not proof that culture itself fits perfectly into my boxes.
A model is useful because it leaves things out
A graph reminds me of a mathematical model: it keeps the parts that help answer a question and leaves other detail outside the model. That can be useful, but I should never confuse the model with reality. English adds another test—can I turn the line into a clear sentence? I&S adds one more—does the sentence still make sense when I consider time, place and different perspectives?
The model is useful because it is incomplete
I thought the main technical challenge would be drawing an interactive map.
Now I think one of the hardest parts is deciding what Culture Atlas needs to know underneath the map.
The interface can be redesigned later. A confused information structure is much harder to repair once thousands of records depend on it.
What I'm figuring out next
The graph creates another problem: geography.
If I make states the main containers for cultural records, I make the system easy to navigate—but I can also accidentally suggest that culture follows administrative boundaries.
My next question is how to use India's map without letting the map oversimplify India.