Pro/3 is a system for processing knowledge, and Pro/3 deals with two main categories of knowledge - facts and rules. The purpose of this page is to look at the concept of facts more closely.
First of all - where do facts and rules come from? Facts and rules come from a knowledge engineer (KE for short), who either is an expert in the area of interest, or has access to such an expert. The KE formulates the knowledge so that Pro/3 can make use of it, and make use of it in a way that makes the system produce something useful. This means that he or she also needs to know Pro/3 - its knowledge representation concepts, its inference methods and the practical facilities included in the system.

What is a fact?
A fact in Pro/3 is called a sentence, and consistent with that, a fact can be expressed as a natural language sentence. Two types of natural language sentences correspond to Pro/3 facts. These are (i) sentences with a subject and a predicate and (ii) sentences with a subject, an object and a predicate. 

Facts are either asserted (entered) by the KE, or concluded (derived) from other facts by rules (sentence rules). 
The examples to the right are all sentences which can be recognized by Pro/3.

Subjects are shown in blue, objects are green/italics, while predicates are shown in red/bold.

 the exchange rate with currency GBP and per US $ rate 0.56 is current ! 
the bike with model "RSV Mille R" has UK specifications with cc 998, bhp 113, engine type 4 - stroke, cylinders 2, tank 145, weight 0, consumption 33.0 and top speed 167! 
the manufacturer with name Kawasaki makes the bike with model "Ninja ZX-7R" ! 
the retail price with price 6,500 and currency GBP is published for the bike with model "M900 Monster Dark" with year 2001! 
An essential aspect of a fact is that it does not contain variables.

 

ENTITY TYPES

Subject and objects are called entities in Pro/3. An entity belongs to an entity type. Entity types in the above examples are exchange rate, bike, manufacturer and retail price. Entity types consist of a fixed number of one or more data element types. bike and manufacturer have one data element type (model and respectively), exchange rate and retail price have two (currency and per US$ rate; price and currency). Data elements are actual values of data element types (GBP, 0.56, "RSV Mille R" etc).

Note that the set of data element types for an entity type always it is the same, e.g. a retail price-entity will always have a price and currency whenever it occurs in a sentence in Pro/3 (e.g. the sentence the retail price with price 6,500 and currency GBP is published for the bike with model "M900 Monster Dark" with year 2001 is invalid since the currency data element is missing from retail price).

 

DATA ELEMENT TYPES

Data element types are open sets of values (data elements) belonging to certain subsets of values such as strings, integers, numbers, dates and many other.  The price data element type is an integer, model is a string (note the quotes), while name is an identifier (no quotes). Note that the same data element type can be used in different entity types (in the examples, currency is used both in the exchange rate and retail price entity types).

 

PREDICATE TYPES

Predicate types are either unary or binary. Unary predicate types can only be used in subject-predicate sentences, while binary can be used only in subject-predicate-object sentences. The makes and is published for predicate types in the examples are binary, while is current and has UK specifications are unary. Note that a predicate type always is unary or always is binary. It cannot be unary in one sentence and binary in another.

Like entity types, predicate types can also have data element types. The is published for predicate type has one data element type (year), while the has UK specifications predicate type has eight! The makes and is current predicate types do not have any data element types. Note that when the predicate type does have data element types, then they are always used (similar to entity types).

 

SENTENCE MODEL

It will be seen from the examples that sentences can be modeled in various ways. They can be unary or binary, they may use predicate types with or without data element types, and can use entity types with a single data element type or with many. The process of defining data element types, entity types and predicate types is called sentence modeling in Pro/3.

It is important to come up with a good model - to achieve an intuitive natural language interface among other things. However, variations in the style of sentence modeling do usually not constrain the formulation of rules.  

 

SENTENCE TYPES - SENTENCE GROUPS

The ordered set (combination) of entity types and predicate type (in a sentence) is referred as the sentence's sentence type. The sentence types in the examples are exchange rate is current, bike has UK specifications, manufacturer makes bike and retail price is published for bike. Sentence types play an important role in organizing sentences, and is a key concept in sentence rules.

A sentence group is practically the same as the sentence's predicate type, i.e. all sentences (sentence types) with the same predicate type.

How are facts represented in the knowledge base?

The natural language style representation of facts shown in the examples above are not practical inside the knowledge base. A format more suited for processing by an inference engine is required. The internal format is the same as used in PROLOG-language facts:

PRO/3 SENTENCE

INTERNAL REPRESENTATION STRUCTURE

EXAMPLE
subject-predicate sentence (predicate without data elements) predicate ( entity ( data_element , data_element , ...)) pApplies(eExchangeRate(iGBP,0.56))!
subject-predicate sentence (predicate with data elements) predicate ( entity ( data_element , data_element , ...), data_element, data_element , ...) pHasSpecifications(eBike("RSV Mille R"),998,113,i4Stroke,2,145,0,33,167)!
subject-predicate-object sentence (predicate without data elements) predicate ( entity ( data_element , data_element , ...) , entity ( data_element , data_element , ...)) pMakes(eManufacturer(iKawasaki),eBike("Ninja ZX-7R"))!
subject-predicate-object sentence (predicate with data elements) predicate ( entity ( data_element , data_element , ...) , entity ( data_element , data_element , ...) , data_element , data_element , ...) pIsPublishedFor(eUKPrice(4250,iGBP),eBike("M600 Monster Dark"),2001)!
The entity types in a sentence correspond to the functor-concept in PROLOG.
 

NATURAL LANGUAGE TRANSLATION

The names used for predicate types and entity types in natural language are generally not acceptable in the internal PROLOG format exchange rate, for example, consists of two words which is not allowed for an identifier in PROLOG syntax. Pro/3, on the other hand, does not impose much constraints on names. 

The expressiveness at the natural language level is resolved by requiring each natural language name to have a corresponding internal name. This two-level naming structure has the additional advantage that Pro/3 models can have multiple natural language interfaces e.g. one English language interface and one Danish. It also allows for use of natural language synonyms.

Note the difference in the internal representation of names (identifiers) and strings: Kawasaki and 4-stroke are represented internally as (iKawasaki and i4Stroke) while "Ninja ZX-7R" has the same representation externally and internally. 

The importance of understanding the structure of facts!

The importance of understanding the structure of facts in Pro/3 cannot be overstated. A lot of things revolve around the fact concept. Rules (sentence-rules to be specific), describe how facts are derived from other facts. Without a clear understanding of facts, you cannot understand these rules. The answer to queries (questions) are in most cases one or more sentences, and the structure of the query itself is based on the sentence structure.