When to Design a New Taxonomy for a New System

Often organizations determine that a suitable time to adopt a new taxonomy is in conjunction with adopting a new system for its implementation, such as a content management system (CMS) or digital asset management system (DAM). They can budget taxonomy design and development services as part of the consulting services needed for the content migration and system implementation project, and they can improve and optimize the taxonomy for its new implementation and use.

There is the question of timing, though. Recently, a prospective consulting client asked me whether the new taxonomy should be developed prior to the selection and implementation of a new system or afterwards. Ideally, both the taxonomy project and the CMS or DAM adoption can happen simultaneously. However, the design and development of a taxonomy takes less time (typically 3-4 months) than the adoption of a new CMS or DAM. Altogether, a system selection, with a trial or a proof-of-concept project, implementation, data/content migration, and user training, can take 6-18 months.

Benefits of Taxonomy Development Prior to System Adoption

The primary benefit of developing a taxonomy prior to system adoption is that you can make it a system requirement that the new system supports the taxonomy that you have designed to best serve your users, your desired tagging method, and the nature of your content. These criteria should take precedence over designing a taxonomy to fit the requirements (or limitations) of a CMS or DAM.

Over time, your organization will adopt other systems, and the taxonomy should be suitable for multiple systems, rather than being system specific. Especially if you have an enterprise (enterprise-wide) taxonomy as your eventual goal, designing your ideal taxonomy first should be your approach. If one system cannot take advantage of all features of your taxonomy, another system may. There are also usually development work-arounds to get the full use out of your taxonomy.

Benefits of Taxonomy Development After System Adoption

A CMS or DAM has a variety of functions, and tagging and retrieval of content with a taxonomy in only one of those functions. Workflow management, rights management, authoring features (for CMS) and image/video editing features (for DAM) tend to matter more than taxonomy use among the requirements for a system. You can make “good support of taxonomy management and tagging” a requirement for your new CMS or DAM without getting into the specifics.

Adding features a taxonomy (such as polyhierarchy, related-concept relationships, end-user scope notes, different sets of synonyms/alternative labels to support each tagging and searching) if the system you later adopt does not support them is a waste of time and resources. It’s better to wait until a system in selected and implemented before fully designing a taxonomy.

Iterative Taxonomy Design Approach

When implementing a new taxonomy with a new system, the ideal approach is to spread out the taxonomy design and development tasks over the phases on the system selection and implementation process.

You should consider basic taxonomy requirements early in the system selection process. To do this, you might categorize different taxonomy support features as essential and nice-to-have. The method of tagging (automated, manual, automated with human review, and a mix) needs to be determined as both a system requirement and as a factor in the design of the taxonomy.

Then during the lengthy process of system testing and selection, information-gathering work for the taxonomy may take place. This involves stakeholder interviews, user focus groups or brainstorming sessions, content analysis, and review of existing/legacy taxonomies and other controlled vocabularies. Draft versions of portions of the taxonomy, without all features, may be created and reviewed, prior to the system selection decision.

After the CMS or DAM is selected and is in the process of being implemented the taxonomy design can be refined with features that the new system can support, and then the taxonomy can be fully built out. The new taxonomy can also be tested in the new system for its suitability for tagging and retrieval, and final enhancements are made based on the test results. The documentation of the taxonomy, including guidelines for its maintenance (a governance plan), should be started early in the taxonomy design process, but additional system-specific documentation is created after the new system is implemented.

A Multilingual Thesaurus Standard

Standards for taxonomies are of two kinds:
1) data models for interoperability and machine-readability, namely SKOS (Simple Knowledge Organization System) published by the W3C, and
2) best practices guidelines, which focus on thesauri but are relevant for taxonomies. These are ANSI/NISO Z39.19 and ISO 25964. The International Organization for Standardization will publish a revised edition of ISO 25964 Part 1: Thesauri for Information Retrieval later this year. I have been contributing to the revision as a member of its international working group

I have written before on Standards for Taxonomies, which is at a high level, and I will likely write again about the revisions in the new version of ISO 25964 Part 1, when it will be published. For now, I’d like to discuss some the specifics of defining an international standard which I have been working on recently.

Different Language Versions

