Let’s start by setting aside the technological issues, because these are largely irrelevant. Metadata may be stored in a database separate from a file, or in a distinct table, or marked up differently, but this isn’t the determining thing that makes it different from other data or content held in a system. It can even be an inherent part of a document. What makes metadata different is how it’s used.

Metadata is used for classification. It’s used to relate one piece of content to another and to help people and systems find relevant information. If it’s not serving that purpose then it’s not metadata.

This may lead you to the conclusion that I’m saying everything is metadata. But it’s not. Some content that is marked up as metadata isn’t really metadata at all, or is at best poor metadata. Take a look at the UK’s National DNA Database, for example. This database records ethnicity and skin colour as a way to search for people, but one person’s view of their ethnicity may not be shared by another’s. This disparity has effectively rendered this metadata set useless. The records on ethnicity and skin colour are potentially useful as content, but unreliable as metadata.

So if you’re looking to define metadata types and corresponding taxonomies for your content, you have to consider how those doing the classification will apply the metadata and how other people are going to use that classification. If it’s not useful, it’s not metadata. If it is useful, you’ll be on your way to managing your content.

This is usually because few people know the content really well, while those who do are seldom in a position of sufficient authority to enforce processes and guidelines to make the website a streamlined communications tool. The communications team in charge of the site are put upon by subject experts and non-web marketing managers who insist that they need a new page, often linked to from the homepage, that promotes their unique piece of content.

Unless you have a really tough manager taking charge of the site, this spells trouble. Content is added without an over-riding communication strategy and very little content is taken away. It’s a symptom that you see most often in the public sector, where people’s fear of breaching misunderstood legislation like FOI mean that content purges are rare. Consequently website management becomes unwieldy as more and more superfluous information is piled into the CMS repository. This creates its own content management issues, but the most significant problem is lack of focus on the website.

If this is the case for your website, you need two things:

1. A clear objective for your site.
2. A clear process for dealing with duplicate content.

When you find duplicates, or a request is made to add content that resembles content which exists already, you need to ask the following questions:

1. Does the new content meet the website objective? If it does, process the request. If not, reject it.
2. Is there evidence that your audience requires the information supplied by the new content. If so, process it. If not, reject it.

If the content exists already and is fulfilling its remit but isn’t being read by your audience, you have an information architecture issue. This is the justification for promoting the content as a feature on the homepage or elsewhere on the site.

These are all basic editorial issues, but if you’re suffering from them it’s probably not because you have bad editors but because your editors have little support. You need to help them develop and communicate this very simple process and ensure that it is enforced. The clarity of your process will translate into clearer content on your website.

At the most basic level, content types are a classification tool used to distinguish groups of content. Typically, websites will have site sections, news stories, reports, and so on. But this basic classification is handled easily by metadata: just tagging a page as a “news story” and using that tag as a link to other news stories is very straightforward. It’s not really making any use of the content type metaphor.

So what are the benefits of content types?

1. They provide structure.

Larger sites need structure for several reasons: it helps contributors to enter the right kind of information (title, summary, event dates); it helps them to put content into the right areas of the website or intranet; and, it assures consistency in site design across pages that have the same function but different content.

2. They scale the system.

Being able to distinguish between a job, an event and a personal profile is essential if you have a large site with lots of contributors. Content types help with the information architecture of your site for public users and contributors alike; they enable you to introduce navigation that you just would be very difficult achieve without this concept.

3. They enable devolved ownership.

Most websites are “owned” by a marketing or communications team who are keen to ensure house style across the main publication, but who would be happy for other departments to own and maintain their own content that doesn’t require editorial review. If you don’t have content types, it’s a pretty difficult task to set up areas of the site that one department can contribute to without having free reign to change everything, particularly if you want to ensure that public website navigation doesn’t simply reflect your departmental structures. If you have structured content that doesn’t require editorial intervention (press releases, jobs, events, etc.) you can simply assign ownership of these content types to internal teams without compromising the editorial quality of your overall website.

If you’re struggling with findability or devolving ownership of content on your site, there’s a good chance that it’s because you’re lacking the structure to cope with the increasing size and complexity of your site content. Revisiting your defined content types could well be a good place to start.

