When we speak of routing content, we refer to making content available in additional or different places. In some cases, this involves actually moving content, but in many instances it refers only to changing access permissions, sharing content or links, or opening portals. The goal is to make content available anywhere it is needed, in the formats that are needed.
Most important among the concerns for routing content are:
- Routing content vs. routing metadata
- Making content available to users and the public
- Routing content between business systems
- Publishing content to output channels
Collectively, these considerations account for the vast majority of content routing requirements.
Routing content vs. routing metadata
In the traditional digital asset management paradigm, there is a distinct difference between content and metadata: the file is the content and the DAM system (database) record contains the metadata that describes the contents of that file.
For file-based content, this paradigm still works. But “fileless” content is increasingly common. Emails, blog posts, tweets and Google Docs are common examples.
To be technically correct, these content types also have associated files, such as the file of the database where the Google doc is stored. What is different is that the user is not exposed to the underlying files for these and other content types. Still, content needs to be managed, no matter what the format.
Another type of fileless content is content that is created as a result of combining other content elements into a single entity.
Consider any given website page. The page text might have come from a Word document; the images from individual files created in Photoshop; and the videos linked to from YouTube. But how would you manage the page as a whole? How would you add metadata to make the page findable from within a content system, or more readily accessible for research. Where would you flag, for example, that the page includes a reference that will need updating in 6 months?
Most website content management systems (WCMS) lack flexible metadata options. They might permit a tag or two, but little more. A content system can be used to manage website pages, even if the pages themselves are hosted from another system.
With that website page in mind, think about a campaign landing page or a press kit. In these cases, you also have a collection of content serving as a single piece of content. What is different here is that you could create content like this in a content system. Using templates, as previously discussed, new content of these and other types could be created fairly easily. Then, of course, they would also need their own metadata profiles to define and manage them.
Where fileless content is considered, metadata is the asset. When that metadata describes a remote page or video, it enables users to find those resources without having to know what to search for on the Internet. And when that metadata is itself the content, as is the case when building landing pages or other such templated-based content within the content system, the metadata is all there is.
Metadata without Data
The term metadata suggests there is data. This distinction becomes confusing when the data is the metadata, and vice versa. For the purposes of the next generation of content management, assume that the line between the two will continue to blur.
This excerpt from Picturepark’s Routing Digital Content through the Enterprise is part of a multi-part blog series that features sections of the complete document.
It is a good idea to think of archiving as nothing more than a change in lifecycle stage for content. Archived content might be reusable at any time, so the notion that you are “done” with any content forever might result in missed opportunities.