Thursday, March 15, 2018

Subject Searching: Why a Taxonomy, Thesaurus, or Controlled Vocabulary Still Helps in the Age of Search

Subjects, topics, index terms, keywords, controlled vocabulary, thesaurus, taxonomy. These all refer to an organized, precise way to find and retrieve desired information, where that information has been indexed to terms. Indexing content with subject terms can be manual or automated, but in either case the focus is on what the content is about, not what words appear in the text. The subject terms represent unambiguous concepts, which may have synonyms, but synonyms are often included as cross-references to redirect to the preferred term name and thus to the same set of content. Before the era of digital content, subject categories or index terms were the only method to find specific information, such as in a back-of-the-book index or business categories in the yellow pages.

Using subject terms to find desired content contrasts with using a search engine for full text search. Search is based on the occurrence of words, not concepts, so appropriate results can be missed if they use different wording for the same concept, and inappropriate results can be retrieved if a word has multiple meanings. The accuracy of search, without the additional support index terms/subjects, is dependent instead on the sophistication of algorithms. The combinations of algorithms have improved only slightly in the past decade or two. What has made a bigger difference in retrieving good results through search (without subject indexing), is that in many cases the volume of content has grown, and when search results are arranged by relevancy, a larger number of initially displayed search results are satisfactory.

There are two issues with this kind of search. Ordering results by relevancy is not always the preferred option. Sometimes searchers are interested in timely stories, so they want their results to be ordered by date, newest first, but when relying on a search engine, newer results might not all be insufficiently relevant.  Secondly, such results are good for the searcher who only wants to get some or enough information on a topic. If instead, the searcher wants to perform an exhaustive search and retrieve everything available on a topic, there will likely be relevant content that is missed in the search retrieval because it was worded differently. Indexing with subject terms improves both precision (accuracy, where incorrect content is not retrieved) and recall (comprehensiveness, where appropriate content is not missed).

The role that index terms play in the search process has evolved. Originally, researchers started with browsing a full list of subjects that may have been arranged alphabetically (as a traditional book-style index) or hierarchically (as a taxonomy), and they navigated the index to find more specific subdivisions as aspects of the main heading, or they navigated the taxonomy to drill down to the most specific term. As the volume of indexed documents or other content items has grown over the years, browsing and selecting a term from a taxonomy or thesaurus is often no longer as practical or sufficient. An individual term may have too many records indexed to it. Furthermore, many taxonomies and thesauri have grown too large to easily browse.

So, instead of taxonomy terms being used as the primary starting point to find desired content, taxonomy terms are more often being used to narrow or filter search results.  The user executes a search in the search engine, and if they get too many results, they can limit or filter the results by various aspects listed in the margin, including by indexed subject. (Other aspects could be date, document type, author, source etc.) The subjects can display in order of frequency of occurrence on the records in the search result set, and the user can select among them, rather than having to browse the entire taxonomy or thesaurus.

Use of subjects and other attributes to limit search results is becoming very common across various implementations, so most people are familiar with using them, such as enterprise search systems to find internal corporate documents, ecommerce websites for selecting products, library databases for selecting research articles.

The use of subjects to limit search results is similar to a faceted taxonomy, although the designation “faceted taxonomy” typically refers to a taxonomy where different types of terms are grouped into multiple facets. In other words, a faceted taxonomy involves several facets or filters, whereas a traditional taxonomy or thesaurus may comprise a single facet or filter, which may be used in combination with other, non-taxonomy filters.

I will be exploring and demonstrating this topic, specifically in the case of library subscription databases, in a presentation “Customer Focused Thesauri,” in addition to a pre-conference workshop on taxonomy creation, at the Computers in Libraries conference in Arlington, VA, in April.

Sunday, February 25, 2018

Taxonomies for Filtering and Sorting

Taxonomies are versatile and may be used for various purposes. Originally designed to support hierarchical browsing of topics linked to content, they also may be implemented to support more accuracy in searching. Most discussions of taxonomies have focused on browse and/or search, but taxonomies may function in additional ways: enhancing filtering and sorting.


Taxonomies structured into facets serve a combination of search and browse, and thus serve what is often called “faceted search” or “faceted browse” (as described in a previous blog post, Faceted Search vs. Faceted Browse). However, it’s simpler, more accurate, and more helpful in understanding facets to consider a faceted taxonomy as serving a distinct role from browsing or searching, that of filtering.

