SharePoint 2010 Taxonomy Limits

SharePoint 2010 introduced managed metadata for the first time – the Managed Metadata Service (MMS). You can create a hierarchy of terms (metadata) and then use those terms to classify content stored in SharePoint. If you decide to rename a term, all items classified will be updated to reflect the new term. That’s the managed bit.

For an overview, please read an earlier blog post: SharePoint Managed Metadata Overview (Nov 2010)

Whilst the MMS is a great addition to SharePoint, it doesn’t cover all taxonomy requirements. This post will briefly explain the different types of taxonomy and what SharePoint can and can’t do to implement them.

The short version:

The SharePoint MMS can create taxonomies with a single hierarchy or multiple hierarchies using term sets. It can also be used for folksonomies by using a keywords list of tags. It can nearly do polyhierarchies, by reusing terms across term sets, but with limited uses.  If you have a deep taxonomy hierarchy to implement, you may need to add FAST to your SharePoint deployment.

The details:

Types of taxonomy

A taxonomy is a hierarchical form of classification. You define a hierarchy of metadata terms that can then be used to classify and describe stuff.

There are three main types of taxononomy:

• Single hierarchy
• Multiple hierarchies
• Polyhierarchies

And then there’s the informal rebel, the folksonomy.

Single Hierarchy

The simplest of taxonomies – a single hierarchy containing all the terms you plan to use. In this example, I’ve started with Flowers. That means the only things I’m going to classify are flowers. If I want more in a single hierarchy, then flowers would be a sub-class with a parent – e.g. plants, which may have a parent – organic material, that may have other sub-classes like mammals, which would have a sub-class for primates etc.  A single hierarchy is simple in theory but quickly becomes complex as you try to organise all possible terms.

Which is why, unless you are a library or garden centre, you end up with…

Multiple (Faceted) Hierarchies

In the digital world, we don’t need items to be located in only one place. We can use multiple hierarchies to describe them.  I might be looking for tulips. I might be looking for anything with red petals. I might want flowers that open earlier or later in the year for my garden.  Thanks to multiple hierarchies, I can find what I want without having to know where to look first.

Polyhierarchies

The most complex of taxonomies – a polyhierarchy is where a child or sub-class has two or more parents instead of just one.  Jasmine can be in the form of a shrub (small bush) or a vine (tall climbing plant).  Instead of being listed twice, the word is listed just once and linked to the two different parents.

Folksonomy

A folksonomy is the informal version of a taxonomy. It is simply the use of tags to describe objects. An object may have many tags. A tag may be reused for many objects.  There is no hierarchy – all tags are equal and there is no relationship between them.  You don’t define the tags first. You create them as you go. Once a person has created a tag, it’s added to the list.

A folksonomy can seem chaotic and confusing. Its success on the Internet, on sites such as Flickr, has been because it is a lot easier and quicker to simply tag items than have to select from a pre-defined hierarchy that may not match your vocabulary (imagine if plants were described using their Latin names).

SharePoint and Managed Metadata

SharePoint’s MMS can be used for both taxonomies and folksonomies.  Within Central Administration (and can also be accessed via Site Collection Administration) is the Term Store Management tool.

Keywords

SharePoint’s folksonomy is a group called Keywords:

When any item is tagged, either using the Enterprise Keywords column available in lists and libraries or by tagging site pages, the tag is added to the Keywords group (1. above).  As you start to type a tag, SharePoint will automatically suggest matching tags as you type (2.), to avoid having multiple spellings of the same word.  You can manage your keywords (3.) If you want to clear out unnecessary tags, you simply delete them.  If you also have a taxonomy, you can move popular keywords into the term set and make it part of a formal hierarchy. This is a great way to develop an effective taxonomy rather than a taxonomy filled with unused terms.

Term Sets

SharePoint uses term sets to create taxonomy hierarchies, with the following levels:

You create a group to contain one or more term sets.  A group with a single term set would be a single hierarchy. A group with multiple term sets would be a multiple or faceted hierarchy.

Within a term set, you create terms. Each term can itself have terms. In the image above, we have a group called Taxonomy Examples (created for this post). The term set is called Colours. The first level of terms contains Blue. Beneath blue is a second level of terms: Royal Blue, Cambridge Blue and Navy Blue.

Terms can be re-used across term sets, which sort of (but not quite) enables polyhierarchies.

In the image above (click on it to view in larger detail), I have a group called Plants. It contains term sets for Shrubs and Vines. The Shrubs term set contains a term called Jasmine. The term has been re-used and linked to the term set Vines.  If you look at the right side of the page,  displaying the term properties for Jasmine, in the box ‘Member of’ we can see the term is linked to two term sets. If I rename Jasmine, both term sets will be updated.

To create this polyhierarchy, the group Plants is the class, and the term sets are the first sub-classes. It has to be done this way because you cannot re-use a term within the same term set.  But this creates a challenge because only the built-in Enterprise Keywords column allows users to pick terms across groups and term sets. Managed Metadata columns have to point to a specific term set.

Whilst you cannot re-use a term in the same term set, there is nothing to stop you having duplicate terms, i.e. two or more terms with the same name. The downside is that you are creating extra terms, each with its own properties, which is extra work to manage and can be confusing for people.  But duplicates enable you to use a single term set that works better with the Managed Metadata column.

It’s probably easier to demonstrate:

