itsMeta

The critical prerequisite for a Content Interpreter is having the content in a structured and organized manner. There are two core components to a successful content management strategy.

The first is the versioning, storage and maintenance of the master copy of the files. This is the realm and strength of industry standard Enterprise Content Management Systems (ECMS) and strategies.

Second, content must be made accessible for content managers in a way that allows them to determine the feasibility of a new idea quickly and easily. If a product manager sees an opportunity to provide a collection of content to a partner in a particular format, he should be able to nimbly gauge this opportunity during the time he on the phone with this partner. If an editor wants to create a collection of assets to give out at a conference, she should be able to browse the content, chunk relevant sub-sections from larger publications, and create a customized publication for this specific occasion with rapid ease.

These advanced content browsing and creation capabilities, however, are outside of the capabilities of traditional ECMS. What’s needed to meet these needs is a Content Interpreter: a system that sits on an ECMS or Digital Asset Management System (DAMS) and converts relevant digital content from a large repository into human comprehensible content.

In the next post, we'll go over the conceptual architecture of the Content Interpreter.

In the case of XML, a Content Interpreter is an architecture that consists of an XML database that stores and indexes XML, with a business layer application that provides business intelligence and content transformation capabilities.

These specialized functions are not mature features within ECMS or DAMS. To gain these advantages it is necessary to look for a 3rd party package to integrate into the ECMS or DAMS. In the market, there exists a number of mature XML Database solutions including but not limited to Mark Logic and the open-source eXist.

The key points of implementing a Content Interpreter are:

1. Integration with the content repository.

It is imperative to draw a hard line between the functions that the ECMS and the Content Interpreter are responsible for. For ex. the ECMS should “publish” to the Content Interpreter.

2. Scalability.

The Content Interpreter should be able to handle an enterprise’s full structured content set.

3. Speed.

The Content Interpreter must be able to execute queries in real time and can be quickly extended to create new ways of searching and grouping content.

4. Configuration.

The Content Interpreter should not be a black box but rather a transparent collection of modules that can be configured to meet new requirements.

5. Lightweight.

The Content Interpreter should be relatively portable, and not requisite of an advanced engineering degree to manage and operate.

To meet these five key points of implementing a Content Interpreter, a sophisticated programming language that is simple and lightweight is required. Since the architecture is comprised of an XML Database and a business logic layer, the natural choice is XQuery (XML Query Language). XQuery is a natural fit because its inherent capabilities are to execute tasks such as combining, searching and comparing data.

The Content Interpreter’s layers

The implementation of a Content Interpreter is more an exercise in setting up the appropriate architecture and sticking to a key set of rules as opposed to what tools and technologies are used. Looking at the Content Interpreter from the bottom up, the following outlines its four logical layers:

1. XML or structured content layer – the physical content.
2. ECMS or DAMS layer – the management of the content.
3. XML Database layer – the indexing and searching of the content.
4. Content Interpreter layer - the business application layer.