Filtering is a common function which is not limited to use with taxonomies. Filtering can be done by non-taxonomy attributes, such as keyword, author, date, etc., if these are set up as metadata and implemented as filters. We see filters in situations which lack taxonomies in options in the email inbox or lists of documents in file management user interfaces. We also find filters on documents in SharePoint libraries and other content/document management systems, which may include taxonomies. In a user interface, the icon for filtering is a funnel (where you can imagine that it is lined with a cone-shaped filter paper).

Filters may be known by other names, such as “Refinements”/“Refine by” or “Limit by.” These designations may be used interchangeably, although they tend to be used different circumstances. “Filtering” may be done on search results or on a complete set of records, such as a list in a spreadsheet or table. “Refining” or “limiting,” on the other hand, would usually be performed only on the results of an executed search, as a further refinement or limiting factor on an initial set of search results which turned out too large. “Refining,” furthermore, suggests a more careful search process, so this name is more often used in research databases or other repositories of articles and resources.

A relatively small faceted taxonomy comprising short lists of terms for each facet/filter, from which the user can select from a displayed list or drop-down, is both easy to use and, with proper tagging, can achieve accurate retrieval results.


Sorting is done on content in a spreadsheet or table, where data on content items is in different columns, with sorting done by an attribute of an individually selected column. Sorting could be by numeric order, by alphabetic order, by date, or by the mere presence of a binary value.  Indeed, most sorting does not involve taxonomies, but it can.  If a column is for “Topic” and items have been tagged with taxonomy terms, then the items can be sorted by taxonomy term topic.

The function of sorting with taxonomy terms may not be quite as common as filtering, since it is not done on search results but only on data in a table or spreadsheet. However, in many situations content items are presented this way: content in spreadsheets and databases, messages in an email inbox, content items in SharePoint libraries and various kinds of content management systems, and many other applications. Furthermore, it’s often simpler to sort than to filter.

Sorting is nevertheless a function associated with taxonomies, at least in the definition of taxonomy in the ISO standard for controlled vocabularies. ISO 25964-2:2013 in section 3.83 defines taxonomy as a “scheme of categories (3.5) and subcategories that can be used to sort and otherwise organize items of knowledge or information.”

The following screenshot from SharePoint shows the availability of both sorting (by clicking on the down-arrow next to a column name, such as Topic), and filtering (by selecting Topics in the filter pane on the right).


As taxonomies are versatile, the same taxonomy can be used for multiple purposes: browsing, searching, filtering, and sorting. However, a taxonomy design usually can be optimized for the user experience of only one or two implementations. So, a taxonomy that delivers a great user experience for hierarchical browsing, might not be best suited for filtering or sorting, or vice versa. Filtering is more accommodating for various taxonomies than is sorting, since it may not be necessary to display the entire taxonomy in filters.

Sunday, January 28, 2018

Best Practices for Different Taxonomies

A question was recently posted to a group: “I'm wondering if anyone knows of a standard for designing taxonomies for industrial components (widgets).” So far, no one has replied.

To clarify, taxonomies for different subject areas and different content don’t have different standards. Standards, whether for interoperability, such as SKOS, or for structural design, such as ANSI/NISO Z39.19 or ISO 25964, are the same and just as relevant for taxonomies and thesauri in all subject areas. Taxonomies for different subject areas and content may have different design best practices, though. The published standards don’t spell out everything; there is room for design and style differences for different taxonomies, including those that differ in their subject domain and content.

Areas of taxonomy design best practices that may differ include:
  • Degree of term specificity or granularity
  • Depth of hierarchical levels
  • Number of terms at the same level (i.e. the number of narrower terms a term has)
  • Length of terms
  • Use of parenthetical modifiers and other term label fields
  • Additional attribute details for terms (notes or controlled value fields)
There are also issues of relationships between terms (whether a term may have more than one broader term, and whether there should be associative/related-term relationships) and how extensive alternative labels/synonyms shall be. Best practices for these issues, however, depend more upon the implementation and user interface for the taxonomy than on the subject area of the taxonomy.

