Definitions Are Not Enough

Occasionally a project will create a glossary to define the terms and how they will be used in a particular system. This is a useful start, but it doesn't go nearly far enough. First, the glossary may suffer from "design time" artifacts. A design time artifact is one that is used while the system is being designed, but generally is ignored by users and maintainers of the system. Second, the glossary may suffer because it is created by inexperienced workers. Third, the glossary may suffer for the same reason that more general-purpose glossaries fall short.

Glossaries and vocabularies are not designed to distinguish or group closely related concepts; they are designed to "define." As a result, most are full of ambiguity and overlap. In effect, this leaves much of the defining up to the reader.

Let's look at an example. What is a cash commodity?

Cash commodity

Commodity that is owned as the result of completed contract and must be accepted upon delivery. Contrasts with futures contracts, which are not completed until a specified future date.^[12]

I took this definition completely at random. It is better than most, especially in that it makes the distinction between a closely related concept (futures contracts) and this one. However, it also points out most of the problems with relying on vocabulary alone.

First, just what is "cash commodity?" I'm guessing it is real physical stuff, such as a truckload of barley or lumber. It doesn't sound like it is cash or has anything to do with cash, except that you presumably had to pay some cash to get this stuff. If this is the case, it is only tangentially related to a futures contract, which is a contract, and, although it has a reference to a commodity, it is, strictly speaking, just a contract.

But the interesting questions come when you start asking yourself: Do either or both of these represent an obligation? Is it the same kind of obligation? With the cash commodity it is likely that the obligation is already discharged. Or is there another way to indicate whether it is or is not an obligation?

We could chalk this misunderstanding up to my personal ignorance of commodity trading lingo, except for the following:

• I'm going to guess that more than 95% of the readers of this book also do not understand what is meant by "cash commodity," even given the definition quoted earlier.

• Even experts on a given subject disagree about nuances of definitions.

• We have an expectation, or a hope, that future agent-based or Semantic Web–based systems will somehow be able to make inferences about things like this in the future, but if we can do no better than define our terms as definitions in glossaries, we won't get there.

Clearly, underpinning most of our business systems, we need some better way of defining what we mean than just vocabularies and glossaries.

^[12]John Downes and Jordan Elliot Goodman, Dictionary of Finance and Investment Terms, New York: Barron's Educational Series, Inc., 1998, p 85.