What Is and Isn't Considered "Content"?

We need to take a brief detour here and talk about what is and isn’t considered “content,” in a particular CMS. And this isn’t a meta-philosophical discussion about the nature of content, but rather it’s a practical acknowledgment that not every piece of data managed by a CMS is the same. Some are more content-ish than others.

Consider the Article we’ve used for examples. If I’m a publishing company, then my articles are most of the reason I’m managing content in the first place. They’re not incidental to my content model – they are my content model. My entire business is built around managing articles.

Therefore, we can say confidently that articles are “full” content.

What about, say, the categories I use to organize my articles? Are the categories “full” content? They have a name, and they’re organized into a tree, but are they content like an article is content?

Maybe not. Depending on the system, categories might just be some data structure managed from the interface.

But, wait, isn’t everything in a CMS “some data structure managed from the interface”? Well, yes, but some of them get more services than others.

Let’s consider all the services a CMS provides to content objects:

• Full modeling capability, with attributes and custom validation and everything else we’ve talked about so far
• Versioning, so we can maintain a history of changes and can rollback to a prior version
• Granular permissions assignment, so we can control who can do what
• Some level of auditing or logging, so we have a record of everything that has happened to an object
• An editorial lifecycle, so that changes to the object are not always published directly, but can exist in a virtual workspace until ready
• An approval process, so that progression through the editorial lifecycle has to be approved by one or more people
• A event model, so that we can inject code operations at various points in the lifecycle
• An archiving model, where content can be deleted and removed from the UI, but retained in some form

And so on. Depending on the system, there might be a dozen different services provided around content. Fundamentally, this is what makes any particular CMS more than just a database – it “serves” and enhances content by providing extra functionality around it.

Our Article content object would certainly benefit from all of these services. But would a category? Does a category rise to the level where it can benefit from all these services?

In many systems, the answer is no – categories aren’t actual content, they’re just an organizing structure. They’re data, but not content like an article is content.

And when would a category cross that line? What if I wanted to model a category – provide a description and an image and some other data? Without some modeling capability (the first service described above), I don’t have that option for categories, and there might simply not be a way to do that at all. Even if I could, that expanded category is now very content-like, and I’d want more services – like preview, approvals, and versioning – to manage it.

However, in most systems, there is always some dichotomy between what’s full content and what isn’t. Where this line is drawn depends on the system. Often, not everything managed from the interface is content, and it’s important to understand what is and isn’t, because editors might find themselves depending on a content service that doesn’t exist (“I accidentally deleted the entire category tree… What do you mean there’s no recycle bin for categories?!”)

An example of evolution in this dichotomy is content files – images, video, etc. In early CMSs, these were not content. Usually, you just had an interface where you were managing files on the server’s file system, and they were directly available to be accessed.

There was no request interception or delivery context to speak of – in fact, when a content file was accessed, the CMS wasn’t even involved. When you uploaded a new file, you weren’t creating a content object – rather, you were literally just putting a file in a directory on the server. There were no extra services offered.

Slowly, this changed. More and more systems began to consider content files to be “full” content objects, with some or all of the services offered to other content. We could now model file objects, and have approval workflows for them, and have code that executed on an event model. This was a healthy progression.

Not everything has or will progress like content files. For almost every system, there are things that are just never going to be considered full content, and never going to benefit from the complete service model. A key part of editor training is to explain what is a full content object and what isn’t.