In the case of an industrial component taxonomy, best practices for the aforementioned points would likely be of the following:
  • There should be relatively high level of specificity of terms to include all components
  • Depth of hierarchy that accurately reflects standard component categories and subcategories. So this could be deeper than for other, business taxonomies. Also, the levels of depth may vary in different parts of the taxonomy.
  • The number of terms at the same level should also accurately reflect standard component categories and subcategories, so there could be a large number of terms at the same level.
  • The length of the term should be complete and unambiguous, but any component number should be managed in a separate field.
  • It may be desired to use some additional numeric or alphanumeric classification system. If so, the classification code would be another field or component of the term, separate from the term name, for purpose of sorting.
  • Additional attribute details for each term would be desired and expected. These may include a component number, size, price, and other specifications. (Attribute fields may or may not be searchable. They are not for filtering, though, as facets are.)
In contrast, a consumer products ecommerce taxonomy would follow different best practices:
  • Terms should not be too specific, not more specific than what users would be familiar with. Specificity should reflect the number of units (SKUs) covered by the term category. A term that refers to only 1-5 products is probably too specific. If there are additional refinement filters, then a category term may be broad enough to include 10-50 items.
  • Hierarchy should not be too deep, probably no more than 3 levels.
  • Terms per level should be limited, such as 3-12 terms per hierarchy level
  • Term names should be concise, for easy browsing, yet unambiguous, usually 1-3 words
  • Terms should probably not have any other fields/components or parenthetical qualifiers
  • Attribute details would include at minimum product number/SKU and description. Price would be managed as a separate filter, rather than as merely an attribute.
These best practices are not “standards” because they tend not to be shared outside of an organization. Each organization comes up with their own policies and guidelines, just as they have their own taxonomies. The best practices could be considered internal standards, though. Regardless of what they are called, these guidelines should be documented and overseen as part of a taxonomy governance plan.

Sunday, December 31, 2017

Engaging Others in Taxonomy Building

Whether you are building a new taxonomy from scratch or redesigning one based on an existing taxonomy, it’s important to engage other people in the process. There are two primary reasons:
  1. getting input from those who will use the taxonomy, so that it will better suit their needs
  2. getting buy-in and support from various stakeholders and users, so that it will continually be used, maintained, and funded
Even if you are the only person given the responsibility for creating and editing the taxonomy, and it’s no one else’s job to be involved, you should still seek the input of others.

It’s just common sense to get input from those who will use the taxonomy, although being respectful of their time in the process. If the taxonomy project can be stretched out over time, this means that asking for input does not happen too frequently.

Getting buy-in and support is an issue that is especially particular with taxonomies. People don’t always understand or respect the full benefits of a taxonomy. They may think that search alone or automatically generated keywords may suffice. Or they may prefer the simplicity of a search box. People responsible for tagging might prefer to avoid that task to save time and thus not adequately or correctly apply the taxonomy. Getting such people involved in the taxonomy creation process both educates them about the benefits of the taxonomy and gives them a sense of ownership by contributing to the process that is meant to serve them.

Others in your organization will use the taxonomy. If it’s for tagging and retrieving content internally, some people will use the taxonomy to tag content, and other people will use the taxonomy to help find content, but representatives from both groups of people should be invited to give input. If the taxonomy is to be use for public-facing content, those who will be tagging the content are still within your organization, and they should be consulted in the taxonomy design process.

Taxonomy consultants might lead 2-day taxonomy brainstorming workshops of stakeholders, conduct a series of interviews with stakeholders and users, and develop detailed use cases. While there is usually not the interest in demanding so much time of others when the taxonomy project has been assigned to a person on staff, the taxonomist should still engage other employees, at least at a minimal level. To get initial input, instead of in-person interviews, this could involve emailing a short list of questions to key users and stakeholders and the following up with a phone conversation to go over the answers. Draft versions of a starter taxonomy, which can be developed by means other than a brainstorming workshop, should be shared with stakeholders and subject-matter experts for feedback.

A rather technical taxonomy could start with asking the subject matter experts to submit lists of terms which the taxonomist would review with them and edit into proper taxonomy. In most cases, however, the taxonomist develops the draft starter taxonomy and then seeks feedback.

