Five Myths about Taxonomy and SharePoint

[This post originally appeared on DigitalLandfill.com on August 25, 2011.  It has also been included in AIIM's Governance in SharePoint Toolkit which is available free to Professional Members or $99 to others.  Use coupon code PROMEMX2 to extend your membership through December 2012 when you upgrade to Professional for $139.]

Many organizations are finding that leveraging the full suite of capabilities SharePoint offers requires introduction of a new requirement – that of dealing with, managing and exploiting taxonomies.  Of course taxonomies are not new, but there is some confusion about where managed metadata services and the term store end and true taxonomy management begins.  There are also some misconceptions about the process of deriving and applying taxonomies in SharePoint.  The following are five areas of confusion that we have seen in our engagements and research. 

Myth #1: SharePoint now has taxonomy management

Reality -- The term store management tool is not a taxonomy management system.  It is called a term store and not the taxonomy manager for a reason.  True taxonomy management allows for various types of relationships beyond the parent child (kudos to the SharePoint product team for addressing the lack of hierarchy in 2007). It does handle what are referred to as equivalence terms or synonyms.  These are called “other labels”, which are used to guide content contributors to selection of a preferred term, or “default label” - and hold little inherent value beyond display in auto-suggest). But a real limitation is the ability to handle different types of equivalence terms.  One might want to manage misspellings, acronyms, technical terms, internal terms, etc in different lists and expose them to users in different contexts.  For example, one can do term substitution with more sophisticated taxonomy systems and show one term to a medical specialist and another term to a layperson.  There is also no capability to manage associative relationships in SharePoint.  These are the relationships that show how something can be conceptually related but is not necessarily a parent child relationship.

It’s important to note the lack of workflow associated with term addition, modification and deletion. Changes to taxonomy in the term store can occur without review or approval, which can lead to repercussions like downstream processes becoming out of alignment.  If someone changes the name of a marketing campaign or a solution without correct input and approval, people may not know where to find the correct document or inconsistent terms may be used in other applications which can affect the brand.  There is no audit trail that tracks term history and insight into changes over time can’t be understood. Also absent is the ability to easily define custom attributes for terms and term sets, essentially the metadata on the metadata.    

Myth #2: Taxonomy is used as metadata and metadata is an IT problem.  Therefore taxonomy is best left to the project’s technical resources.

Reality -- The common wisdom is if it is data related or metadata, then it’s in the IT realm. In fact, IT can own some metadata but the business users need to own and manage business language.  Taxonomies are expressed in content models and have technical implementation considerations.  However, terms are used to communicate business concepts and business concepts are the realm of business specialists.  The language that is used to describe solutions, markets, offerings, risks, products, features, etc is business in context, perspective and usage. A balanced approach requires enrollment of business stakeholders in taxonomy development and management in a way that is derived with business users and then translated into technical elements. This means establishing content types that are reflective of content itself which include unique metadata schemas, templates, workflow and document retention schedules.

Myth #3:  Librarians are the best people to handle SharePoint taxonomies.

Reality -- SharePoint is a complex platform and handing this task off to a library science specialist who does not have the appropriate expertise would not yield optimum results.  While good at what they do, taxonomists and library science people tend to want to build comprehensive and exhaustive taxonomies but in some cases all you need is a way to simply navigate information using a broader classification.  SharePoint has limitations from both a taxonomy and IA perspective and it needs to be considered as more than just terminology but also application in lists and libraries, navigation and search. Therefore, it is important to have someone with library science understanding but not exclusive of SharePoint development or IA.  

Myth #4:  SharePoint taxonomies need to be comprehensive and finely grained.

Reality -- Taking too narrow or too broad a perspective can lead to problems. Just because you are able to create a seven level hierarchy with thirty-thousand terms doesn’t mean that you should. Taxonomies should not, as a rule, be very deep (no more than a few levels) but this also depends on how the taxonomy is exposed to the user.  Other questions to consider - how many term sets are needed? How will they be managed? Can we make use of a single managed metadata service or do we need to leverage multiple? Which site collections will consume which services? Not only do we need to be cognizant of how we model our taxonomies, but in the SharePoint perspective we need to now pay closer attention to how we model the constructs that consume and manage them. The best way to determine optimum depth and breadth is to test based on user scenarios and use cases.  The question is what to test.  In some cases one can test the taxonomy by itself, in others we need to test the taxonomy in the application such as in search refinement or tagging processes.

Myth #5: Taxonomies managed in the in the term store can be used everywhere in the SharePoint application. 

Reality -- here are some interesting nuances to this “myth."  The reality is that we can manage terms in the term store and leverage in many places however terms in the term store do not influence all places where the taxonomy can be exposed.  There is a complex relationship between taxonomies, navigation, search refinement, enhancement and content object models.  Taxonomy labels can be applied at any level – site collection, site, library, list, content type, view or term itself.  In each case, the meaning of the term needs to be understandable to the user in the context of where they are in the application and what task they are executing.  Terms however are managed in the term store for application as metadata to content.  So the taxonomy is used throughout the site but terms are managed in the term store for specific usage in content. 

Summary:  Succeeding with Taxonomy

In summary, managing a controlled vocabulary is critical to effective use of SharePoint.  Business-ownership of terminology is mandatory for effective results.   It’s important to understand the limits of the SharePoint term store in order to properly evaluate the role of other tools for taxonomy management and search optimization.

SharePoint can be the catalyst for a serious look at enterprise taxonomy.  In the end, however, effort on an enterprise taxonomy should be more than a SharePoint initiative. It needs to be part of enterprise architecture that spans many systems and processes.   A governance body for managing controlled vocabularies needs representation from across the business with an eye to leveraging taxonomy to meet overall enterprise findability goals, whether content emanates from SharePoint, other ECM programs, business intelligence applications, ERP and transaction-based systems, and social media.

Add new comment

Filtered HTML

Plain text

Refresh Type the characters you see in this picture. Type the characters you see in the picture; if you can't read them, submit the form and a new image will be generated. Not case sensitive.  Switch to audio verification.