Content Modelling in— Part 1

Getting your model started with content types, structure, and relationships.

Michael Kinkaid
School of Content
Published in
6 min readNov 17, 2019


A doodle of a basic content model showing artist, album and song content types. is a fantastic Content as a Service (CaaS) platform. It’s a place to work on your content before you publish it to a channel (website, app, voice assistant — basically anything that can make use of the platform’s Delivery API).

To get started, the first thing you need to do is create a model that your content can be put into. The model represents the content and describes that content in terms of content types, structure, and relationships.

As an example, for a music streaming service, our model would have an artist (a type of content) where we could write the name, bio, and genre (the structure of the content); and each artist would have albums (a content relationship between an artist content type and an album content type).

Let’s explore these three things and build them out in You can sign-up for an account over at

Content Types

How do you tell which parts of your content should become content types? Content types are typically the nouns in your model. They’re the things in the topic your content is related to. In the case of our music streaming service, these would be things like an artist, an album, and potentially a song.

You can use the content model section of to start defining your content types.

The content modelling area of shows a list of content types for the music streaming service.
The content modelling area in allows editors to start building out their model by creating content types.

So why did I say “potentially a song”? Here’s the rub when it comes to content modelling: you’ll have to decide just how far you go with breaking the content up into distinct types. But how do you decide? Well, outside of the obvious (we’re going to need an album content type), you should consider the following:

Promote content reuse

The model should allow content to be reused. Editors shouldn’t be expected to enter the exact same content multiple times. This keeps our model flexible. If a song appears on an artist’s album and their ‘best of’ album, then with a separate song content type, the editor just has to create the song once and link it to both albums.

A doodle of a content model (kinda), that shows two albums that are linked to the same song.
‘Song’ is its own content type. In this way an editor can create a single song and relate it to multiple albums. ‘Tis the season for Christmas compilations… As long as you’re reading this in December. 😆

Take a ‘content first’ approach

Your content likely doesn’t exist in a vacuum. Whether it’s intended for a website, app, or something entirely different, you want to start designing and discussing the content requirements with your team or client at the very start of the project.

Brainstorming the purpose of your content and how that content will be presented will help firm up the overall requirements for your content model. These content requirements should inform things like design and development more so than the other way round. For example, maybe we don’t need a separate song content type if all we ever do is list the song names. In that case they can be added to a text field directly in the album content type.

Doodle of an album content type showing fields editors can add content in. One is a “track” field with song names listed.
Imagine an app that just shows the names of album tracks and that’s all. Creating a separate song content type is overkill if there’s nothing in the roadmap to suggest we’ll be adding more types of content to a song.

Balance content flexibility with the effort to create it

Typically, the more flexible the model is, the more abstract it gets, and the more steps it may take editors to put the content together. Because of this, you have to balance flexibility with the work effort to actually author the content in the first place. You might look lovingly at a music service content model with 30 flexible content types, but if an editor has to enter content into half of these just to make a single album, then you’re going to get tapped on the shoulder.

Doodle shows a complex model with many content types and a lot or relationships.
Modelling for content that isn’t going to be used to the extent your design implies is likely going to lead to a lot more work for content editors.


Once you’ve identified a content type you’ll likely roll straight into giving it structure. By structure, I’m referring to the exact content you want to store and, ultimately, present on some channel. For our artist content type we’re going to capture their:

  • Name (text)
  • Bio (rich text)
  • Genre (some type of categorization)

To capture this information in, you add fields to the content type. These fields are referred to as elements in vernacular, and can be used for entering in content directly (plain text field, rich text field, etc.). They can also be used to support your content in some special way — such as adding in a URL ‘slug’, which is a unique path for the content on a website (e.g., supports a whole bunch of these element fields, as shown below:

The editing screen for the artist content type is shown in Three fields can be seen in the editor.
The editing screen for the artist content type is shown in On the left, three fields can be seen in the editor. On the right, you can see the possible elements (content and supporting) that can be added to give structure to the content type.

With the structure of the artist content type setup, editors will be able to create new artists in the content inventory in

Screenshot of the editing UI for a content item that uses the artist content type. Example is Bill Callahan.
Example of a content item that uses the artist content type.

The Genre field in the artist content type is an example of taxonomy. Taxonomy can be used to add categorization or tagging to your content, and is another way to add more structure to the model.

This is an example of content reuse. We want to categorize the genre both for the artist and for their albums. Rather than writing out the entire list multiple times, we write it out once in the Taxonomy area of

A screenshot shows the genre taxonomy group.
The ‘Genre’ taxonomy group shows a list of musical genres that can be used to tag content items.

The Genre taxonomy group can be edited in one place and then added to any content type that we wish to use it on.


Breaking content up into types helps to make it reusable. It also makes it more accessible. Rather than having one BIG artist content type that contains each and every field for an artist, their albums, and all their songs, we’ve created distinct content types for each. This means that if I just want to get the info about a single song, I don’t need to retrieve the artist’s full back catalog from the API just to get at it. I just use the API to query for that particular song.

This is all great for managing and accessing content in a modular way, but what if I actually do want to get the information about an artist, their related albums, and the related song information from those albums? How do any of those content items know how they relate to each other?

The answer is that the relationships are defined explicitly in the content model. The primary way of linking content items in is by using the linked items content element:

Screenshot shows the fields for the artist content type. A linked item element is included which allows albums to be related.
The Linked Item field ‘Albums’ is set to require at least 1 album and only allow the editor to select Album content types. Configuring the ‘allowable content’ will help the editor know what is expected.

The linked item field can then be used by editors when they’re working on an artist content item to create the relationship between the artist and their album(s).

Screenshot shows an artist content item. The album field has a list of linked items that point to album content items.
The Album field in the artist content item is a list of linked items. The field only accepts album content types.

Linking a content item to another content item can also be done in rich text. This flexibility to relate content rather than recreating it is another way in which re-use is promoted in

Animated screenshot shows an editor adding a linked item to a rich text field in an artist content item.
Clicking into the rich text field in the content item brings up a wee menu that allows you to, amongst other things, insert a linked item.

This feels like the right spot to wrap up Part 1. In this post I’ve highlighted how modelling should help promote content reuse. Write your content once and use relationships to reuse it. In Part 2, I’m going to explore how you can reuse the actual structure of the model itself.

I’m thinking this article could make a decent video tutorial. That would let me go into a lot more detail with the app. Tell you what: if I get a hefty number of claps then I’ll roll up my sleeves and get recording. Bribery? Who, me?

For an extended trial of — use this magical link and go sign-up 😎.



Michael Kinkaid
School of Content

Hmmmmm, what can I say about me? I’m currently the CTO at Reason One, and I wish I had more willpower when it comes to snacks. Oh screw that! Pass the Fifteens.