Taxonomy | Sharepoint and Office 365
Many organizations are finding that leveraging the full suite of capabilities SharePoint often requires the 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 the 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 that 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 from business users and then translated into technical elements. This means establishing content types that are reflective of the 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 -- There 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.
Succeeding with Taxonomy
In summary, managing a controlled vocabulary is critical to the 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.
