SharePoint 2010 Managed Metadata Service: Classification using real estate hierarchies

Whether moving to electronic document management, implementing property management workflow, or providing dashboards for asset managers, one of the challenges we face is determining the metadata (data about the documents or information items) to capture.

Capturing more metadata tends to make it easier to find things – either by browsing or searching – but also makes it more time consuming to file documents or create content (as the metadata needs to be completed). Therefore we need to find a balance between a clear classification scheme (or “taxonomy”) and something that users will find intuitive, quick and easy.

For example, if we are creating a document library, we may want to classify documents in a number of ways:

• The business function or department that the document relates to – for example “Asset Management” or “Corporate Finance”
• The type of document – for example “Lease” or “Invoice”
• The property or assets it relates to – for example “Suite 1050, One Penn Plaza” or “London Office Portfolio”
• The related organizations  – for example “Walmart” or “Broadgate 1 Investment S.P.V. Limited”

These classifications make it easy for us to find documents: “all the Walmart Leases” or “London Office Portfolio Asset Management files”.

However, there is a very specific challenge that arises with all four of the above examples: they are most naturally expressed as hierarchies. For example, the illustration below shows part of a property – unit/suite – tenant hierarchy:

When these hierarchies are used as metadata, this is often achieved in one of two ways:

1. Simplify the metadata to a single list – for example flatten the above hierarchy to a list by concatenating the property, unit/suite and tenant all together, or compromise and just list units; or
2. Split the metadata across multiple fields linked in a parent – child (grandchild) relationship.

Neither of these are ideal: the first limiting the ability to find the document, the second making the data entry more complex for the user. Worse still, in earlier versions of SharePoint, the second approach wasn’t even supported without third party extensions.

However, SharePoint 2010 introduces a solution: the Managed Metadata Service. This service allow shared hierarchical “term sets” to be defined, centrally managed and then used in whole or part as library and list columns. This means that at last it is possible to have easy to use, hierarchical metadata columns in SharePoint.

The implementation is rich and it is the richness that makes this innovation so valuable to the real estate sector. The following lists the key advantages provided by the Managed Metadata Service:

1. A column based on Managed Metadata provides suggestions as you type, meaning that you only need to enter the first few characters of the item you want and then choose it from the automatic drop-down list:
   
2. If you prefer, you can browse the term hierarchy and select a value in a user interface designed to cope with very large hierarchies (so you don’t need to worry if your hierarchy contains hundreds or even thousands of items):
3. You can configure the column to show either the specific node selected or the complete hierarchy path down to that node:
   
4. Centrally maintained: the term sets that define each hierarchy can be imported which allows for integration with external information sources – in the examples used in this post, the property hierarchies came directly from an MRI database via a simply query joining the BLDG, SUIT and LEAS tables. This means the hierarchy can be automatically maintained in many cases.
5. You can define site columns based on Managed Metadata and reuse them throughout a site collection:
   
6. You can define site columns that use a subtree within a term set – for example a term set that contained a hierarchy comprising three levels – fund, property and suite/unit – could be used in its entirety in one site column, but in another site column it could be restricted to the properties within a specific fund. This can be particularly useful if you are deploying SharePoint as an extranet or collaborative solution with third parties who should have access to only restricted sections of the overall taxonomy.

I hope this has provided a taste of what is possible with the Managed Metadata Service. This really does change the way we need to think about the provision of metadata within SharePoint.

My colleague, Shaun O’Callaghan, will be providing a post here soon on how you implement the Managed Metadata Service.