Content modelling at the BBC using RDF and OWL

Content management at the BBC

We expect that the future of the BBC, and the broadcasting and publishing industry in general, will rely heavily on new technology and the way in which it can provide context, navigation and gateways to different types of content. To enable this, we need to create content in such a way that it can be reused any time, anywhere, on any device. Our strategy is to make our content digitised at the point of creation, atomised so that it can be repurposed, and findable through having the correct metadata. The BBC’s “on-demand” strategy aims to cross all media, all content types and all devices.

“Rather than creating TV, radio or online content, the BBC needs to think in terms of creating media assets for the future, flexible enough to be used across all devices and in all environments. […] We will invest in making our content available on demand in ways that will benefit both the public and the industry, grouping them under one banner so that they are more easily recognisable and usable to the user and more manageable, in terms or resource and direction, for the BBC. We must also ensure that the correct rights are in place for use and re-use.” - BBC’s internet strategy

The “Content Management Culture” group within BBC New Media Central was formed to address this issue. The group is facilitating the move from many disparate, hand-crafted “content production systems” to a small number of interoperable content management systems that “speak a common language”, to allow re-use and adaptability of content, and ease of implementation and maintenance.

When the Content Management Culture group was in its initial planning stages, it analysed the BBC’s content management and re-use problems and the way in which industry experts and other organisations have approached the issue. Our main influences were the work of content management consultants Ann Rockley [ROCKLEY03], [ROCKLEY06] and Bob Boiko [BOIKO02], Information Architecture consultant Louis Rosenfeld [ROSENFELD], and others in the content management and information architecture fields.

Based on this analysis the group decided that the best approach would be to create a shared content object model that describes the BBC’s content in an atomised, re-usable way, and a shared metadata model that allow the content to be described in a way that lets us find it again in the future.

For example, we can break down a page on a web site into separate, atomised, reusable components: an “article text” object, one or more images, web links, audio and video links, perhaps some objective information such as a person profile, event description, or sport result. These individual “content objects” can be pulled together in a different way to be published to another platform such as interactive television or mobile phones, or syndicated to news readers, or re-published as a PDF file for printing, to name a few examples. By breaking the content down in a sensible way, the optimum balance between ease of content creation and practical re-use can be struck. By annotating the content objects with a known, re-usable metadata structure, based on controlled vocabularies of descriptive metadata terms, the content can be found and re-purposed easily. For more information on our semi-automated metadata system, see [HARVEY05].

A shared content and metadata model

The goals behind a shared metadata and content object model are similar to the goals of most XML-based publishing projects, particularly those that span multiple departments and multiple content management systems. These include:

• We can avoid re-modelling each site/project separately, reinventing wheels of content as we go, by having different teams re-model the same content independently. Actually it is more likely that we would end up re-modelling “by accident,” by re-inventing our content structure to suit the quirks of each tool as we implement new systems. This is a common problem with organisations that don’t take a “model-oriented” approach and dive into CMS implementation without first addressing the modelling issues.

• Having a common description for our content types gives us scope to aggregate content across all of bbc.co.uk much more easily. For example, if we have a common set of attributes to describe a “person”, be it an actor, writer, newsreader, sports personality or historical figure, then we could create a rich vein of content that links together all people referred to by any bbc.co.uk content, to allow serendipitous content browsing and to link our sites together through a common navigation “hook”.

• Using shared descriptive metadata terms allows for content repurposing and re-use, and minimises content duplication. For example, the easier it is to find images about the cheese rolling competition in Devon(???), the less likely the situation where our journalists will need to go to an image bureau and purchase a new copy of an image for which we already own publishing rights.

• In fact, using a common approach to rights across all of our content, through common fields in a content object model, also benefits rights management in the sense that rights can be checked and enforced in an easier way.

• Our “model-first” approach ideally creates a content object and metadata model that more abstract than any particular implementation of that model in a CMS. Therefore we should be able to translate the model into implementations in any CMS that can handle a model in the format we describe here. At the moment, that means the system must use XML-based (or otherwise hierarchical) discrete objects that can handle inter-object relations, and must support querying on those objects based on metadata terms. This aspect of the approach requires more investigation before it can be proven that our model is truly interoperable; this will be an area of future work.

Implementing the shared model approach

