Should A Technical Term Have Only One Definition?

There are far more concepts than there are terms to describe them.  This leads to the use of a single term to signify more than one concept.  Such terms are known as homonyms.  For instance, the term "table" is used in conversations in business about whether or not to discuss a topic.  Someone may say "Let's table that".  Unfortunately, some people think this means "Let's take that topic off the table", while others think it means "Let's put that on the table".  The differences in interpretation are geographic, with the British thinking it means one thing and the Americans another.  It makes for pretty interesting conference calls on transatlantic projects.  I have managed to forget which side thinks of it which way.

So homonyms exist, and we have to deal with them.  But what about technicial terms?  Technical terms are specific to very specialized domains.  It might be thought that the narrowness of the domain would itself guarantee that a technical term would have only one definition.  But there is no guarantee of this.  An example I often come across is "data model" in the realm of data management.  To some this means an artifact for the design of a database produced by utilizing a standard symbology.  To others it means the actual design of a physical database.  The first means an artifact produced by a tool like ERwin.  The second means the underlying design of an actual physical database, and certainly not a design artifact.

This is very confusing, and can cause a lot of problems in communication.  Working with technical language is very difficult to begin with.  Having technical terms with more than one definition makes things much worse.

If it is possible to set up a technical vocabulary, or to reform a technical vocabulary, then it is possible to ensure that one technical term has one definition.  This is part of the work that terminologists do.  

Yet, even if a technical vocabulary is set up by terminologists, they cannot control its usage.  If a technical term starts to have marketing value it will be used to signify things that may be the same as the original concept, or a different concept, or no concept at all.  We call this "hype".  If a general community cannot fully understand the concept signified by a technical term, they will use the term to mean something they think they understand, as in the example of "data model" above.

To answer the question originally posed, a technical term should only have one definition, at least within a particular technical domain.  However, we have no way to ensure a technical term will always signify the same concept.  

So what is the conclusion?  If we want to master technical terms we need to understand what they are intended to signify, and be alert to detecting when they are used to signify other concepts.  A big piece of this is having a glossary of terms with adequate techncial definitions.

One Term, Many Meanings - Why Are We Surprised?

David Eddy kindly supplied me with the following military tale:

A true story heard around the Pentagon goes like this:

One reason the services have trouble operating jointly is that they don't speak the same language.

"secure a building" has been found to have the following meanings...

• Navy would turn off the lights and lock the doors.
• Army would occupy the building so no one could enter. 
• Marines would assault the building, capture it, and defend it with suppressive fire and close combat. 
• Air Force, on the other hand, would take out a three-year lease with an option to buy.

I think that we can all appreciate the humor in this, but must recognize that there is something deep and important about it.  But what is the moral in this tale?

The story shows that "secure a building" means different things to four different groups.  In each case the term refers to a different concept.  And in each case the concept is clearly defined.  The concepts are all very distinct - there is no chance of confusing them.

However, the four groups are all part of the same overall organization - the Armed Forces of the United States.  It is a common assumption that one organization is a monolithic semantic community.   The reality is that enterprises are often mosaics of different subcultures, who each see the enterprise through a different ontology.  At least, this is my observation.  I would like to find some research material on it, rather than anecdotes like the one quoted above.

The view that that enterprises are mosaics of subcultures also goes against the idea that there is a single data model - a "single reality", or a "single version of the truth" - that must underlie every enterprise.

Saying that the services "don't speak the same language" is a telling statement.  Rather than suggest that each service has its own view of the world - its own ontology - the fundamental difference is attributed to language.  This brings us back to the idea of the primacy of language over conception, and Wittgenstein's notion that language is the mirror of reality.  I believe these views are invalid, and that we need to "make our ideas clear" as Peirce said, and that language can as easily trick us as inform us. 

Perhaps the lesson for an analyst is not to be surprised when the same term is used to mean different things in the same enterprise.  Indeed, the analyst should be on guard for it when technical or unusual terms are used.  Homonyms can also indicate the existence of different concept systems, or ontologies.