Related Concepts in Taxonomies

A and B are related; C and D are related.

Taxonomies and thesauri are characterized by having hierarchical relationships linking their terms. The associative relationship (or related concept, Related Term, or RT), on the other hand, is a fundamental feature of thesauri, but it is merely an optional feature of taxonomies. 

An over-simplistic distinction between taxonomies and thesauri is the presence of associative relationships, although I would disagree, because taxonomies can have associative relationships, and there are other structural design differences between taxonomies and thesauri. (See my past blog posts Taxonomies vs. Thesauri and Taxonomies vs. Thesauri: Practical Implementations)

The associative (related) relationship is a generic, nonhierarchical, symmetrical (same in both directions), reciprocal relationship between pairs of terms/concepts in a thesaurus or taxonomy. "Related concept" actually refers to a kind of relationship, not a kind of concept. The following figure illustrates that Data protection and Privacy are related.

It is true that many taxonomies do not have associative relationships. This is for various reasons. The function of the taxonomy in the user interface may not require the support of related concepts, such as when the taxonomy is displayed only as facets for refining results or only as type-ahead taxonomy term suggestions when a user enters a search string into a search box. The taxonomy may be implemented in a system (such as a commercial off-the-shelf content management system or SharePoint) that does not support the links/navigating to related concepts in the user interface. A taxonomy may be too small to make beneficial use of associative relationships if most of the taxonomy can quickly be browsed and seen. Finally, and perhaps of the greatest potential significance, is that relationships across different types of concepts can instead be better supported with customized semantic relationships based on custom schema and ontologies, which can be applied to a taxonomy. For example, having Physicians practice Medicine and Medicine isPracticedBy Physicians, instead of Physicians related Medicine.

It is not so much the presence but rather the extent of associative relationships that also distinguishes thesauri from taxonomies. In a traditional thesaurus, associative relationships are as prolific as hierarchical relationships, and perhaps even more so, and they occur between terms of all different kinds and different types of relatedness. The thesaurus standards (ANSI/NISO Z39.19 and ISO 25964-1) provide a list of possible types of associative relationships (process and agent, action and target, cause and effect, object and property, object and origins, and discipline and object, among many others). When taxonomies have associative relationships, they tend to be limited to only certain categories, facets, or concept schemes of the taxonomy.

Related Concepts and SKOS Concept Schemes

Most taxonomies these days, if they are of any significant size (hundreds or thousands of concepts) and intended for use in more than one application, are created in the SKOS (Simple Knowledge Organization System) data model. (Smaller taxonomies might be created in a spreadsheet and imported into a content management system.) The highest level of organizational structure in SKOS is the concept scheme. SKOS-based taxonomy management software will group and display multiple concept schemes together in a single “project” or “knowledge model,” which is intended for a single business use, set of content, user audience, or implementation (with some overlap of multiple use cases acceptable). While SKOS does not provide any recommendation on what you should use concept schemes for, it has become common practice to designate a concept scheme for a taxonomy facet or a metadata property/field.  Even when concept schemes are not currently implemented as facets, they might be in the future, so it is good practice to created concept schemes to represent facets. The structure of concept schemes representing facets is also is also a good organizing principle for constructing any taxonomy. Concept schemes also tend to reflect top-level “classes” of ontologies (although not the very esoteric top class of “Thing”).

SKOS permits the creation of related concept relationships both within and between concept schemes. SKOS also has mapping relationships called matching properties, including relatedMatch, for use between concept schemes, whether they are in the same “project” (sharing the same, initial, domain part of a URI) or not. The option to use either related or relatedMatch across concept schemes of the same project can be a source of confusion.

Best Practices for SKOS Related Concepts

If you are implementing concept schemes each as a facet/filter/refinement in a user interface, then it is best practice not create associative (related) relationships between concepts in different concept schemes. Facets function as mutually exclusive aspects or dimensions of content items and queries. Any “relatedness” is implicit based on the search results, but not from the taxonomy itself, which should be flexible to allow any combination of concepts from facets and not prescribe relatedness. For example, a user may want to filter a search on movies by which movies meet selected criteria (facets) of a chosen genre, actor, director, topical theme, and country of production, and the result set will implicitly indicate in which movies where these aspects are related.