To create a shared content object and metadata model, first a team of information architects and business analysts work with the project stakeholders (content creators such as journalists, their managers such as editors, graphic designers, senior management, business people, and of course site users) to determine what are the most important parts of content on the site (or other property), what is no longer needed, and what broad content types are required. The output from this stage of the project is known as a content audit. They may also be able to draw up some wireframes and a site map if the business side knows what they want their site to look like. In addition the business analysts gather a requirements specification that describes any high-level requirements from the business side.

At this point, the technical and information architecture teams should join together to decide which direction to take for the next stage, content analysis, which dives deeper into determining what individual content objects, property fields and business rules should be created by the CMS to implement the pages desired by the business users. The output of this phase is the first iteration of the content object model, which in the first generations of our project was implemented as a Word document looking something like the following:

Figure 1: example content object description in Microsoft Word

Problems with early implementations

We soon discovered that a tabular format in a word processor was not the best way to describe the content objects, partly because a two-dimensional table couldn’t simply represent a multi-levelled hierarchical model (e.g. a repeatable set of properties within another repeatable set, for instance a player within a team in a sports result object) and relationships between objects were very hard to manage.

To avoid some of these problems, we included some information in appendices to the “COM” to handle controlled lists of terms used in objects (e.g. the types of image that could be created, map, photo, cartoon etc) and metadata terms. Other information was included in “notes” columns in the tables (e.g. the dimensions of images that could be associated with articles in different places) and some in completely separate documents, such as the soon-to-become-infamous “cardinality spreadsheet,” which determined how many of each object type could relate to each other object type.

In addition to this complexity, when it came time to implement two “clients” in our content management system, we had two copies of each of these documents, that described how the content object models used the same objects but with different slants such as different image sizes or numbers of articles in an index.

Having so many documents describing the same content made implementation and maintenance of the CMS extremely error-prone and time consuming, and testing took far longer than it should have, because simple errors and inconsistencies in the documentation couldn’t be spotted by looking over the two 120-page word processor documents and additional spreadsheets and other material.

To make matters worse the documentation set we used was incomplete -- some elements of the business logic, and editor-level presentation rules, were only described in the actual XML configuration files that were created for the particular CMS we were using. This caused two problems: firstly, our developers were left to define parts of the system that should have been modelled much earlier in the design process; and secondly we fell into the trap of designing for a particular system rather than being led by the model.

It took a great amount of discipline within the information architecture and technical teams to ensure that we didn’t introduce inconsistencies in the shared model (e.g. accidentally different article types for different clients) – we were able to mitigate most of these problems by taking care in our modelling approach and cross-checking everything by hand, but this was slow and error-prone itself.

As a direct result of these problems, the project’s bug resolution cycle was overly complex: testers would spot a bug, raise it to the developers, who might then need to go back to the IAs for confirmation on a problem or inconsistency. Client-side developers might not hear that the model had slightly changed, so they might build XSLT templates against the wrong version of the spec, which would mean that further bugs would arise, not to be found until later in the testing process, etc.

So after the second client implementation, we knew that we had to step back and solve the content modelling problem.

A model-driven architecture approach

When we embarked on the project to “modelling our models” in a new tool, we realised that we were entering a world of multiple abstraction layers and separating design from implementation. At the time the project began, we didn’t know much about model-driven design and MDA, but as we learned more about the approach we realised that it fit quite well with what we had originally set out to do – that is, to be “model-driven” rather than “tool-driven” in our approach.

The model-driven architecture approach [MDA] divides a modelling project into layers of models which, with a small stretch of the imagination, can be seen to closely match our layers. The MDA system was mostly created for software design projects, but it seemed to apply quite well to solving our data design problems.

If one thinks about our problem as have object instances (e.g. actual articles and images) at the lowest level, then object definitions for a particular client a level up (e.g. what fields and business rules define an Article object for BBC News or Radio & Music), then general system-level definitions (e.g. what makes article objects from News or R&M shareable with each other), then the actual system that stores those object definitions, we have something like a classic tiered MDA pyramid:

Figure 2: MDA-like view of the COM Management Tool (with apologies to the Object Management Group)

Another way of describing our model in an MDA-like way would be to say that the model maintained in the tool was the “platform-independent model” and the configuration files generated for a particular CMS product out of the standard model was the “platform-specific model”. This would probably be closer to the original MDA specification.

Creating the metamodel

