The Tortured Metaphor of Spatial Content Relativity

It’s funny when developers say something like, “I’m gonna write that out to a physical file.”

A physical file? Really? Of course, the developer means they’re going to write it to disk. They say “physical” to mean “persistent” or “non-ephemeral” or “not in volatile memory,” but I still find it funny. We relate virtual things to physical concepts to make them easier to understand.

We do this with content all the time. We talk about content as if it exists in the real world – like content objects are actual…things, floating in space or something. This usually manifests itself by evaluating content objects as if they have some actual physical relationship to each other.

We say content is above, below, or beside other content. We usually get familial about it: we talk of parents, children, siblings, ancestors, and descendants. When we do this, we’re envisioning an org chart or a graphical description of a family tree, so we’re really talking spatially, even if it comes out like we’re discussing a family. We use the idea of family and genealogy as a proxy for space.

Unfortunately, this metaphor can get tortured. We sometimes try to bend and twist it to make sense in all cases. In the end, we’re trying to impose physical rules on something which isn’t actually a physical concept. In fact, let’s talk about one such abuse: when we try to impose a single structure on all content and pretend that it works in all cases.

I’m a big fan of organizing content into larger structures. In my book, I call this “content aggregation.” In the past, I’ve called it “content assembly” (I changed my mind on the term), and I’ve been an unabashed fan of content trees and subcontent. I believe the organization of content into hierarchical structures is natural for humans – it matches the way we mentally organize content and navigate through information spaces.

This way of discussing content is relative. Something can only “on the right” because something else is to the left of it. And something is only a child because it has a parent. When we do this, we’re talking about content objects in relation to another content object. The assumed precept is that both of those content objects have to exist in the same, larger structure.

This brings us to a critical point: talking about anything in spatial terms requires two points of reference:

1. The specific thing

2. The containing space

South Dakota is roughly in the upper middle of the United States. This statement only makes sense because we’re talking about (1) a specific state, and (2) the United States as a whole. We have both a point of reference (South Dakota), and a larger space (the United States) in which to place it. You can’t be in the “upper middle” of nothing, and you can’t say something is in the “upper middle” of a thing unless you specify the thing.

Where am I going with this?

Lately, I’ve been wondering about the implicit or explicit nature of content structures and “spaces” like trees, menus, collections, categories, etc. Does the content inside a space like that know that it’s in the space? Does it internally know the position it occupies in that space? When we ask it questions about the content “around” it, to what space has it oriented itself before it answers? To the only space it knows? Can it know about its position in more than one space?

Rugby, North Dakota is far north in the United States – only about 45 miles from the Canadian border, in fact. But it happens to be the Geographic Center of North America. So, if we were to ask Rugby how far north it is, the proper answer would be, “In relation to what?” Rugby knows that we want to know something about its location, but it doesn’t know the boundary for which we want that answer related.

So, again, we need (1) the thing, and (2) the space. A specific piece of content clearly has one of them – the point of reference is itself (if we ask a content object for its children, then clearly it knows that we’re asking for its children, rather than some other object’s children). But what’s the second thing – the space in which the idea of “children” is manifested? Does our content object know about that?

To understand this better, let’s consider the case of a CMS with an over-arching hierarchical organization method – a core content tree. This is very common in web content management. Episerver, Sitecore, eZ Publish, and dozens of other CMSs exhibit this pattern. Content is organized into a single, all-encompassing tree. Everything exists somewhere in this tree.

In the past, I’ve called the idea of a single, authoritative content space a “content geography” (there’s that physical space metaphor again) in the sense that it’s the agreed-upon map that we all rely on to place content relative to other content.

In these cases, there is a main “space” that the system is based around – the tree. All the entities in these systems agree that the tree is the core space in which to orient themselves. Because of this, a content object can be assumed to know about its position in that space. And if all content knows this, then content can reason about its position relative to other content. If I know that I’m in South Dakota and you’re in California, and we both know our relative positions in the United States, then I can extrapolate that you’re to the west of me (and you pay way too much for rent, but that’s an editorial comment).

And, indeed, in most cases, we can ask a content object for information about itself relative to other content. How many children do you have? Who is your parent? What are all your descendants? What is your ancestral chain back to the root of the tree? It only knows this because it knows we’re talking about its position in the tree because the tree is assumed to be the space we’re talking about. It has both pieces of the puzzle. It is its own point of reference, and the tree is its space. Thus, it’s quite simple for the object to produce its children.

But let’s complicate this. What if we have two trees? And what if Content Object X exists somewhere in both of them?

Me: “Who is your grandfather?”

Content: “Well, that would depend on which side of the family you’re talking about…”

Consider: I am the grandson of both Walter Barker and Laurence Middleton. If you ask me who my grandfather is, I’ll have to ask what side of the family you’re talking about. I exist in two different familial spaces. While I know the point of reference (me), I do not know the space – it could be one of two. (And, no, that’s not really my mother’s maiden name, so relax.)

Many CMSs have multiple ways of structuring content. If a system doesn’t have a tree (or even if it does), there are often ancillary structures;

• In Drupal, there are “menus.” Menus are a discrete, conceptual thing. You create, edit, and delete menus. And you add content to them. Content can be in more than one menu, and it can occupy different places in different menus. Thus, if you ask a Drupal object for its children, it’s going to respond, “…in the context of which menu?”

• In Ektron, there are “collections.” These are serial, ordered lists of content. Like Drupal menus, content can exist in more than one, thus a single piece of content had more than one “circle of friends.” To get other content in a collection, you first have to ask which collection we’re discussing.

So, while I’ve pushed hard for over-arching content trees before, I’m beginning to wonder if this enthusiasm may have been misguided. I wanted a tree because I wanted to be able to evaluate spatial content, and I was stuck in the rut of thinking there had to be a single, over-arching space (the core tree of a tree-based CMS). Really, there can be multiple spaces.