If you are not asking stakeholders to provide the starter taxonomy, where do you start? Someone asked me that question recently: “Where do I go to get my starter/basic/beginner list before I actually sit with staff?” I advised that you don't need much prior to talking with people. My recommendation, in the case of an enterprise taxonomy, would be to consider the following sources for draft taxonomy terms:

  1. Folder names from shared drives
  2. A prior attempt at creating a starter taxonomy, even if never implemented
  3. Categories or tags set up in a content management system, whether or not fully used
  4. Intranet/website site map or navigation menu labels
  5. Product catalog top categories (as a starting point for a "Product" facet/Term set)
  6. Org chart (as a starting point for a "Department" facet/Term set)
  7. High-frequency use terms from search log reports
Include at least the two of these sources to share with people in meetings. I also recommend not editing them prior to initial meetings with people, but rather to get their input on this raw data.

Taxonomy work, is thus people-oriented work, like information architecture, in contrast to related fields of indexing and cataloging.

Friday, November 24, 2017

Auto-categorization and Taxonomies

Taxonomies and thesauri are only truly useful if their terms are appropriately indexed or tagged to content. My path to taxonomist had been as an indexer, so I always value the importance of human indexers. Nevertheless, I must acknowledge that automated indexing, also called auto-categorization, is becoming increasingly common and important.

At the most recent Taxonomy Boot Camp conference (November 6-7, in Washington, DC), a trend I discerned was the increasingly commonplace use of auto-categorization (or at least machine-aided indexing) with taxonomies. Conference presentations didn’t state auto-categorization as something new but rather sometime more matter of-the-fact, and by the way, the software vendor used in this case is so-and-so. There were also sessions on artificial intelligence and taxonomy and on leveraging taxonomy management with machine learning. There is also a lot of interest in text analytics, a field broader than auto-categorization, which justified the first Text Analytics Forum conference co-located with and immediately following Taxonomy Boot Camp (which I, unfortunately, did not have time for).

When conference speakers and others state that automated indexing has been proven repeatedly in test comparisons to be more “reliable” and more “consistent” than human/manual indexing, while true, that does not mean it is better. Human indexing is certainly not as consistent, as two trained indexers will not index exactly the same way, but the way they differ is rarely so substantial. One indexer may add an additional index term. Another indexer may index with a slightly different, but related, term. Automated indexing, on the other hand, while consistent, is not as correct. Depending on the method, it can be approximately 20% inaccurate, indexing with completely wrong terms or completely missing the most appropriate terms. That’s where “machine-aided indexing” comes in, where indexing is initially automated, but a human quickly reviews the suggested terms, adding or deleting terms as appropriate.

The primary reason for implementing automated indexing is not so much to achieve consistent indexing, but rather to achieve efficient indexing. This is because the amount of content to be indexed in many organizations is growing too fast to be kept up with by manual indexing. Publishers of external content for subscribers have also transitioned to partial automated indexes or machine-aided indexing.

While enterprise search engines do not utilize taxonomies by default (but can be configured to make use of them), auto-categorization software generally uses some form of taxonomies. Search engines can function out-of-the-box without any taxonomies or controlled vocabularies, although a search thesaurus (a.k.a synonym ring) can significantly improve search precision and recall. Auto-categorization software, on the other hand, relies on “categories,” which can be simple controlled vocabularies or hierarchical or faceted taxonomies. Thus, as auto-categorization is gaining wider adoption, the need for taxonomies to support them is also growing.

Automated indexing technologies have not advanced significantly in recent years, but there have been improvements in auto-categorization software by effectively combining more than one technology method within the same software product. The main technology methods are (1) rules-based and (2) machine-learning. Regardless of the method, automated indexing is still not fully automated. Humans are required to put in time and effort beforehand to either write or edit rules for each taxonomy term, or to provide and test training sets of sample documents to index for machine learning. These could be dedicated roles or additional tasks to be performed by the taxonomist.

Auto-categorization is also becoming more common, because software products that effectively combine taxonomy management with auto-categorization have become more established and better integrated. Although there are many organizations which continue to use distinctly separate software for each of taxonomy management and auto-categorization, organizations newer to taxonomy adoption prefer to have a single solution. Synaptica is the one major taxonomy management vendor which does not yet include fully integrated auto-categorization, and they are very actively working on incorporating the technology. I have separate chapters in my book, The Accidental Taxonomist for software for taxonomy management and software for auto-categorization, but in my second edition I ended up repeating more vendors in both sections.