Ontological Taxonomy Approach

We are currently in the process of building our corporate information Taxonomy to associate questions to the hierarchy nodes and associate solutions to those questions.  Besides benefits for our search engine, this Taxonomy provides a tree structure guiding users to solutions to problems, best practices, knowledge experts, and lessons learned.  During numerous prior Taxonomy creation projects for Knowledge Management Initiatives, I found this milestone of the project the most difficult and always requiring significant refinement after the Knowledge Repository deployment.  I hoped to take an Ontological approach and derive a new method for creating this information Taxonomy that quickly provides enterprise adoption and decreases node restructuring once deployed.  Before moving on with my approach, I want to describe my interpretation of a Taxonomy and Ontology.

Ontology:
Ontology tends to be more industry focused for how that industry communicates.  It defines Subjects & Objects and the relationships between both.  The Ontology for the financial industry is different then the Ontology for the legal or telecom industry.

Taxonomy:
Taxonomy tends to be more internal business specific for organizing artifacts in a hierarchical structure.  This is the development of a common framework to organize content & vocabulary.  This allows a single piece of content mapped to multiple parents within the hierarchical structure.

Traditional Taxonomy hierarchy structures would require users to memorize the path(s) where artifacts might reside.  Whereas, Ontology focuses on the way we think and organize artifacts, it does not allow a classification method for artifacts (objects) to relate to other parent subjects.

My approach is to create a Taxonomy that adheres to users (Customer Service Representatives) thought patterns.  I term this an Ontological Taxonomy approach!  I first determined a subset of users of our Knowledge Repository; three Subject Matter Experts (SME’s) from each of the five regions I support.  We first discussed the component of the Knowledge Repository selected (Kana IQ) and concepts required to associate artifacts within a logical structure (the Taxonomy).  Next, we threw out random topics where knowledge artifacts would reside within a corporate hierarchical Taxonomy.  Once we had twenty high-level Taxonomy parent nodes I asked which nodes could fall under one of the listed nodes.  This helped us decide four main goals:

1. Which nodes are logically better presented as children within the Taxonomy
2. Which nodes could be parent nodes of the Taxonomy
3. The relationship between nodes
4. The relationship for a node to have the same child as another node

From the exercise, the following six parent nodes were defined, 1) Product, 2) Sales, 3) Tools, 4) Customer Service, 5) Policies & Procedures, and 6) Trouble Shooting. 

Next, we utilized the Visio Brainstorming template to map deeper under each of the parent nodes.  The goal is to only go three deep, in some cases we went four deep, and reach a node level where we derive questions allowing the ability to map best practices to each question. Remember, the same question can be mapped to multiple nodes. 

This exercise fostered almost zero arguments or debates since it is built around the nomenclature of the Ontological approach.  One SME’s belief that he/she will find knowledge artifacts down a certain hierarchical path is just as valid as another SME finding the same artifact down a different hierarchical path.  Building the Taxonomy became the simplest major milestone of this initiative.  It allows many avenues to reach the same knowledge artifact and allows it to become a living entity that changes as product and marketing offers change on a weekly basis.  In a future posting I will discuss processes incorporated to ensure the Taxonomy is agile and extensible, and how we captured feedback daily to determine that knowledge artifacts are mapped to the proper nomenclature.