The international standard is written in English, and it will be translated into other languages in the future. Since it will not be assumed to be translated into certain languages, and since the standard covers multilingual thesauri, it needs to include examples in different languages. Some of the examples within the sections of ISO 25964-1 are translated into common languages, such as French, German, and Spanish, but other languages are not included. Thus, this standard also includes an extensive table of the “tags” and “expansions” or terminology that appear in a thesaurus for 10 additional languages. Examples of “tags“ include BT (Broader Term), NT (Narrower term), and SN (Scope note).

A German reviewer pointed out some errors in the German column of the table, which prompted me to look more carefully, and I noticed some issues in the Russian and Arabic, which are languages I had studied long ago and which are not represented by native speakers in our working group. I then sought other sources on thesauri in those languages, examples of thesauri on the web, and native-speaker experts.

As it turns out, for the specialized use of thesauri, it’s not just a matter of a translation, but what is used in the context. “Scope note” could have various translations in a language, as both the words “scope” and “note” can have different translations. Even, “broader,” narrower” and “related” can be translated differently. Broad can mean “wide,” and thus perhaps “superordinate” and “subordinate” are better translations in another language.

Variations and Lack of Standards

The thesaurus terminology is quite standardized in English and somewhat less so in other languages. Although the original ISO and German DIN thesaurus standards go back to 1974 and 1972 respectively, these standards have never been free and are actually rather expensive for the number of pages, unlike the ANSI/NISO standard, which has been made freely available since 1974. Thus, the free English-language standard from the United States has been more widely read and followed than the ISO standard. Creators of other standards sometimes translate from English, but inconsistently, rather than relying on a standard in their own language.

There are different reasons for such variations. Some thesaurus authors prefer to use terminology closer to English, while others prefer to user terminology that is more native, when near-synonyms exist. For example in Russian, “related” could be “assotsiativny” (similar to associative) or “rodstvenny,” and “concept” could be “kontsept,” or “ponyatiya.” There is also the matter of saving space with concise labels. While English has a single word for “broader” and“narrower,” a correct translation for the comparative requires two words, as in “more broad” or “more narrower” in other languages, such as French, Spanish, and Russian. Often the word for “more” is omitted to save space, but in other thesauri it is included for preciseness, such as inserting the word mas in Spanish. Arabic-language thesauri additionally vary in their use of tags/terminology depending on the region within the Arabic-speaking world of 22 countries.

I found the multilingual UNESCO thesaurus and UN library’s UNBIS thesaurus good sources to consult, since you can change not only the term display, but also the user interface with its tags and designation into different languages. However, these two UN-related sources are not even consistent with each other!

I suspect that in some thesauri the terminology was simply translated from English by a translator who was not familiar thesauri, rather than developed by a thesaurus specialist/taxonomist who would research the formats of other thesauri in that language.

Legacy Standards and Future Direction

Thesauri were originally developed to be presented in print, where space is an issue so short tags were created. Now thesauri are online, and two-letter tags are not needed and rarely displayed. But the new edition of the standard continues to include tags to be comprehensive and provide consistency with printed thesauri. However, it is my personal opinion that we should not invent comprehensive tags for all languages where they have not previously existed.

Should the standard be more descriptive or prescriptive? Descriptive would mean describing what is done in thesauri in existence. I looked up various thesauri online to see what tags and terminology they were using. If a certain designation is used more than another, such as the phrase used to mean “broader term,” then we could decide that is the standard for a language.

Prescriptive would mean to dictate the standard, typically based on expertise and belief in what would be best. In face of inconsistencies, the standard should be prescriptive. Being prescriptive would also mean that the latest revision of the standard should try to follow the prior edition and any previous translations of it, rather than merely following the usage practice the of leading examples of thesauri on the Web. The conclusion was to include both.

Although the distinction between terms and concepts is addressed in the current ISO thesaurus standard, the current summary table of tags addresses only “terms” and term relationships. The nuance of term versus concept was discussed at length by the working group and the conclusion was to include both concept to recognize an idea and term to be the representation of the concept itself.  Thus, the table of tags and terminology in the new version will now include Broader concept, Narrower concept and Related concept (which do not have tags). As new additions to the standard, the names for these in other languages thus need to be prescribed by the standard. Relying on thesauri published on the web, I found, results in too much inconsistency.  Official translations of the SKOS data model are a good source for this, but the translations exist for only some languages. I even looked at the German user interface of a SKOS-based taxonomy management software (PoolParty) and found yet other translations for broader, narrower, and related that were not consistent with the official German SKOS translation.

I hope the new edition of ISO 25964 Part 1: Thesauri for Information Retrieval will be read more widely and provide more consistency for thesauri.