I think that byline was a bit facile, but the article does prompt a serious debate about where taxonomy and more particularly expert taxonomists are heading. When organisations think web 2.0, they think wikis, user-generated content and tagging. They don’t think about well-organised content. Web 2.0 implies the death of expert taxonomy rather than the death of taxonomy itself.

People just don’t want taxonomists; they think they can organise content for themselves. While this may be true, it’s unfortunately also true that they just can’t organise content for anyone else. This creates a particular problem for systems which are dependent on finding very specific information: intranets, for example.

If you need your audience to be able to retrieve information reliably, don’t look to “audience development officers“: recognise that taxonomists do have an expertise that you’ll find useful. However, not all information needs to be structured, so feel free to challenge any taxonomist who tells you otherwise.

1. Identify key user types (personas)
2. Identify key tasks they need to undertake (user journeys)
3. Develop navigation to enable journeys (site maps)
4. Develop user interface that will enable users to complete journeys (wire-frames)

Main advantages of doing things this way:

• You’re not trying to fit in existing content unless it’s actually useful to your users.
• You can identify content that’s missing easily.

There are more useful IA definitions at iaonesheeters.com

Taxonomy is about classification. It describes ways of naming, arranging and ordering things within a system. Those things may be books in a library, or plants and animals in biology.

Taxonomies are usually hierarchical and based on restricted terms. In biology, for example, there are a limited number of kingdoms, phyla, and classes. In the Dewey Decimal System, these restricted terms are based on numbers: Phonology (414) is an element of Language (400). These relationships are often described as ontological.

Some things can belong in more than one place in certain classification systems. For example, a dish on a menu may be available as both a starter and a main course. These ways of looking at the item are often termed “facets”; so a Greek salad is both a type of dish (salad) and a course (starter).

The “thing” in question may also have one or more synonyms which form part of a taxonomy. There is some overlap here with the functions of a thesaurus.

A recent innovation brought to the fore by websites like del.icio.us and Flickr is the concept of “folksonomy”. This allows participants to “tag” any page, image, or document according to their own vocabulary. As more people tag pages, these become related by shared terms, building up the classification system. This taxonomy is unrestricted: what one person calls design, another may call art, creativity, or even Photoshop.

How are taxonomy and content management related?
Content management typically addresses a number of key areas:

• Production: providing the tools to enable people to create content.
• Authorisation: ensuring that only relevant people are able to view and amend content.
• Workflow: delivering content to people within the system once it passes through certain stage gates.
• Storage and retrieval: providing a mechanism to store, find and re-use content held in the system.

Content management systems (CMS) can make use of taxonomy for authorisation and workflow, but they are dependent on taxonomy for storage and retrieval. Each page, document, or other asset held in the CMS is stored according to a predefined classification method.

There are different metaphors for this method. The taxonomy may be represented as types of document (e.g. contract), as departments with their own document silos (e.g. legal, marketing, human resources), as folders that represent some other business function (e.g. project start-up, initiation, execution, closure), or flagged with a value from a predefined list. Most CMS will use a combination of these classification systems so that content can be retrieved more easily.

Taxonomy vs. metadata

Taxonomy is often applied as metadata: that is data about data. Office documents have metadata assigned to them such as author and revision date. (To see this in your Office application choose File >> Properties and click on the summary tab.) Web pages also have metadata. There are a number of ways to view this, but the simplest is to choose View >> Source in your browser menu. Close to the top of the page you’ll see some HTML tags beginning meta name=”". The name attribute is the type of metadata they describe (description, copyright, keywords, author, etc.) while the content attribute holds the metadata itself. Metadata is often assigned from pre-designated classifications, so is an important part of any taxonomy project.

Where can I see taxonomy on the web?

In its simplest form, taxonomy on the web is represented as website navigation. Many of the techniques applied to develop taxonomy are used to develop more user-friendly websites. This includes activities like card sorting.

More complex taxonomies can be found at dmoz.org (a directory of websites) or, for medical research, GoPubMed.