Enriching a taxonomy with the semantics of an ontology, in addition to supporting additional data attributes (such as movie production year, actor nationality and birth date, etc.), supports connections across concept types that can be utilized in a front-end application. The user can search not only for movies, but also search for other entities, such as actors (who appear in movies of a certain genre directed by a certain director), or directors (who directed movies on certain themes from certain countries), etc.  This involved creating customized, semantic relationships between classes which correspond to the concept schemes: Actor performsIn Movie title and Movie title hasActor Actor, Movie title isProducedIn Country and Country isOriginOf Movie title, etc. These semantic relationships, of course, make any generic SKOS related relationships across the concept schemes unnecessary, redundant, and rather meaningless.

Thus, regardless of the use of your concept schemes, the related concept relationship is best not used between concepts in different concept schemes. Rather, the related concept relationship is better used between concepts within a concept scheme, especially topical (subject) concepts, for example, relating the concepts Data quality and Quality management. Relatedness between named entities within a concept scheme, on the other hand, such as concept schemes for People, Organizations, and Geographic places, is best left to be implicit from the retrieved content and not prescribed in a taxonomy, which may be dependent on the content, change over time, and be too subjective.

Even if the current end-user application of a taxonomy does not support user interaction with related links, associative relationships can support tagging, both manual and automated. Finally, a taxonomy typically has a longer life than a single application, so incorporating in related concept relationships while the taxonomy is being built and regularly maintained is a good practice for the future use of the taxonomy.

What it a Thesaurus and What is it Good For

It is somewhat ironic that in the domain of controlled vocabularies and knowledge organizations systems that there continue to exist differing meanings for “controlled vocabulary,” “taxonomy,” “thesaurus,” “ontology,” and “knowledge graph.” Hopefully, I have provided some clarification regarding what a taxonomy is and is not in my previous posts on taxonomy vs. classification, taxonomy vs. navigation, and when a taxonomy should not be hierarchical. Let’s turn now to thesauri.

Different meanings of thesaurus

I recently attended a webinar on taxonomies, ontologies, and knowledge graphs, in which a thesaurus was described as a set of synonyms for each identified concept in a list. This is not the right definition for this context. A set of synonyms for each of list of concepts is what we taxonomists call a “synonym ring”, and what administrators of enterprise search engines would call a “search thesaurus.” The use of the word “thesaurus” in this case refers to the dictionary-type thesaurus (as the default Thesaurus entry in Wikipedia) such as Roget’s Thesaurus, where synonyms are presented for each word. Synonyms are included to support search, by matching potential words and phrases entered by users into the search box with the words and phrases that likely occur in the text of content, so that content is not missed due to the searcher using a different synonym.

The “search thesaurus” (synonyms ring) differs from the synonym-dictionary thesaurus, however, in several ways, due to their different uses:

• A search thesaurus includes phrases, not just single words as in a dictionary thesaurus.
• A search thesaurus comprises concepts that are nouns, verbal nouns, or noun phrases, not just any part of speech as a dictionary may include.
• The “synonyms” in a search thesaurus are appropriately equivalent terms that can be used interchangeably in all cases for the content repository, not synonyms that may be used in only some cases, as the dictionary suggests.

However, in the context of taxonomies/ontologies (not the context of search administration), the designation thesaurus has a significantly different meaning. Also referred to as in information thesaurus or information-retrieval thesaurus (to distinguish it from the synonym dictionary type), there is a different entry in Wikipedia for Thesaurus (Information Retrieval), which defines it as “a form of controlled vocabulary that seeks to dictate semantic manifestations of metadata in the indexing of content objects.” This is the meaning that relates to taxonomies and ontologies. More significant than the Wikipedia definition, are the published standards/guidelines for how to construct thesauri: ISO 25964 Thesauri and interoperability with other vocabularies and ANSI/NISO Z39.19-2005 (R2010) Guidelines for the Construction, Format, and Management of Monolingual Controlled Vocabularies. While the latter does not name thesauri in its title (although it did in an earlier version), it is essentially about thesauri and defines, in section 4.1 Definitions, a thesaurus: “A controlled vocabulary arranged in a known order and structured so that the various relationships among terms are displayed clearly and identified by standardized relationship indicators.”

