Letʼs get the terminology out of the way
The first step in understanding anything is to learn the basic terminology of the subject. Ideally, everyone would be always using the same terms. Emerging and abstract disciplines, such as content modeling, often have a terminology problem. Terminology might only be an afterthought. There are several reasons for that, for example, misuse of certain terms for marketing purposes, a bias towards a specific word, or maybe simply the fact everyone is approaching the subject differently. Nevertheless, in order to tackle content modeling challenges, we’ll have to agree on some basic terms.
Content modeling
The first term is content modeling, which structures your content into highly reusable pieces and adds relationships and meaningful metadata. Creating a content model is a collaborative effort, and the best results are achieved if all stakeholders are involved.
Content model
The result of the content modeling effort is a content model. The content model is a blueprint and a set of (usually enforced) rules on how your company will work with content throughout the whole organization or in a given project. It’s important to note that the content model, if carefully crafted, is future-proof and not dependent on more volatile aspects of the project, such as the actual content, the implemented front end, or its navigation.
If you want to dive deeper into this topic, you should know that a content model consists of several constructs. This is where most of the terminology disagreements happen.
Content types and items
Content types are your blueprints for creating different kinds of content items. For example, they can create an Article, Blog post, or even a Mattress product. Some systems will call these blueprints page types (they don’t have to be pages), entities, collections, data types, classes, or modules, to name a few. The name content type best reflects the purpose of this construct as everything created based on it is content, and all instances will be of the same type. Thus, content type. Creating instances based on content types results in producing content items.
It’s important to address the flexibility of content types right here. The Mattress example mentioned is, in most cases, already a composite of multiple content types. The article could contain a call to action (CTA), which by itself can be a content type. We will address how far you should go when it comes to the granularity of your model in a separate article.
Content type elements
Dissecting content types brings us to a lower level where weʼll discover their actual structure. Content types consist of a set of sub-objects for which we’ll use the term elements. These can also be called fields, properties, attributes, inputs, or similar. The term element showcases the flexibility over some of the other naming conventions and highlights the fact that these are the smallest building pieces belonging to an overarching structure, the content type. So, for example, when talking about a Mattress, there would probably be Name, Description, or Price elements. These elements usually come in different types, such as Text, Number, or Date and time.
Building relationships between items
One of the most important aspects of a content model, if not the single most important one, is the links you establish between different content items. These links form relationships of different kinds. Links between items are dictated by how your content types are set up as most systems allow for some kind of linked item element type.
Linking with metadata
Linking items explicitly is one of the ways of forming relationships. Another way, and even more useful one, is utilizing meaningful metadata, which is any information helping you to form invisible (semantic) relationships in-between content and between content and readers. Metadata can include taxonomies, personas, audiences, or stages of the buyerʼs journey. Metadata attached to content gives it the needed context for which the content was crafted. You’ll use different tools to add metadata to your content model depending on what is available and what you want to achieve. In short, metadata can be added as an element, a content type, or a separate taxonomy object if available.
Assembly and chunks
Other common terms used when talking about content modeling are the assembly model, content chunking, and content chunks. These are usually universally agreed upon, so they won’t need too much explanation. The assembly model is the process of how the content is pieced together from different content items. This can be done manually, by content editors, or even automatically by the actual front end. Content chunks are the smallest reusable pieces within the whole content model, and the process of modeling those is called chunking. Chunking sometimes means grouping elements into a content type (chunking up), but usually, it means breaking content types down (chunking down) into more reusable pieces. We’ll always use it in the latter definition.
Supporting tools
These are the essential constructs you’ll need for most content models. Some systems come with supporting tools to aid your content modeling efforts, such as content type snippets used for a repeating set of fields that can be repeated on multiple content types (e.g., SEO elements), or custom elements that can simplify and enhance your content model significantly (e.g., a custom element allowing you to select assets from your existing DAM), so it’s recommended to get yourself familiar with your CMS of choice.
For now, these are the essential terms you need to understand the basics.
To sum up:
- The content model is a blueprint for all your content. It includes also how the content is orchestrated, or assembled.
- Content items can represent anything that makes sense for your business.
- An important aspect of your model are the relationships between items.
- Chunks are the smallest reusable content pieces.
Subscribe for updates
Stay in the loop.
