Skip to main content

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.
Labels:

Comments

Post a Comment

Popular Posts

Create Your Own Social Networking Site

Create Your Own Social Networking Site JCOW: Ethical Hacking Top 10 reasons to choose Jcow:- 1. Handle more traffic - Clean codes and Dynamic caching can lower the CPU load and  speed up your website. 2 Make your site more interactive - Well designed Jcow applications help you members to connect and communicate with others more effectively. 3 Add questions to the Registration Form - You can add new member fields, which will be displayed to the registration form, profile form, and the member browsing form. 4 Easily share stuff - Within the AJAX sharing Box, your members can publish status,  photos, videos, and blogs. 5 Customize and Extend your Jcow Network - A Jcow network consists of core apps(like "Friends" and "Messages") and optional apps(like "Blogs" and ""Videos"). You can enable/disable optional apps. You can also develop your own apps. 6 Every profile could be Unique - Members can customize their own profile theme and  add music play...
Post a Comment
Read more

The Problem of Abstraction in Definitions of Data Objects

I think there is a major problem in not being able to understand and work with different levels of abstraction.  By "abstraction" in this sense I mean one concept system that somehow describes or defines (not merely relates to) another concept system.  I think this is a big problem for definitions in data models. Let us take an example in a retail business such as mortgage banking: Customer Name.  Customer Name exists in the business.  They use it all the time.  Maybe it is sometimes called Borrower Name, but the concept is the same.  This is the Level 1 abstraction. Now let us think of data values in a column in a table that holds Customer Name.  These data values are stored as a code of 1's and 0's.  Of course these bits are rendered into something we can read.  However, this is not the same as the Customer Name in the business.  I worked for a place where they prefixed the name of anyone who had recently left with "ZZZ"....
Post a Comment
Read more

The Humpty-Dumpty Principle in Definitions

In dealing with empty concepts, we came across the issue that if somebody uses a term that potentially has an unintelligible definition, they are likely to defend themselves by quickly making up some kind of definition.   I strongly suspect that in such cases, the usage of the term will be inconsistent with the definition.  Which brings us to Humpty-Dumpty. Lewis Carroll (Rev. Charles Lutwidge Dodgson) is best known for his children's' books Alice's Adventures in Wonderland and Through the Looking Glass .  It is in the latter that Humpty Dumpty - an argumentative egg perched on a wall has the following exchange with Alice: 'And only one for birthday presents, you know. There's glory for you!' `I don't know what you mean by "glory",' Alice said. Humpty Dumpty smiled contemptuously. `Of course you don't -- till I tell you. I meant "there's a nice knock-down argument for you!"' `But "glory" doesn't mean "...
Post a Comment
Read more