Fit-for-Purpose Taxonomies
A common request from our customers is the ability to deliver the right terms at the right time. Delivering the right terms at the right time is more than simply maintaining taxonomies to ensure terminology is up to date but also involves delivering the right set of terms to the right users at the right time during a concept and content lifecycle. Specifically, customers have a need to deliver a specified subset of a taxonomy or taxonomies to the users who need them.
One method to address the need to present a subset of concepts is to develop multiple taxonomies specific to each consumer and deliver these as they are needed. Another method is to structure multi-purpose taxonomies to precisely serve different groups by negotiating shared requirements and ensuring they are built into a single, common enterprise taxonomy. Both of these methods are impractical as they necessitate a nearly unsustainable level of maintenance in governance processes. Both methods also require updating multiple vocabularies which may only differ in structure or may involve multiple instances of the same concept used in the same or different ways.
Why only present some terms to users and not all of them? Let’s cover some alternatives to delivering taxonomies with the right terms at the right time before we get into use cases.
Structuring Taxonomies
It is tempting to develop taxonomies which are ready for publication exactly as they have been built. In fact, the delivery of taxonomies can help to determine the way they should be modeled but should not force workarounds for sound taxonomy practices. Building good taxonomies requires bearing in mind that what the taxonomist develops within a taxonomy or ontology management tool does not need to be what the user sees on the front end of the system they use to do their jobs.
In an organization in which a taxonomy can be easily aligned with a functional business unit, a good strategy might be to build separate taxonomies for each consuming organization, especially if there is no interaction between the schemes. If the Finance Department only deals with financial terms, a Finance Taxonomy might suit the purpose. In most cases, however, operations are not this simple and clearly aligned. A more practical and flexible approach might be a single faceted taxonomy in which a facet called Finance interacts and has relationships with concepts in Geography, People, Organizations, and Topics facets. Again, it’s possible to deliver a single facet to the end users who need them while retaining relationships to concepts in other facets while not surfacing everything.
Even more likely, however, is that separate or faceted taxonomies will have terminology across all vocabularies which are relevant to the consumer. The problem many groups face, though, is delivering multiple or complex taxonomies to users who have specific use cases and no interest or knowledge of the other domains covered by the vocabularies, presenting concepts which may be unknown or confusing to the end user and unnecessarily complicating their experience. In many cases, the end users only need specific terms in their job roles to tag content or fill out forms. Presenting too many concepts for selection creates unnecessary burden on the user to search for or navigate to the needed concept. Why should a user need to search through ten thousand terms when only ten are relevant to their work? Yes, it would be possible in this case to provide these users with hard-coded, application-local term lists to choose from, but this defeats the purpose of having centralized taxonomies in the first place. How can we deliver some concepts to certain users and other or all concepts to other users?
Filtering Taxonomies
Whether your organization requires a single taxonomy or ontology covering all aspects of your business or multiple taxonomies, the ability to filter and choose what is delivered can reduce the amount of work it takes to surface the appropriate concepts. In addition, it allows for a customized user experience without the back-end work of customized taxonomies.
The ability to filter a taxonomy by a given property is an easy, non-invasive way to consolidate terms for output which can be applied and ready for use within a taxonomy or ontology management tool. For example, a simple Boolean flag could be placed on a concept, such as Ready for Publication: True/False. Likewise, a designated property with a list of organization-specific workflow statuses, business units, months of the year, or any other filtering property appropriate to the organization can be added and set once or changed over time as the concept moves through its workflow. Such a flag or property can be added to a whole taxonomy, a branch of the taxonomy, or concepts spread across one or more vocabularies. In our ontology management system, Graphite, we have the notion of a Collection. Essentially, this is a metadata property which can be applied to any concept in one or more vocabularies to act as a grouping and filtering mechanism for viewing within the system or exporting to other systems.
While these properties can be grouped and viewed within a taxonomy or ontology management system, the real practical application is the ability to output based on one or more of these properties and sending them to consuming systems via APIs or exported reports. For example, if an organization had COVID-19-specific terminology scattered across multiple vocabularies, regardless of their organizational strategy, the ability to group these concepts from their various locations and surface them in an application quickly developed to provide information to consumers is invaluable.
While the use of APIs is typically a cleaner and less invasive way to filter and port concepts to their consuming applications, another option is to set up report parameters within the tool, save them as a reusable query, and schedule exports in the desired format to be ingested by the target system. While exporting and ingesting files is not as elegant, it can be useful if the reports are run infrequently because they require fewer updates or there is less dynamic change. Similarly, it may be a matter of who is performing the updates to the system. In an environment in which business users can upload files for use but do not have technical support, providing file-based taxonomy extracts might be more appropriate.
The ability to deliver the right terms at the right time is an important aspect of taxonomy development and deployment. If users can see a selected subset of a controlled vocabulary, especially if the properties used to do the filtering can be mixed and matched, delivering highly customized and seemingly complex varieties of a taxonomy does not need to be highly customized and complex on the back end. Since taxonomies are never done, delivering appropriate terms to users makes a taxonomist’s life a little easier.