This is relevant because a single tree can be a problem sometimes. In my book, I talk about the “tyranny of the tree.” When settings or functionality is based on the tree, and there’s only one tree, you can get forced into things you might not want. You might organize your content into a tree in a way that makes sense for editors. However, if your URLs are formed from an object’s position in the tree (which is very common), and you want your URLs to be formed differently than your editor-friendly tree…well, you have a problem. Remember, you only have the one tree, and can sometimes be tyrannical.

What if you could have two trees? One to show to editors to assist them in finding content, and one with which to form URLs? (And any CMS that lets you free-form its URL sort of does this. Setting the path to something like /articles/politics/2015/crisis-in-china is actually exactly like placing something in a tree – it’s just been serialized to a string.)

Beyond two trees, what if you could have an infinite number of trees? What if we had a multiverse of content trees, which we could switch between at will? One to show editors, one for URLs, one for the main navigation, one for the footer navigation, one for the taxonomy, etc.

And it’s not just trees. Consider the idea of “Next” and “Previous” links on a blog. Those are relative terms. Comparing them to physical space, we think of people standing in a line – one person is in front of us, one person is behind. On a blog this makes sense because blogs are invariably ordered by reverse chronological date, and that’s the space. So relative navigation through that space means that next/previous makes sense. We assume that “space.”

But what if you’re looking at a list of posts in a category? You see this list, and you click into a post, and then next/previous suddenly doesn’t make sense anymore because it’s operating on a different space than you are (which is why sometimes they’re actually labeled “older” and “newer,” to be more clear – to clarify the space to which they relate). In reality, the concepts of “next” and “previous” are only accurate in relation to the last space you perceived. And if there’s more than one space, then every user could perceive a different one. We keep jumping in and out of different lines so the people front of and behind us keep changing.

So, does our content exist in a universe, or a multiverse?

The etymology here is actually fun. “Universe” comes from:

• “uni”: one

• “versus”: turned

In a universe, everything is turned into one thing. In a multiverse, everything is turned into multiple things.

Indeed, in physics (or maybe philosophy?), the concept of the “multiverse” posits that:

The multiverse is the hypothetical set of finite and infinite possible universes, including the universe in which we live […] The various universes within the multiverse are called “parallel universes”, “other universes” or “alternate universes.”

Thus, if we call our content “multiversal,” then our content can live in multiple universes (spaces) at once.

And this brings me to a critical point: when getting spatial information about a content object, we can pose our question to one of two things:

1. The content object itself

2. The space in which it exists

Traditionally, I’ve worked with CMSs where you did the former. You asked the content object, and it gave you an answer based on the one space that is baked into it – the tree.

The problem is that from the content object’s perspective, it only exists in one space.

Hey, Content Object #123. What are your children?

In this case, the space is implied and the content object answers in the only way it can – from the universal perspective.

I’m beginning to wonder, however, if we should be asking the space instead. Or, rather, whatever space we wanted an answer from in that moment:

Hey, Main Menu. What are the children of Content Object #123?

Hey, English Department Submenu. What are the children of Content Object #123?

Hey, URL Manager. What are the children of Content Object #123?

Each space would answer in the context of itself, and Content Object #123 might have a different relative position in each space. We can evaluate the object from the perspective of multiple spaces, or at least the space which we care about at the moment, for whatever we’re trying to accomplish.

Now, clearly, there’s some impracticality here. Editors aren’t going to place content…

• …in one tree for editorial organization

• …in another tree for URL formation

• …in another tree for Navigation Menu A

• …in another tree for Navigation Menu B

Additionally, editors probably want to create content spatially. It’s likely that they envision content as a “child” or other content in a purely logical sense, regardless of what being a “child” means in practical, interpretive terms.

This means there should probably be one “core” tree into which content is placed by default. Which means we’re back to a universal tree

But what if there were others? What if we could have a universally-structured system which allowed alternate structures as necessary? So, we could just create random trees for whatever reason, then ask those trees questions (as noted above)? We’d essentially have a multiversally-structured system. The structure would re-arrange itself based on what context we’re in. Are looking at a URL structure? An administrative structure? A navigation structure?

So, what if we had a universal tree with multiple secondary trees. As if to say, for most things, this is the tree/space to which content is oriented. But other needs and contexts can have their own tree/spaces.

In the end, this blog post might be subtitled “How I Feel Out of Love with the Content Tree,” but that’s a step too far. Rather, there are a number of…refinements, in my thought process around relational content structure that writing this post has delivered:

• We tend to think of content as “a thing which exists in a space,” which is a paradigm we might have inherited from physical space itself. But it’s limiting to think in terms of a single over-arching structure in all cases. While a core structure (a “geography”) is comforting and orienting to editors, it can be tyrannical and limiting in practice.

• Different structures can exist for different reasons, sometimes without us realizing it (e.g. – a string path). Content relates to other content in different ways depending on the context.

• In explicitly menued systems, menus might be these structures. I’ve been critical of explicit menuing in the past, but did Drupal get it right after all?

• From an API perspective, perhaps we should be asking relativity questions to the space, not the object. If the object can exist in multiple spaces, then it only ever has one piece of the puzzle – one of the two things it needs to know, as discussed above. Whereas the space knows both things: (1) it knows about itself and locations of content within itself, and (2) it knows about the object we’re asking questions about.

Content relativity is natural when dealing with content in aggregate, but there’s a danger of imposing the limitations of the physical work onto content relationships which really don’t have a physical corollary. Content objects are not physical, and they’re not bound by conventional physics. We torture a metaphor sometimes when we try to force fit that paradigm, and user and editorial confusion can result from it.