The image above on the left is displaying the term store within the MMS. At 1. is the polyhierarchy example: A group for Plants with term sets for Shrubs and Vines, each linked to a single term, Jasmine (it has a slightly different icon to show it is linked to more than one term set).  At 2. I have created the alternative scenario, a single hierarchy with duplicate terms. This time, Plants is the term set with first-level terms for Shrubs and Vines. Each has a second-level term called Jas.

The MMS is used in two ways within SharePoint lists and libraries:

• Enable the built-in Enterprise Keywords column, which points to the entire term store (all groups and term sets).  It is always a mult-value field (people can enter one or more tags) and if the words entered are not already in a term set or the keywords group, they will be added to the keywords group. (Side note: the label ‘Enterprise Keywords’ can be confusing since it points to all groups in the MMS, not just the Keywords group).
• Create columns of the type ‘Managed Metadata’ which must be pointed to a single term set. However you can then specify if the column is to contain only a single value versus multiple values, and whether or not people can create and add their own tags or must choose from the list provided.

The top-right image is displaying the properties form for an item in a document library, with the built-in Enterprise Keywords column (3.) enabled. As I type in Jas, three suggestions are offered – Jas in the term set Plants, under the term Shrubs; the duplicate Jas in the same term set Plants, under the term Vines; and, Jasmine from the group Plants, displayed once but showing both term sets that it is linked to. In this image, the correct method would be to use the Polyhierarchy (from 1.) so that I can classify the document as about Jasmine, regardless that it is both a shrub and a vine.

The bottom-right image is displaying the properties for a Managed Metadata column (4.). When you create a column of the type Managed Metadata, you have to point it to a single term set.  This is where the polyhierarchy (1. in the image above) fails in SharePoint because I can’t point the column to the group Plants, I have to pick one of the term sets within the group, either Shrubs or Vines. I don’t want separate columns for each sub-class within plants. My alternative approach (2.) with duplicate values does work because Plants is the term set. But then how do I decide which Jas to pick to classify my document?

And there’s another gotcha.  One of the most useful reasons for implementing managed metadata is to refine search results.

The image above is displaying a standard SharePoint search results page. On the left side of the page are the search refiners.  I have two term sets listed – Department and Products.  Under Products, I can refine results by SharePoint, Content and Apps.  Here’s the rub. My term set hierarchy is as follows:

• Term set: Products
  • First-level term: SharePoint
    • Second-level term: Content
    • Second-level term: Apps

The standard search refiners in SharePoint do not display a hierarchy under the term set, it is simply Term Set as the heading, and all terms listed beneath, regardless of their position in the term set hierarchy.  A deep hierarchy within a term set does not work well with the standard search refiners, they are better suited to flat hierarchies – term set as the class with just one sub-class of terms.  In this example, I should either keep the term set Products but have just one level of terms – the product names (SharePoint, Office etc.) or make the product the term set if I want to classify by feature, e.g. term set: SharePoint, terms: Content, Apps etc.  The alternative is to upgrade my SharePoint deployment to include FAST, which is Microsoft’s advanced search and taxonomy tool. FAST includes the ability to configure your search refiners to match your taxonomy hierarchy.

In conclusion, the Managed Metadata Service enables you to create all three types of taxonomy: single hierarchy, multiple hierarchies and polyhierarchies, as well as the folksonomy of keyword tags.  However, you can only use all these methods with the built-in Enterprise Keywords column, which cannot be locked down if you want to restrict what words can be used to classify content.  The Managed Metadata column can be locked down but only works with a single hierarchy, meaning you either have a deep single hierarchy or have to create separate columns for each term set.  Search refiners work best with multiple (and flat) hierarchies, they do not work well with a single deep hierarchy.

To design the MMS effectively for search, you have three choices:

1. Flatten your taxonomy:

• Use multiple term sets, each with a list of terms – i.e the term set is the class, the terms are a single sub-class. Do not have a hierarchy deeper than that.
• If using the Managed Metadata column, you will need a column per term set.  Essential if you need to restrict people to picking from your defined lists of terms.  Aim for fewer term sets. This will likely mean not going to deep with your taxonomy (in my Plants example, I’d need to either drop the final level – Jasmine, or drop the sub-clases of shrubs vs vines vs flowers, and just have a term set of Plants with terms for the type: Tulips, Roses, Jasmine etc.
• Use the Enterprise Keywords column when you don’t mind people adding their own tags (will be added to the Keywords group). Matching terms will be suggested to help avoid unnecessary duplicates.

2. Upgrade your deployment to FAST

If your taxonomy is too important to flatten but you still want to use search refiners (you should, reasons for classifying content usually include making information easier to find), you need to consider whether or not to configure FAST in your SharePoint deployment.  FAST includes advanced search refiners that include displaying a deeper taxonomy hierarchy.  It also includes the ability to auto-classify. But may involve additional licenses so you need to factor the cost into your project.

3. Use a specialist add-on

The third option is to use an alternative (non-Microsoft) taxonomy solution that can be added to your SharePoint deployment.  You are likely to also require an auto-classification tool.

If you are immediately thinking that option 1 is not good enough for your taxonomy needs, before heading to the second or third option consider if your taxonomy is good enough for your organisation’s needs.  Folksonomies have succeeded where taxonomies have failed because of their ease of use.  It’s no use having a deep and detailed taxonomy hierarchy if people make mistakes, choose the defaults or just click the first in the list to get through classifying their information. And auto-classifiers are a long way from perfect.

No metadata is better than bad metadata.

Related blog posts

• SharePoint Managed Metadata Overview