So, a thesaurus is a kind of controlled vocabulary or a kind of knowledge organization system which is quite structured and has certain standard features: terms that are noun phrases, hierarchical relationships between terms, associative (related, but not hierarchically) relationships between terms, “synonym” or variants, which are called nonpreferred terms, and scope notes on terms. Other metadata on terms is possible, and variations of hierarchical and associative relationships may also be possible.

Thesaurus usefulness

On the continuum chart of controlled vocabulary (knowledge organization system) types, a thesaurus falls between a taxonomy and an ontology in its level of complexity and support for semantics.

Controlled vocabulary types

Since both taxonomies and ontologies are recognized as useful, it would seem illogical that something that is in between should not be considered at least as a useful. A thesaurus has the benefits of supporting more semantics than a taxonomy while not being as complex as an ontology.

Even if most relationships are hierarchical, there may be times when creating an associative relationship between related subjects seems logical and would be helpful to users, such as relating between a process and agent, action and property, cause and effect, object and origins, discipline and practitioner, etc. Or it might not be subjects. For example, ecommerce may want to recommend “related” product categories, or content on activities could relate activities to products. In an expert people finder, person names can be related to subject areas of expertise, If the scope of “related” types is kept limited, then the generic associative relationships (“related term”) may suffice without getting to level of complexity of an ontology where there are multiple types of defined semantic relationships.

The added associative relationships and comprehensive inclusion of synonyms/nonpreferred terms also supports better (more comprehensive) tagging, whether manual or automated, by providing suggestions to the indexers or providing context for the auto-classification tool.

Finally, the overall structure of a thesaurus is more flexible than that of a taxonomy. A taxonomy groups concepts into categories with a limited number of top concepts (or “top terms”). A concept which has no broader and no narrower concept relationships, sometimes called an “orphan,” is considered an error in a taxonomy. In a thesaurus, on the other hand, where an over-arching hierarchical structure is not required (although may exist) and associative relationships are included, it is OK to have a concept with no broader and no narrower relationships, but at least an associative relationship. Thus, the taxonomist does not always have to force new concept into an existing hierarchy which might not be ideal.

Software for thesaurus management

Software to support the development and maintenance of thesauri has also been available for some time. (Taxobank has a historic list, not updated since 2013.) There actually is no such thing as “taxonomy” management software, because the software used to create taxonomies is really “thesaurus” management software, and the added thesaurus features, such as associative relationships, are just not utilized when creating a simple taxonomy.

As taxonomies have become more popular than thesauri, the software vendors have reflected that by having a hierarchical display (instead of alphabetical) as the default, and by marketing their solutions for taxonomies and ontologies and de-emphasizing or omitting mention of thesauri. For example, the basic core module of the PoolParty Semantic suite is appropriately named Thesaurus Server, since you can easily create thesauri with it, but the default hierarchical display suggests the use for taxonomies, whereas the website's product page says it’s for “Enterprise Taxonomy and Ontology Management.”

Thesauri today

Thesaurus design principles are applicable to both thesauri and taxonomies. Therefore, thesauri continue to be taught in library science and information science degree programs, including courses on information architecture. The book Information Architecture for the Web and Beyond (Rosenfeld, Morville, and Arango)(aka the polar bear book, due to its cover design), even in its 4th edition of 2015, devotes 20 pages, nearly half the chapter “Thesauri, Controlled Vocabularies and Metadata,” to thesauri.

The main impediment to thesauri is that the most common implementations these days, variations of off-the-shelf content management systems (CMS), usually do not support features of thesauri. Associative relationships are rarely supported. Synonyms/nonpreferred terms may be only partially supported (such as in the tagging view but not in retrieval). Thus, we tend to see thesauri implemented only in custom (home-grown) end-user systems, such as those of publishers of information retrieval databases.

Information retrieval thesauri have been around for a long time, and perhaps that is also part of the problem in their acceptance today in business and industry. People may consider thesauri as some kind of legacy knowledge organization system that was more predominant when we only had printed systems, not digital systems. It’s true that thesauri are designed to be useful in print, but their design is also adaptable and relevant to digital implementations. They can also form part of a larger system of interlinked controlled vocabularies.

This brings us to the next topic, ontologies, which can link to thesauri. Next month’s blog post will address the different meanings of ontology.

Related Terms in Taxonomies and Thesauri