Before we started thinking about what software we would use to implement the COM Management Tool, as part of the requirements gathering process we created a “metamodel” that defined how our content object models were structured, and what we needed a tool to support. The idea is that the tool should allow users to create content models that adhere to our metamodel, and prompt the user with warnings and errors if she tries to stray from the model.

The core parts of the metamodel are objects, containers and properties. These non-system-specific “classes” each have “subclasses”, such as BinaryObject and ContentObject, which can then be instantiated to create the model for a given content object.

This is a variation on the standard hierarchical metamodel, following all document-style XML models. A relational model, implemented in a simple relational database such as Oracle 7 or Microsoft Access, would differ from this in that it would only include objects and properties; the “container” class would not exist. Using “container” classes allows us to model XML more closely, and also to allow for repeatable elements without creating new objects for a person’s appearances in a programme, for repeatable sets of telephone numbers, etc.

It is important to note that the metamodel only describes the content structure side of what was in the Content Object Model document: properties, containers, and objects, plus how objects can relate to each other (through the ContentObjectReferenceContainer), but no details on how the interface is presented to CMS users, or how the content is displayed on a web site or interactive TV platform, for example.

Figure 3: Simplified UML model of Content Object Model Management Tool

We feel that this “content object model model” is quite generic and may be useful for other content creators in similar situations. To help the community create similar models in the future and to help to set a convention or best practice, we plan to release our content models to the public in the future.

Investigating solutions

Implementing the metamodel in Protégé

Early designs led to something that worked very quickly, and through Protégé-OWL’s support for refactoring, we were quickly able to create an implementation of the metamodel that allowed us to test theories and quickly change the way we handled different types of object and relationships between them. With little knowledge of RDF or OWL, we could simply create “classes” and “instances” (also known as individuals in Protégé-OWL) to implement our metamodel and instance models.

Custom extensions and plugins to Protégé

We made several customisations to Protégé, using the extensible Java plugin API, to implement some custom requirements for the COM Management Tool project.

These include:

A set of locked-down selector widgets, such as “RestrictedMultiChoiceSelectorWidget”, to replace existing widgets in our forms. We want to ensure that users cannot accidentally choose related properties or objects that are disallowed by the restrictions defined in the class, so this enforces the constraints defined in the metamodel

A “Content Template” generator, which uses the model to create empty XML instance files for each object type, to be uploaded directly to our Content Management System

Similarly, a “Rules File” generator, which creates configuration files that tell our CMS how to present objects to CMS users for editing and the business rules around how objects can be selected and manipulated

We also built a custom CVS integration plugin, to connect with our corporate version control system. Protégé doesn’t provide CVS compatibility by default as it is assumed that concurrent and large-scale use will be facilitated through using the Protégé group server, which we did not need at this stage of the project.

Issues with using RDF/OWL to describe content object models

Speed to implementation

Content Object Model design and implementation projects will be much faster now as we have removed a large chunk of tedious work in implementing a paper model using somewhat fragile and error-prone XML configuration files. We now produce virtually all server-side object model configuration information automatically from the RDF/OWL model. Previously most of these files were created and tested by hand – over 10,000 lines of XML per deployment.

In addition, consistency errors in the COM documents were hard to notice, whereas now, with re-use of properties and containers amongst objects, it is much easier to detect and fix inconsistencies when they occur, and it is harder to introduce inconsistencies as the system encourages the use of existing properties rather than creating new, duplicate and perhaps inconsistent properties.

Transparency of the model and the solution

The nature of our new system is that it brings together the two sides of the content modelling process: our developers, who create the XML configuration files for the CMS, write supporting custom code, and define more technical aspects of the COM such as what queries will help to find related content for a particular object, and our information architects, who analyse the content and design the content objects.

The fact that the developers and IAs work more closely and can see each other’s work in progress means that issues are raised and resolved much earlier in the project lifecycle, before any code is written, and before any bugs are introduced. This should also serve to reduce implementation and bug-fixing time.

In addition, the transparency of the model should mean that bugs and omissions in the model implementation (e.g. the CMS editing screens) can be remedied by IAs easily using the COM Management Tool, rather than using the previous lengthy process of raising the bug, going through developers, checking with IAs and editors, implementing a fix, and then being tested again by all parties.

It ensures that everyone has the same understanding of what an object is and does (everyone who understands the Protégé model, at least).

Automatic documentation

As described above, we built an extension module for Protégé that generates HTML-based Content Object Model documentation that can be presented to business users. This also removes the need to manually write documentation for models and the business rules around them.