A Single Taxonomy
Controlled vocabularies are meant to provide a single source of truth for terminology. Within the enterprise, the goal of a taxonomy program is to have one or more taxonomies serving the entire organization rather than having many competing vocabularies with distinct terms, scopes, and applications.
In most organizations, however, various end users and consuming applications can have very particular needs. For example, not all users need to see every concept in a vocabulary, especially large vocabularies covering many knowledge domains. Likewise, consuming systems may need only selected subsets of a vocabulary or require the use of different labels or properties from the same concepts used by end users in another way.
Attempting to create separate vocabularies for use by multiple users and applications is not only time-consuming, it defeats the purpose of using controlled vocabularies as a single source of truth. In addition, creating multiple vocabularies and trying to reconcile the differences (and the similarities, for that matter) takes time and can be extremely complicated.
Let’s look at how the many faces of a single taxonomy can reveal themselves to different end users and applications.
Permissions
The first way to view or use a single taxonomy in more than one way is through permissions. These permissions can be limited to the taxonomy management system or may carry throughout the information architecture assuming downstream applications can also use and apply the same permissions model.
A taxonomy permissions model is used to control what users can see and do to a controlled vocabulary. Permissions can include administrative permissions such as who can create, edit, or delete a new project, a new vocabulary, the properties and relationships available for use, and other features used to set up and develop vocabularies. Editorial permissions may include who can view, edit, and create and delete concepts, their properties, and relationships.
Permissions can control who can access the taxonomy management system and perform actions. For example, a taxonomy editor may have one or more taxonomies they review and they have full authority to create and edit concepts. A taxonomy reviewer may be able to see all concepts but can only edit selected properties.
Granular permissions can change the way a single taxonomy can be viewed by users. In some instances, hiding properties and their values may be for security reasons or simply to declutter or target only appropriate information. A taxonomy reviewer may not need to see a Scope Note field while a taxonomy editor may need to see and edit this field.
If these permissions can be enforced outside of the taxonomy management system in downstream consuming systems, then permissioned users have a consistent view across platform and application experiences.
Filtering a Taxonomy
In consuming systems, there is more than one way to filter a taxonomy for use in both navigational and typeahead displays.
Using the concept status, such as Candidate or Published, is one way to control which concepts are available for use. While the controlled vocabulary may be completely viewable in the taxonomy management system, only those concepts in the published status may be viewable in downstream navigation structures or tagging interfaces. This allows for a single vocabulary to be a work in progress while approved and published concepts can still be employed in production environments.
Taxonomy management system APIs tend to be very flexible. Not only can taxonomies be filtered by status, they can also be filtered by branches or other subsets of the vocabulary. In a single taxonomy with many top-level facets, users may find only some of them pertinent to their work. Showing only those branches scales down the size of the vocabulary and makes the user interface more usable. Some taxonomy management systems also include categories or collections which can gather concepts together across one or more taxonomies, ignoring the hierarchy altogether. When large taxonomies have many related concepts across one or more taxonomies, gathering them in a single, pared-down view can make the end user’s job much easier.
Taxonomy concepts can also be filtered by their relationships. If the relationships between concepts are constrained by the taxonomy management system, then these relationships can be potentially exploited in consuming systems. For instance, a relationship like has content type or has topic constrains the choices available. You would not expect to see “Meeting Minutes” in the has topic relationship but it makes a lot of sense to find the concept in the has content type relationship.
Versioning for A/B Testing
I’ve written previously about using taxonomies for A/B testing. While technically not a single taxonomy, a good practice for taxonomy A/B testing is to start from a single common vocabulary and fork them into two independent versions.
The intent with forking a taxonomy for A/B testing is to draw a line in the sand, exposing both taxonomies to end users randomly (for navigation, browsing, tagging, etc.) and collecting analytics about how users perform using either version. Whichever one comes out on top is the version carried forward. Continuity stems from the fact that the original work in progress taxonomy is still inherent in both versions with only some differences in concept location, top level groupings, or possibly even concept label changes. Most concepts and concept locations are maintained and are unambiguously identified (ideally by using a URI) while any changes can be mapped back to their original source.
Using a single, forked taxonomy for A/B testing provides a way to maintain a single source of truth even when that source of truth diverges for testing changes which may improve the overall use. The new, accepted version moves forward while the original or forked version is archived as a point in time indicator of a taxonomy trial.
Many Faces, One Taxonomy
The many faces of a single taxonomy prevents the proliferation of competing vocabularies and the tedious overhead involved in developing unique taxonomies for each use case and maintaining and governing these vocabularies into a harmonious whole.
Using a single enterprise taxonomy or set of taxonomies is not only a best practice providing a single source of truth, but it doesn’t prevent the organization from using it in many ways for many different use cases.
