Common vs. Technical Terms in Definitions and Some New Definition Rules

A good deal of work in dealing with definitions in information management is done by analysts, and when I have been doing analytical work I have been struck by the need to capture Technical Terms.  Particular business areas always seem to have their own technical jargon, as does all of IT.  However, in capturing the concepts that lie behind these terms there is always a challenge about what terms to use in their definitions.

It is an old rule that high quality definitions should not use terms as obscure as the term being defined.  This is negative advice - telling us what not to do.   But what should we do?  I suppose that the best approach would be to use Common Terms.  A Common Term is one used in everyday discourse, and for which there is a well-know definition.   I agree that it is a noble goal to use only Common Terms in a definition of a Technical Term, and we should make every effort to do this.

However, can I really define something like "Mortgage-Backed Security" only by using Common Terms?  Campbell Harvey's Hypertextual Glossary defines "Mortgage-backed Securities" as:

Securities backed by a pool of mortgage loans [http://www.duke.edu/~charvey/Classes/wpg/bfglosm.htm]

But in this case, "pool" is not a Common Term, meaning a body of water or a swimming pool.  It is actually a Technical Term which is further defined by Prof. Harvey as:

In capital budgeting, the concept that investment projects are financed out of a pool of bonds, preferred stock, and common stock, and a weighted-average cost of capital must be used to calculate investment returns. In insurance, a group of insurers who share premiums and losses in order to spread risk. In investments, the combination of funds for the benefit of a common project, or a group of investors who use their combined influence to manipulate prices

Having developed quite a lot of securitization software in my time I would not define "pool"  that way, but as:

a set of mortgages with common characteristics that act as collateral for debt instruments 

That definition could probably stand improvement too, but let us get back to our main point.  "Pool" seems to be a Common Term but is really a Technical Term.  Yet we have no way of recognizing it is a Technical Term.  Actually, to be fair, in Prof. Harvey's Glossary we can infer it is a Technical Term because it is hyperlinked to the above definition (which is inadequate to define "pool" in the context of "Mortgage-Backed Security")

Prof. Harvey's definition of "Mortgage-backed Securities" also refers to "mortgage loans".  You could argue that this is a Common Term, but you could also argue that it is a Technical Term in the very broad area of finance, which is a much broader area than Mortgage Securitization.  This is interesting as it implies that there are vocabularies for specialized areas which are subspecies of less specialized areas.  It would seem to be helpful to use Technical Terms from a more general specialized area in definitions of terms that exist within a more specialized area.  After all, the more general specialized areas should be more widely known, so more people will understand these concepts.  But if somebody does not understand a term from a more general specialized area it should be easy for them to find understand its definition.

From this discussion we can derive some rules of what terms to use in a definition:

1. Always try to use Common Terms in definitions
2. If a Technical Term has to be used, try to use a Technical Term from a vocabulary that covers a more general area than the area to which the concept being defined belongs
3. Always try to use a Technical Term from the most general area above the area to which the concept being defined belongs 
4. Only as a last resort should a definition contain a Technical Term that is specific to the area to which the concept being defined belongs
5. Do not use Technical Terms from a more specialized area than that to which the concept being defined belongs

This is interesting as it implies we will always need generalization hierarchies to do definitions well if we adopt the above rules.  Of course, the Tree of Porphyry has been around for many centuries to support the old formula of Definition = Superordinate Genus + Specific Difference.  However, I am discussing Descriptive Definitions rather than Essential Definitions here, and it is Essential Definitions to which the Tree of Porphyry and the old formula apply.  So  it is interesting to see that there are additional reasons for having a generalization hierarchy.