One of the benefits of a taxonomy is that there are relationships between the terms to support navigating to find the most suitable term. This could be the multi-level hierarchical browsing from broader terms down to more specific narrower terms. In a strict definition of a taxonomy, the only required type of relationship between terms is hierarchical. But sometimes it may be desirable to have relationships other than hierarchical.

ISO and ANSI/NISO standards for controlled vocabularies are very explicit on the criteria for hierarchical relationships between terms. The narrower term must be a specific type of, an instance of, or an integral part of its broader term, and it must be so in all circumstances, not just sometimes. If a pair terms seem as if they should be related, but their relationship does not meet the criteria for a hierarchical relationship, then they could have an associative relationship instead, which is also known as “related term” or abbreviated as RT. Examples include Schools as related to School busses, Computers related to Operating systems, and Business development related to Marketing

 

Those familiar with controlled vocabularies, know that the RT relationship is a standard feature of a thesaurus, whereas it is not common in taxonomies. However, the distinction between a taxonomy and a thesaurus can be blurred, and the kind of controlled vocabulary that is designed and implemented can have features of both, serving the needs of the users and the nature of the content and indexing. Therefore, taxonomists should have a good understanding of the associative relationship, in case the need arises and the system supports it.

The creation of an RT relationship is more subjective than the creation of hierarchical relationships. Even the standard ANSI/NISO Z39.19-2005 (r2010), in section 8.4 Associative Relationships admits "The associative relationship is the most difficult to define." The standard states that the relationship is created "on the grounds that it may suggest additional terms for use in indexing or retrieval." The fact that the relationship may be created but is not required in many circumstances leaves it up to the best judgment of the taxonomist.

The only required circumstance for the RT relationship (in a thesaurus or taxonomy that has associative relationships) is between two terms that share the same broader term and they have some overlapping meaning. Examples include Boats and Ships (sharing the broader term Vessels), or Tablets and eReaders (sharing the broader term Mobile devices), or Coats and Jackets (sharing the broader term Outerwear). But there would not be a related-term relationship between Coats and Mittens, even though they are both narrower terms of Outerwear, because they don’t have overlapping meaning.

More often, however, the RT relationship is created between terms with different broader terms or even from different hierarchies entirely. The ANSI/NISO Z39.19 standard provides guidance on this only to the extent of when the relationship may be created. Whether creating the relationship is a good idea or not is up to the taxonomist’s discretion and ultimately depends on what the taxonomist thinks would be helpful to most users.

Following are examples of possible RT relationships between pairs of terms:

Baseball RT Baseball players

Ventilation RT Fans

Bacterial infections RT Antibiotics

Appliance repair RT Appliances

Plastics RT Elasticity

Timber RT Wood products

Psychology RT Psychologists

Literature RT Books

There are different users of a taxonomy/thesaurus with different goals. Depending on what they are looking for, some users would welcome the guidance of a certain RT relationship, pointing them to a related term they had not considered but find helpful (such as E-commerce RT Online shopping); whereas other users are not interested in the related term and may find extra RT relationships getting in their way. The goal is to provide RT relationships that are probably relevant and helpful to the majority of users or “the average user,” while realistically not expecting to serve all users.

The following are examples of RT relationships that are not likely to be helpful to most users and thus better not be created:

Newspapers RT Advertising

Germany RT World War II

Athletics RT Doping

A good way to become more familiar with best practices for creating RT relationships is to browse published thesauri with these relationships. Thesauri that are available publicly to browse on the web include the ERIC (Educational Resources Information Center) Thesaurus, MeSH (Medical Subject Headings), UNESCO thesaurus, and the NASA thesaurus. These and others can be found on the American Society for Indexing’s website page OnlineThesauri and Authority Files. Note that related terms might be indicated as RT, Related concepts, or See also links.

Creating associative relationships is part of the creative work of taxonomists, but taxonomists must remember that serving the user is the primary goal.

Indexing vs. Thesaurus Creation

The activities of back-of-the-book indexing, document/digital asset indexing, and thesaurus/taxonomy creation all require similar skills, but each has its own unique requirements. Indeed a typical career path toward an accidental taxonomist is to first work as an indexer. You might think that the two kinds of indexing are similar to each other and thesaurus creation differs more, but having done all three, I can attest that back-of-the-book indexing and thesaurus/taxonomy creation are more similar to each other than the two kinds of indexing are.

