|Montague Institute l Contents l Index l Digest l Courses l Calendar l Subscribe
Ten questions for taxonomy teams
Today, creating a corporate taxonomy is a team activity that brings together experts from multiple disciplines. It's important for team members to participate in learning activities as a group, preferably in a hands-on setting using their own data. This article discusses ten questions that taxonomy teams need to answer.
Who's on the team?
Every team starts out with a vision, mandate, or objective. In our experience, the most common mandate is "create a corporate taxonomy to make it easier to find internal information." That's a good starting point, but it's too limited. For example, it doesn't address such issues as dealing with multiple organizational schemes, integrating print and Web formats, setting and enforcing standards, or improving content quality. To put it another way, a "taxonomy" is a necessary part of the company's intellectual infrastructure.
Identify multiple perspectives
So the first question involves identifying and understanding the different perspectives — what they can contribute, where they overlap, and where the gaps are.
Establish a common vocabulary
The process of arriving at a common vocabulary is a good way to introduce and describe the basic taxonomy building blocks — metadata, authorities, thesauri, ontologies — as well as stress the value of accommodating multiple organization schemes.
If you can't find one person that can speak all five languages, try to include a few "boundary spanners" on the team — employees that regularly interact with two or more departments or functions.
Defining one domain or application isn't too difficult, but most taxonomy projects span multiple applications. Therefore, it's useful to define at least two domains with a common area of interest. For example, marketing and product development have different vocabularies and use different business processes, but they share a common interest — the product or service to be sold.
One taxonomy isn't enough. Even when two business processes use information about the same entity (e.g. a customer), it's likely that the type of data collected, the data source, the frequency of updates, the methods of accessing the data, and the level of detail needed for each process are different. It may be possible to have a single taxonomy architecture, but it's not possible to have a single organization scheme.
Specialized taxonomies should be linked and shared. Why shouldn't everyone use the same geographic or product codes? Why should the user have to know which collection to search or which department created the data? Why shouldn't the search engine have access to a list of synonyms and definitions, so that when the user searches for COTS (meaning Commercial Off-the-Shelf), he gets information about software instead of beds (cots)?
There are a variety of tools and techniques available to provide access to standard terms and create cross references among similar terms. The team should understand the options, as well as their pros and cons.
Departments are both taxonomy users and creators. Content creators are key to keeping taxonomies up to date. If a taxonomy system saves time and yields better information, content creators will not only use it but will invest in helping to maintain it. The goal is to make it easier to use existing taxonomies than it is to create new ones.
Metadata repositories and solutions
A metadata repository is a data structure or "virtual holding area" used to store metadata and/or the pathways to external metadata. Some metadata is entered manually through forms during the content creation or classification process. Other metadata is entered automatically by harvesting it through a computer program (see "The economics and ABC's of indexes"). These two methods are illustrated below.
A metadata "solution" consists of one or more repositories along with:
There are two aspects to metadata solutions — conceptual and technical. That's why it's important to have a multi-disciplinary team working from a common set of assumptions, definitions, and objectives. The problem is that both the conceptual aspects (represented by editors and librarians) and the technical aspects (represented by IT staff) are detailed and complex.
Theory vs. reality
It's better to find out up front that some department managers fear losing control over their data or that senior executives believe the proposed solution is too expensive. When some parts of the organization are not ready to move forward with a proposed taxonomy solution, the team can:
Striking a balance