To what extent do our natural biases leek into the models (data structures, algorithms) we use. E.g is it possible that a tree data structure is more appealing to both users and developers because it mirrors a hierarchy (everything has a parent/cause) vs a graph which has a loop (which came first the chicken or the egg) which is considered less intuitive. It seems a relevant design choice to consider not only the universal truthiness of something but also the cognitive load it takes to use it.

For me it usually comes down to cognitive load. If I can get away with a vector I’ll use one, then a map, then a tree, then a graph.... I also believe in iterating towards a goal in an agile fashion and not over engineering a solution. But yeah, I don’t lightly use a tree or a graph, because complexity == time

I suspect that material biases wrt existing libraries matter a lot more—I’d prefer a graph for most of my applications, but it’s much easier to write hierarchies. Since relational databases depend on slow joins to emulate graph queries, we don’t see a lot of many-linked relationships on apps and pages—which I think limits peoples’ imaginations (part of why Roam is taking off IMO)

This is where it would be good to get takes from psychology, anthropology, and sociology. Hierarchies make sense to people for a lot of reasons, and some of these are deeply cultural (think: organization of societies). On the other hand, people are generally (though we all know some exceptions) good with spaces. Perhaps what in CS is called a "graph" structure is better though of as a "map" or "the layout of rooms in a giant house" -- it's very easy for us to understand in such a case how you can leave a room but somehow take a path that leads back to that room over and over, etc

with the semantic web i’d say a combination of economic factors (eg, google’s dominance, lack of a business model) and ux factors (never saw a really appealing end-user app for creating or browsing rdf data). unfortunately i’m at the “read the wikipedia five years ago” level of understanding of OODBs so i can’t contribute much on that front—but i’d also note that path dependence is really, really hard to overcome especially for foundations of applications like databases

I see what you mean.

Trees are appealing in some cases because nesting and containment are something we understand metaphorically/cognitively via 'spaces' and they also gives a nice coordinate system for 'naming via location' for each node. E.g.

earth < solar system < galaxy < alpha quadrant

and

second < minute < hour < day

. Graphs are appealing when we think of peers and relationships (the set of buildings in a city). You can have arbitrary relationships but you don't get the canonical path to each node. I don't think one is always more intuitive. IMO the bigger problem is our biases in 'meta models'. We have the idea of what a "data structure" is, we pick exactly one and get 'locked in' permanently to that one view. We may want multiple parallel views of the information based on what we're tying to do. But none of the usual models or type systems do this well. If you look at programming, a lot of it is 'changing the shape' without adding any new information. E.g. transform a JSON object into a struct; load an array of structs into a dict for faster lookup, extract one field of many structs into an array etc. There's conflation between data structure and information structure and we haven't figured out how to separate these nicely.

I think that is a good explanation

Yes I think the appeal of 'graphs' as a universal structure is that in the high level 'informational space', we think our minds organize it as graphs. This is where RDF etc come in. I too am surprised we don't have mainstream programing languages that deal directly with RDF like information structures (only graphs and various views of them), instead we get low level data structures (arrays, dicts, lists, structs). This is the idea of separating design from optimization (picking a data structure involves both and implies conflation). I want to be able to design the information structure separately from the implementation and optimization views.

I'm spitballing the following without real evidence, though I'm imagining research might back it up:

Re metaphors, I found Lakoff's "Metaphors We Live By" very interesting. The idea that we understand via 'metaphor'.

People a fundamentally good at dealing with complex relationships between things, be that institutions, or even and especially personal relations (families, friends, friends of friends, etc)

Re ambiguity yes it seems the software we build is way too strict.

There is a book by the anthropologst Lucy Suchman called "Human Machine Reconfigurations" that might be good on some of this

@Eric Gade

One issue here is that being “computer people” in 2020 we have kind of already poisoned our thinking. I’m wondering how a regular, non-programmer would organize information with only the barest of tools. Would some spatial/relationship based thing come out of it?

If you know anyone in high school or college who isn’t studying CS, try looking at their personal notebooks or journals. I think people often store information in narrative form. The narrative gives many contact points with the same piece of information. A particularly adept learner might write about what they learned in many ways: how it applies to their life, where they have seen it in the world, the strict technical definitions, and some metaphors that capture the essence of the subject. We want to look at the same information in as many ways as possible so we can get an intuitive sense for it. Something that we understand deeply can represent itself as a felt-sense in the body, as opposed to an intellectual thought, like a grandmaster chess player analyzing his position on the board, or a tennis player analyzing the trajectory of a ball.

In addition to the very good Lakoff recommendation above, I'd add the work that Hofstadter and Melanie Mitchell have done around analogies as the basic unit of understanding.

@Jack Rusher That's brilliant.

Often a graph has a spanning tree that represents a reasonable way to get around. And in case the tree isn't not quite right, you can often split a node so that it appears a few times in the tree.