No...     You don't need to be a trained logician to build a problem-area model with Pro/3. Pro/3 provides a natural language-oriented and easy-to-use interface to the under-lying logical concepts based on PROLOG-type inference logic enhanced with statistical computations, certainty rules and entity-relationship data modeling. 

The most important logical foundation of Pro/3 is PROLOG  (PROgramming in LOGic - a programming language defined by Colmerauer and Roussel in the early 1970s). PROLOG uses an inference rule known as resolution (used in the inference shown to the left). 

 

How is a problem-area model built with Pro/3?

Problem-solving rarely follows a pre-defined and linear path. The initially-set course is adjusted as insight in the problem area is gained or obstacles encountered. A promising approach might turn out to be a blind alley - or a better path towards the summit is suddenly discovered. Two steps forward and one back. That's the pattern of progress in problem solving.

Facts - rules - derived facts - more rules - more derived facts - .... - and eventually conclusion(s). That's the way problem solving is done with Pro/3. So it starts with facts. A fact is a sentence in Pro/3 terminology.

 

Step 1 - Defining the Sentence Model

Entering sentences cannot be carried out without prior preparation. This preparation is called sentence modeling, and involves defining the types of predicates, subjects and objects from which sentences can be built. Pro/3 can handle two main classes of sentences, that is, subject-predicate sentences and subject-predicate-object sentences. This imposes some limitations with respect to the sophistication of the natural language capabilities of Pro/3, however this is not very important for the overall purpose of problem solving.

Subjects and objects are actually the same type of objects - called entity types in Pro/3. An entity type has (besides a name) a fixed (and ordered) set of data element types. Predicate types may or may not have data element types. Predicates used in subject-predicate sentences are called unary, while predicates in subject-predicate-object sentences are called binary.

 

Example

Lets assumed we have defined three predicate types is registered (unary) and belongs to (binary), and the two entity types car and person. Pro/3 can recognize six sentence types from this sentence model (some of them don't make much sense semantically):

  • car is registered
  • person is registered
  • car belongs to person
  • person belongs to car
  • car belongs to car
  • person belongs person

Note that a predicate type always is unary or always binary (it cannot be unary in one sentence and binary in another). An entity type have the same data element types (in the same order) in all sentences.

Step 1 actually consists of two steps - the preparation of the sentence model and the preparation of the terminology (e.g. that we decide to call a car for car, rather than for example a vehicle or an automobile). Sentence modeling and the recording of a terminology are usually carried simultaneously by using Pro/3's predefined windows for sentence model data entry (the Structure-menu). Otherwise, the preparation of the sentence model comes after the preparation of the terminology. 

Step 2 - Entering Sentences
After the first-cut version of the sentence model has been defined, then the knowledge base (KB) is ready for entering of facts. There are several choices with regards to the practical aspects of this. Sentences can be entered as texts via the editor (in one of several possible formats), by using a sentence window (or directly from MS Excel with DDE):
sentence window (one sentence at a time)
NL ("natural language") text

One terminological note. Country names are shown in quotes while currency codes are not. This is so because currency codes (in this model) have been predefined as identifiers (defined as such in the terminology), while the country names simply are strings (for which no prior definition has been done). Note in the window under the difference in the internal (PR) representation of strings and identifiers.
PR ("PROLOG") text
delimited format

Using data (facts/sentences) from the web

The web is usually the best place to look for facts, whether these are weather statistics, stock prices or economic indicators. Pro/3 has a utility to translate HTML-formatted files to a format which can be entered into the KB (delimited text format is normally the best choice).

Step 3 - Defining Sentence Rules
It is now time to get some returns from the effort of entering sentences. Sentence rules specify how sentences are derived from other sentences. These derived sentences can be seen as stepping stones on the path to the sentences which ultimately represent the conclusions of the problem-solving exercise. Let's assume that two sets of sentences have been entered, that is, person lives in city sentences and city is located in country, and that we need to know which country a person lives in. Rather than entering this as a new set of sentences, we use a rule:

Step 3b - Enhancing the Sentence Model

No additional sentence modeling is required to enter the person lives in country rule, since both the predicate type and the entity type in the conclusion are known (i.e. they are already used in the sentences in the condition of the rule). This is often not the case, and consequently, new sentence model entities are added as required when rules are defined.
The Rent-a-Car KB involves a typical stepping-stone type of sentence derivation which ultimately derives the net present value of two business scenarios. A portion of this is shown in the following dependency graph:
The CASHFLOW|3-rule derives net cash flows from cash flows, the CASHFLOW|1-rule derives net discounted cash flows from the net cash flows, and finally, the CASHFLOW|2-rule derives net present values from the net discounted cash flows:

Step 3c - Defining Functions
Functions can be used to model sentence derivations which cannot be explicitly represented in sentence rules. Functions should generally be regarded as a last resort approach, since they, like traditional computer programs, are more prone to bugs and interpretation problems than derivation logic directly represented in sentence rules. Note that Pro/3 comes with a set of built-in functions which can be used with less caution.

Step 4 (optional) - Defining Certainty Rules

The problem-area model concepts presented so far have dealt with "crisp logic", somewhat simplistically:  logic where expressions are either true or false. It can be beneficial in some problem-areas also to use degrees of true or false, i.e. to have a measure for expressions such as "quite true", "absolutely false", "uncertain" etc.

Pro/3 uses certainty factors for modeling degrees of certainty. Certainty factors are computed by networks of certainty rules. A certainty rule is "called" from a sentence rule (and/or from other certainty rules), and through various processing features, returns a certainty factor. Certainty rules include 

  • bayesian rules
  • AND, OR and NOT rules
  • switch rules
  • map rules
  • data rules

Certainty rules are typically used to draw inferences from the KB i.e. by "querying" sentences derived from sentence rules, or by questioning the KE interactively during the processing of a query (or sentence derivation).