Let’s start with a few key clarifying points:
- Content modellers create content types.
- Content authors create content items.
- Content items are created from content types.
Content modelling is a design time activity where content types are identified, classified, and organised within a content model. Content types describe discrete units of information that are valuable to the business. Press release. Hotel. Booking. Symptom. Article. All candidate content types. However, they are NOT the tangible, concrete pieces of content. Content items are the content.
Authors create content items from content types. The term author refers to someone tasked with creating content. So if an industry analyst (author) creates two press releases (content items) based off the corporate press release standard (content type), then:
Content production is the creation of content items by authors from content types.
Every content item created from a content type is an instance of that content type. Instantiation is the process of creating a content item from a content type. A big word, but simple at heart. Let’s unpack that by defining exactly what we mean by instantiation.
Instantiation is not a new term. It’s well known to developers, particularly those that perform application design. In software, objects are created from classes, in much the same way that content items are created from content types. We are building upon decades of established and widely understood type theory that we can reuse within the context of content. We are not re-inventing anything. Instead, we are bringing forward essential concepts – instantiation – that need to be part of our content modelling vocabulary.
Time for an example: we’re an events business. We’ve done all the hard content modelling work and designed a content model that reflects the core information assets (content types) and their inter-relationships across the business. Event is a key content type that describes the essential characteristic of events the business organising and runs on behalf of its clients. We use six attributes to describe what an Event is: name, logo, venue, start date, end date, and organiser. The Event content type is a design time artefact. It’s conceptual. An abstraction that does a great job of describing what an event is and the properties used to define it.
Instantiation creates a new instance of a content item from a content type.
Instantiation follows a three-step process:
- Create a new content item based off the structure of the content type.
- Assign values to the attributes of the content item.
- Assign the new content item a name that uniquely identifies it.
Instantiation creates a new instance of a content item, that is a tangible, uniquely identifiable, unit of information that we are now responsible for managing. And as any knowing parent we tell you, creation is easy part, the real challenges lie ahead.
Instantiation by Example
Brazil is playing host to both the 2016 Summer Olympics and 2014 World Cup. We’re in the events business remember and need to plan for this. Our Event content type outlines the structure for all our events. It’s attributes clearly communicate the essential characteristics of an event and their meaning. We are ready to create events. We are ready to instantiate content items from the Event content type. Let’s walkthrough our three step example for creating the Summer Olympics event:
Step 1 : Copy Structure
Create a new content item by making a structural copy of the Event content type. By using the content type as a template, a new Event content item is created with all attributes copied over from the Event content type.
Copy structure completed!
Step 2 : Assign Values
Assign values to all the attributes within the newly created Event content item. This is where we bring the content item to life and make the content item a real event. From this point on we have a content item that has all the values associated with the Summer Olympics.
This is the key difference between content types and content items. Content types convey the structure and meaning for your content, but they are not your content. Content types do not hold values. Content types are structure only. Content items copy the structure and meaning from content types, and take the values presented during content production, to become your content. One cookie cutter (content type), many cookies (content items).
Assign values completed!
Step 3 : Assign Name
Finally, we need to give the newly created content item a name. Why? So that we can uniquely identify it and refer back it at some point in the future. Let’s give it the same Summer Olympics 2016. We now have an event (content item) called Summer Olympics 2016, with the key event details (values), based off our Event structure (content type).
Assign name completed!
Content items are things: authors create, databases store, applications manage, processes adapt, and systems deliver. Content items are tangible units of information that are created during production, managed by the business and delivered across multiple channels to engage customers in content-driven experiences.
Content types provide the structure. Content items copy the structure, add values and are uniquely identifiable.
But before we go, think about how authors actually create content items. They’ll have structured authoring interfaces and/or other content management tools that authors use to create the content. Think about how you would create an news article in your CMS today. These authoring interfaces use content types to describe what information needs to be captured at the point of content entry. Do we know what this information is? Well, yes! It’s the attributes of the content types. Once all the attribute values have been collected by the structured authoring interface we use our three step process to instantiate content items from content types:
- Create a content item (copy structure)
- Assign the incoming values to the content item attributes (assign values)
- Give the content item a name (assign name)
Now think about how you would design these structured authoring interfaces without a content model expressing the content types and their inter-relationships. Sadly, that’s largely what we do today. We see content models designed and built bottom up by technologists because the business has not engaged upstream in the design of structured content. So technologists fill the gap because we need to create content. This is not good. We need to flip this around, to design for content top-down, in order to create content that is truly valuable and sustainable for the business. Change is coming.