What is indexing

In my previous blog post “Tagging vs. Indexing,” I explain that indexing involves designating descriptive terms or labels for what some content is about, and that these terms are organized into a browsable index.  There are two kinds of indexing:

1. “Closed indexing,” or back-of-the-book indexing, where the index is created based solely on concepts that the indexer identifies within the text of a single monograph. The index is created for that one monograph and then is finished ("closed").
2. “Open indexing”, or what has been called “database indexing,” for the indexing of articles, documents, content items, or digital assets, whereby the indexer pulls index terms from a controlled vocabulary or thesaurus and assigns them to multiple individual documents or digital assets. The set of content grows over time, and the same terms in the index will point to increasingly more documents over time. It is called “open” indexing, because the task is ongoing. The thesaurus helps ensure consistent indexing over time.

Both kinds of indexing require the skill of analyzing content to determine what concepts are important and deserve indexing. The biggest difference between back-of-the-book indexing and database indexing is that book indexing requires that the indexer additionally invent the index terms and not merely pull them off of a thesaurus.

What is a thesaurus

I use the designation thesaurus here, because I mean the type of taxonomy that features the full set of relationship types between its terms, with each term designating an unambiguous concept (noun or noun phrase). The relationship types are:

• Hierarchical (broader term/narrower term)
• Equivalence (use/used from “nonpreferred terms” or “synonyms”)
• Associative (related terms)

To best support manual indexing, the existence of all these different kinds of relationships help direct the indexers to the most appropriate terms to describe the content they are indexing. The same thesaurus, or parts of it, may be displayed to the end-users to help guide them to find the most appropriate terms to describe the idea about which they are searching for information. The thesaurus thus not only standardizes the language for the concepts, but also provides a guiding structure.|

How they are related

Open/database indexing and thesaurus creation are obviously related, because the thesaurus is used to support this kind of indexing. In an organization which is involved in such indexing, it is not unusual for former indexers to become editors of the thesaurus, since they are already very familiar with it and understand the needs of the indexer-users.

Closed/book indexing and thesaurus creation are related, because they both involve the development of original terms and relationships between them.

Thesaurus and book index similarities and differences

Thesauri and back-of-the-book indexes both have what can be called multiple points of entry. In a book index these can be either See cross-references or “double-posts," whereby additional variant terms or synonyms are included in the index, and they all point to the same set of page numbers. In a thesaurus, this is the equivalence relationships, where nonpreferred terms or synonyms point to the preferred terms (Use/UF). The difference is that a thesaurus distinguishes between the preferred and nonpreferred terms, whereby double-posts in a book index are all of equal standing and none is ”preferred.”

Thesauri and back-of-the-book indexes both have hierarchical structure among their terms. In a thesaurus there are narrower terms to a broader term (BT/NT). In an index, there are subentries indented under a main entry. However, these hierarchies are not identical. In a thesaurus, narrower terms must be generic types, instances or integral parts of the broader term. In a book index, subentries are any aspect of the main entry or merely another concept in combination. In fact, an indexer may choose to switch the main entry and subentry (the subentry becoming a main entry and the main entry becoming its subentry) with no problems. Don’t try to do that in a thesaurus or taxonomy!

Finally, thesauri and back-of-the-book indexes both have indications of related concepts. Thesauri have the associative relationship called Related Term (RT), and book indexes have See also cross-references. While in general these function the same, the rules for thesauri are stricter. If the “related” terms are really hierarchical, then they must have the hierarchical relationship instead. In a book index, it is acceptable to have a See also between two terms where one is actually broader in meaning to the other.

I will be giving a presentation on this in greater detail at the annual conference of the American Society for Indexing, on April 30, 2015, in Seattle, WA.

From Taxonomies to Ontologies: Customized and Semantic Relationships

At this year’s Taxonomy Boot Camp conference, I was invited to present on the panel giving 5-minute “Pecha Kucha” lightning talks, for which this year’s theme was ontology. Just as there are different understandings and usages of “taxonomy,” so are there different understandings and usages of “ontology.”  You can come to if from different angles. If you come to ontologies from the experience of taxonomies and the field of information management, then, most simply, an ontology is a more complex type of taxonomy that contains richer information.
  
