Is Content Geography Just Another Property?

When it comes to content geography, I love content trees. I’ve never made a secret of this. I’ve long-thought they’re the most intuitive way to model a content domain.

But I’ve been wondering lately, in what senses does geography differ from a “normal” property you might model on a content type? A content item’s location in a larger structure describes it in some way, just like other properties do. So how is creating content as a child/parent/sibling of other content any different from setting some direct property on that content? Are we doing something special by modeling content this way?

After tossing this around for some time, I’m going to claim that the difference is subtle, but significant.

First, geography is a relational aspect of content, in that it defines a piece of content in relation to other content. As I noted above, you’re making content a parent/child/sibling of other content, and this means something unique. There is a spatial relationship there, so specifying the “location” of content gives it definition in relation to content that already exists, and content that may be created in the future.

Second, geography can be extrapolated hierarchically, in that being a child of Content Z makes you a grandchild of Content Y and perhaps a great-grandchild of Content X. Your existence in that location can be extrapolated into existence in other locations. (Much like real geography: if I’m in Sioux Falls, then I’m also in South Dakota, and I’m also in the United States, and I’m also in North America, and I’m also on Planet Earth. The relationship between me and my location “rolls up.”)

Third, geography is a matter of ownership, not assignment. If I create Content X as a child of Content Y, then it can be said that Content Y owns Content X, and Content X lives and dies in the same logical space. If Content Y moves, then Content X goes with it. If Content Y gets deleted, then Content X does too. In that way, this way of describing content deeply influences its content lifecycle.

Fourth, ownership implies exclusivity – I only have one father. Likewise, content can only have one parent. In establishing this, you’re creating an indisputable bond between two pieces of content, which is exclusive in one direction (I have one father, but my father has two children), and that’s a very specific method of description. This relationship defines ownership/parentage, which can have a big impact on the lifecycle and disposition of the child content.

(Yes, many systems will allow more than one tree assignment – so you can have Content X appear as a child of Content Y and Z, for instance – but one relationship is usually considered the “main” relationship. If the system doesn’t allow this, then I don’t think it really qualifies as a content tree. In some cases, a system might have multiple trees, but each tree would need to have some exclusivity of parent/child relationship, so that tree can be considered “true” unto itself.)

Let’s step back for a second and look at a common taxonomy system, like Drupal’s. In systems like that, you have a parent/child structure of categories, and you assign content to them. So, it’s similar in the sense that you’re structuring content into some type of tree, but it’s…different. What if we used this to try and indicate a spatial relationship of content?

• You’re not assigning content to other content. Rather, you’re assigning it to a taxonomy node. (Is a taxonomy node content in and of itself? It depends…)

• You’re not creating direct parent/child relationships between content. If Content X is assigned to Node Y, it’s not logically a child of all the content assigned to Node Z.

(To be fair, I don’t know many Drupal-istas would claim that the taxonomy rises to the level of a content tree, but it’s handy as an example.)

What about if we created a “location” dropdown in the content type itself and used this to create some kind of relationship?

• If it’s a flat list of “locations,” then we’re not defining parentage, we’re really just defining sibling-ness. Everything assigned to one location could be considered a logical sibling, or grouping, of content, but that’s awfully amorphous.

• There would likely be no indication of ordinality withing the group. The concept of parentage often implies some ordinality.

• Since the assignment is from inside the type outwards, you run into the usability problem of now showing the aggregate items assigned to a location. If you allowed a view of the opposite – selecting the location, and showing the content assigned (so, outside-in) – then our perspective changes to one of implied parentage; the location would be viewed as a parent of the items within it.

I was an unabashed content tree evangelist for years. Slowly, I tried to pry myself away from it, thinking that perhaps it was a rut I had fallen into and I was being myopic about it. But I’ve now turned around again and I’m embracing the construct. No matter how you slice it, the spatial relationship of content to other content – its content geography – is a significant and fundamental aspect of modeling.