Services
Download print versionWord meanings are ambiguous. Different departments have different interpretations and perspectives. How do you resolve various points of view with regard to your taxonomy development?
The key is to understand ways to map semantic relationships. How does engineering view their terms and categories versus the way sales and marketing may view the same terms? A "specification" document may have very different meanings to each of these groups.
In fact, terms that seem to have simple and obvious meanings can cause a great deal of argument and disagreement. I was once in a meeting where the meaning of "knowledge base" was argued over for almost an hour. We soon found out that the people who were arguing had two completely different concepts in mind and therefore could not come to agreement. On another occasion, I heard several different terms used to describe a marketing function. After questioning how many departments we were talking about, the client said "Oh, just one. We call it lots of different things".
One of the reasons that taxonomy development is so difficult is that people have a hard time agreeing on meanings of terms. They have different concepts that are appropriate to their expertise, job tasks and focus.
Differing perspectives make it difficult to create a "galactic taxonomy" - one that satisfies all points of view. The key is to understand contexts of terminology. When the context is understood, a term used in marketing can have a different meaning when used in an engineering context.
Associative Relation Types
The key is to understand conceptual relationships and to map these based on perspectives and contexts.
Equivalence relationships are synonyms - abbreviations, misspellings, other terms used, internal names, etc.
Hierarchical relationships are the classic definition of a taxonomy - parent/child membership.
Associative relationships are where meaning, nuance and perspective can be defined. The definition of the associative relationship is the conceptual way in which terms are related. In a thesaurus, this is a "see also" entry. But "see also" is very broad. Why should I see this other term? It is not equivalent and is not a member of a broader representation. Software is related to hardware, but in what way? Perhaps software terms are related to the hardware on which that software runs.
What about languages and regions? A language is not synonymous with a region and is not a type of region (not equivalent and not hierarchical). There is an associative relationship of "language spoken in region".
The point is that we can have two lists of terms that are related and a way of connecting those terms.
Semantic Maps
The diagram below illustrates Equivalence, Hierarchical and Associative relationship types between terms.
By labeling associative relation types in the context of the relationship, we can map multiple taxonomies.
If we want to select a term in a specific context, we can pull that term based on how the associative relationship is defined.
For example, suppose we have a number of controlled vocabularies:
Just managing these term lists can be challenging, but what about when there are relationships between sets of terms? There may be more than one set of relationships. When terms are updated, the relationships, which may be somewhat complex, also have to be updated.
We can define and map relationships between these taxonomies through custom associative relationship types. Here are some ways of thinking about these relationships:
We don’t necessarily map every possible term relationship, but just the ones that make sense given our goals and the business application. In this case, some term relationships don’t really make sense – for example Language to Region. This is because there may be multiple languages spoken in a region.
These terms have multiple contexts. There are many relationships between "brand" and other terms. If these are all separately managed lists, changes and updates are very difficult and expensive to maintain.
By thinking of the context of terms as additional metadata, we can pull from a larger list of terms in a specific context. For example, a brand can be in three contexts: a global list of brands, brands sold in a location and related brands. We can have these in three separate vocabularies or we can map the contexts and pull a subset of terms from the master list of brands by tagging the metadata with that context.
There is metadata applied to the term “Ace” so that it can appear in three different views of a brand vocabulary – one for each region. The metadata is the relationship of the term to the global brand list.
If we want to allow a user in the Europe region to see a drop down that only includes the values relevant to them – the brands available in their region – then we can query the table to pull those values.
We create the new custom associative relationship types to describe the contexts and then correlate them with our terms.
If the name changes or we add new values to the Global Brand list, as long as we keep relationships updated, we will automatically update the region specific lists. A subject matter expert – perhaps the global brand manager – can have responsibility for the overall list and perhaps a regional marketing manager can decide if a particular brand should be sold in a region. (This example came from public info on the P&G website.)
Integration with Other Systems
There are a number of ways that we can practically apply this. A simple way to use this is to publish the agreed upon taxonomy as a standard and allow users to view and apply the terms as the create applications or tag documents. Or we can publish the taxo terms as XML and allow systems that import XML to consume the terms. We can also expose the taxo as a web service. Or we can code a deeper level of integration so that terms are pushed out to consuming systems (perhaps even retagging documents).
The most important piece is to formalize the process of term development and management and share those results (even if by spreadsheet) with users who need to apply metadata consistently.
For more info on managing taxonomies and integrating metadata across applications, contact us.
© 2008 Earley & Associates, Inc.