In my brief presentation, “From Accidental Taxonomist to Accidental Ontologist,” I summed up the differences between taxonomies and ontologies as follows:

1.     Relationships: Taxonomies have hierarchical and sometimes a simple “related term” associative, but ontologies have semantic relationships, which are custom-created.
2.     Term Attributes: Taxonomies generally don’t have term attributes, but ontologies do.
3.     Term Classes: Taxonomies generally don’t have classes for terms, unless you consider facets as classes, but ontologies do.
4.     Guidelines/Standards: Taxonomies should follow the ANSI/NISO Z39.19 (2005) or ISO 25964, whereas ontologies are expected to follow the Web Ontology Language (OWL) guidelines and make use of the Resource Description Framework (RDF).
5.     Purposes: Taxonomies  support indexing/tagging, categorization, and/or classification of content, and in turn information findability and retrieval. The primary purpose of an ontology is to describe a domain of knowledge, and support of indexing/tagging, categorization, classification, findability, and retrieval can be secondary.
6.     Tools: Some software supports the creation of only taxonomies, some software is for ontologies, and some software can do both quite well.  Additionally, some taxonomy/thesaurus software can support most, if not all, features of ontologies.

Coming at ontologies from taxonomies, the biggest distinguishing feature of ontologies is the semantic nature of the relationships.

In a taxonomy or thesaurus, you may have generic relationships, such as:

     Automobile industry  RT (related term) Cars, and
     Cars RT (related term) Automobile industry

     Ford Motor Company NT (narrower term) Lincoln Division, and
     Lincoln Division BT (broader term) Ford Motor Company

In an ontology, you may have customized, semantic relationships, such as:

     Automobile industry MAN (manufactures) Cars,  and
     Cars IND (manufactured by the industry) Automobile industry

     Ford Motor Company SUB (has subsidiary or division) Lincoln Division,  and
     Lincoln Division PAR (has parent) Ford Motor Company

If you can customize the relationships, does this change a taxonomy into a ontology? No. Customized relationships are just one feature of an ontology, although perhaps the most important feature. In my online course on taxonomies, although I don’t teach how to create ontologies, I do provide a lesson on customized/semantic relationships. It is often desirable to create a more complex taxonomy without necessarily meeting all the requirements of an ontology.

Furthermore, a customized relationship might not be fully semantic. In the example above, the second set of relationships are customized, because they are designated by the ontologist for the particular case. The relationships are also “semantic” because they contain specific meaning. (Semantic means “has meaning.”) It is possible to customize relationships while still not making them fully semantic. You may decide to simply rename the standard relationships for your particular application and audience. For example, you might rename broader term (BT)/narrower term (NT) as “parent/child,” or rename Related Term as “see also.” If your taxonomy/thesaurus software is more sophisticated, it will allow you to specify any number of customized relationships, and thus you can add more nuances of meaning.

A key component of truly semantic relationships as expected in ontologies is the ability to create directional relationships that are distinct in each direction, with reciprocity. Most of these semantic relationships will be variants of  “related term” (RT), rather than variants of the hierarchical relationship. The generic RT relationship, however, is singularly bidirectional. If you simply customized it by renaming it, it would have to be the same in both directions, such has “has partner.” To create a semantic relationship pair, such as MAN (manufactures) and IND (manufactured by the industry), you need a tool that supports ontological relationships and not just “customized” relationships.

If your tool supports customized relationships but not the ability to create distinct pairs of directional relationships that are associative rather than hierarchical, the results cans still be very useful. You may have a “near ontology” if not a strictly defined ontology. For example, you could rename the singular “related term” (RT) as “Manufacturer-Product” with an abbreviation  such as  MAN-PRO (Credit to Alice Redmond-Neal of Access Innovations, Inc. for the example). Thus, the relationship is the same in either direction:

     Automobile industry MAN-PRO Cars,  and
     Cars MAN-PRO Automobile industry

It is not completely semantic, with the directional details missing, but this may be good enough for your purposes. After all, it should be obvious which is the manufacturer and which is the product. Therefore,  taxonomy/thesaurus software that provides most, if not all, features of an ontology may be sufficient, too.

What matters is serving your needs. Rather than calling it an “ontology” when it does not meet all the definitions of an ontology (and causing confusion or disagreement), it may be safer to say your sophisticated taxonomy “has features of an ontology.”