Interpretation: Clues from How Humans Interpret Unstructured Information

The most common dictionary definitions of interpret include "to understand" or "to explain the meaning of." As with many dictionary definitions, this gets us only so far.

Interpret

To determine the intended meaning of something.

We have a good idea of what the word interpret means. We talk about "interpreting our dreams," "interpreting financial statements," and "interpreting the law." We also talk about an "interpreter" as someone who converts one language to another. Computer science has an alternative meaning for interpreter: an architecture that compiles and executes program code one line at a time instead of compiling an entire program at once.

A Model of Interpretation

The following is a simplified description of how humans interpret their world. As we go through the model, we will describe how human-designed business applications are doing something similar. Interpretation involves the following:

1. Perception

2. Initial, low-level classification of perception

3. Synthesis with things previously perceived and classified

4. Hypothesis of higher-level classification

5. Prediction of further perception

6. Testing to confirm or deny the perception

These six aspects fit together as shown in Figure 7.1.

Figure 7.1: A model of interpretation.

Business systems do far more interpretation than we think they do. Once we are clear about what this is and how it works, we are much more likely to recognize system processes that are interpreting their environment and how this analogy could help us fine-tune this process.

Context is included in Figure 7.1 to represent that it is the act of establishing context that determines what we will initially perceive, and also what aspects of our body of knowledge we are likely to bring to bear on a perceptual situation. One possible interpretation (not shown here) is one that changes context. Within a context the process is perception.

Perception

Without perception, there is nothing to interpret. Perception is any access of information. Perception need not be of the external environment; we also can perceive internal states (a human may perceive pain or discomfort, an application may "perceive" information it has already obtained). A business system begins this perception process when a customer approaches a knowledge worker at his or her desk, or a user visits a Web site.

Initial Classification

Raw perceived data is not interpreted. First, we make some sort of initial classification of the perception. With voice, for example, we classify the sounds we hear into phonemes, and combine the phonemes into words. Much has been written about this low-level classification process. Humans can discern aurally about 200 different phonemes (language sounds). In the first 2 years of life, a human is exposed to about 40 phonemes that are the building blocks of the language and culture the person was born into.

The application equivalent is the initial parsing of information. A business system separates events into transactions and then into fields within records or screens. Note that in our business process, forms and screens dictate the quanta that we perceive as business events. We make initial classifications, and we then challenge them later.

In either case, what is happening is that the "interpreter" (in this case, the person who is interpreting) is chunking (grouping it into larger units to deal with) the perceived input and making some rudimentary classifications.

Synthesis

The least understood part of this process, from a human cognition standpoint, is how each new bit of data is synthesized in with what is "already known." Our body of preexisting knowledge is available on many different levels. The perception of moving color is synthesized with other information to conclude that it is an object. We synthesize it further with additional stored information, and we conclude that it is a car.

To date the application side is far more mechanistic. A new token is acquired and "synthesized" against a grammar or a schema in order for it to fit in. Where the two seem to be greatly different is that the body of knowledge of most applications is not dynamic.

Hypothesis

Using perception, classification, and synthesis, the mind, and occasionally an application system, comes up with a hypothesis: for example, "That is a car moving toward me rapidly," or, in the case of a business application, "This patient has valid medical insurance."

At the language level, as we begin to hear or read a sentence, we form a hypothesis about the meaning of the whole sentence. If the sentence begins "Time flies like …" we might predict that the sentence will end with "an arrow" or some other similar analogy of time moving rapidly in a physical direction. If the sentence ends with "a banana," we first try the analogy of something "flying like a banana" but then go back and recheck our initial categorizations. We might decide that "flies" must be a noun (the insect) and "time" an adjective. There must be a new species of fly that we haven't heard of called the "time fly" that, in common with most flies, is attracted to fruit.

Once we increase our level of abstraction from the lowest-level sensory input, we begin making subjective assignments of things and events into categories. As we'll discuss later, these categories, especially when validated, can be extremely useful, but we need to keep in mind that categories aren't real things. Categories are concepts that we create to help us deal with a complex world. We must remember that they have some level of veracity (probable truth). In other words, when we classify, we might be making a wrong assignment to the category, or we might have a category that is not useful.

Prediction

The hypothesis leads to some predictions. If a car is moving toward me at high speed, I can predict that within 4 seconds it will either pass me or hit me. I can predict that over the next 4 seconds the image will grow larger and the sound louder. At the nearest point I will either feel the car strike me, or feel the wind from the car passing nearby.

In the case of an application system, we predict that certain other information will be available and meet our preconceived ideas about validity. We predict that the patient will have an insurance card with a plan name and number, and that if we call the number on the card, we will get an authorization number.

Beyond data gathering, we make many other predictions. For example, in an inventory system, we predict that we will run out of widget number 27 within 2 weeks at our current level of consumption. We predict that the project will run over its deadline by 2 weeks, based on precedence and progress to date.

Testing

After we make a prediction, we test it. Most tests are validating. As the car approaches, we take several more readings. In most cases, each confirms our hypothesis: This is in fact a car, and it is moving in our general direction at high speed.

The patient did have insurance; the insurance company did confirm it. If we get contradictory information (the insurance company is not in our system, the number does not match the patient's name, etc.), we usually start by reexamining the most recent perception; for example, "Did I type in that number correctly?"

Eventually we will challenge either the hypothesis ("Maybe this person doesn't have insurance") or the body of knowledge ("Am I logged into the right database?" "Did they process the updates to the beneficiary lists at the end of the month?" etc.).

Sometimes the test comes much later. Unfortunately, with delayed tests, we usually forget to close the loop. By the time the project completes, and either does or does not hit our predictions, we have lost track of exactly what there was about our hypotheses that led to an incorrect prediction. This is potentially valuable information that is almost completely ignored in contemporary applications.

For example, in project management applications, people routinely miss their scheduled completion dates. However, systems rarely close the loop and find out what it was about their assumptions, or perceptions, that led to the disconnect between the predicted reality and what actually occurred. Was there a difference in the amount of work? The productivity of the individual? The availability of resources? These questions, if answered, could drastically improve the effectiveness of a project management application and enable it to learn from past mistakes.