Pro/3 knowledge can either be stored in a 3KB-type database (Pro/3's native database system), or in the case of multi-DB configurations: in two or more 3KB-type databases; or in an SQL database. There is no multi-DB configuration concept with SQL-type knowledge bases. Pro/3 accesses the SQL database via ODBC.

A 3KB-type database is stored in one OS file with name xxx.3kb - xxx is referred to as the name of the knowledge base (KB) in this case. An SQL-type knowledge base is stored as a set of tables in one SQL database. It is possible to store more than one knowledge base in the same SQL database, however the knowledge bases do not share tables. A knowledge base named xxx stored in SQL database yyy, is referred to as yyy.xxx.sql.

You have to decide which format you want to use when you initialize a new KB. However, a 3KB-type database can automatically be exported to an SQL-type database at any time. The reverse operation can only be done indirectly i.e. by backing up the contents of the SQL database to source knowledge, which then can be loaded into an 3KB-type database.

A significant difference between the two database approaches is that knowledge (in reality factual knowledge) in an SQL-type databases easily can be shared with other applications and browsed or maintained with SQL-based tools. Knowledge in 3KB-type databases can only be accessed via PRO3.EXE.

The MySQL database and tools (MySQLAdministrator, MySQL Query Browser), available for free, have been very successfully used as SQL-server for Pro/3.

 

PERFORMANCE COMPARISON

3KB-type database is faster than SQL-type databases, at least for small/medium size database sizes. Re-derivation of all sentences in the RAC KB is about twice as fast with 3KB.

Below are described the commonalities between 3KB-type and SQL-type database structures:

 

RECORDS
The basic database storage unit is called a record. One record contains one of five types of knowledge:
  • one fact (sentence) whether derived or entered
  • one sentence rule
  • one function definition (function body) - functions with N bodies are stored in N different records
  • one inexact rule
  • one derived sentence rule

 

CHAINS
Records are grouped together in chains:

There is one chain for:

  • all sentence with the same predicate type and also all sentence rules with this predicate type in the record's conclusion field (see under). Chain name = predicate type KB-name;
  • One chain for each function (if this function has a definition - built-in functions do not have definitions since they are embedded in PRO3.EXE). Chain name = function KB-name;
  • One chain for each category of inexact rules (if inexact rules in this category exist). Chain name = p3_iCbay, p3_iCcmb, p3_iCand, p3_iCnot, p3_iCor, p3_iZnot, p3_iZowa, p3_iZand, p3_iZor, p3_iCswi, p3_iCmap, p3_iCdat, p3_iCpar.

All chains are considered by the inference engine when a query is processed.

Note that the chain is a physical database concept in 3KB databases, but only a logical concept in SQL databases.

 

RECORD FIELDS

Each record contains consists of eight fields:

SQL databases additionally have some fields (columns) derived from the above eight fields:

  • basic record type [abs(record type mod 10)]
  • active
  • suspended
  • sentence type (blank for inexact rule records)

Last update/creation time

The date and time for record creation/last update.

Realm name

Knowledge inputted from source files via an editor window uses the source file name as realm name. Derived knowledge or knowledge inputted through form windows, structure windows or the New Record window, is assigned one of the standard system realm names. The realm name and sentence no are explicitly specified for rules inputted through the Rule-editor window. 

Note the following restrictions on realm names:  

System realms:

$<UpperCaseLetter><UpperCaseLetter><UpperCaseLetter>

All other realms:

<UpperCaseLetter>+{<UpperCaseLetter>|<Digit>|-|_}*

  

RECORD TYPE
RECORD TYPE CONTENTS
1 derived sentence
2 inputted sentence
3 sentence rule (active, not suspended)
-3 sentence rule (inactive, not suspended)
30 sentence rule (active, suspended)
-30 sentence rule (inactive, suspended)
4 function definition (not suspended)
40 function definition (suspended)
5 derived rule (active)
-5 derived rule (inactive)
6 inexact rule (not suspended)
60 inexact rule (suspended)
8 derived sentence during derivation process (temporary status)

 
Type 2 sentences are explicitly defined (inputted) by the KE (in addition to the internal system sentences generated by Pro/3). Type 1 sentences are derived from Type 3 sentences and sentence rules. The derivation is carried out automatically by Pro/3. Type 5 rules are derived from Type 3 sentence rules which have open entity arguments. Active rules are available to the inference engine i.e. they will be used when inferences are maid. Inactive rules are not used by the inference engine. Pro/3 switches the record type of rules as required during sentence derivation. Suspended records are totally ignored by the inference engine and sentence derivation process as well as by most other Pro/3 user interfaces.
RECORD ORIGIN REALM NAME
XML XML source file name (converted to upper case), unless explicitly specified in XML attribute (this will usually be the case)
Sentences in NL or PR in editor windows Editor window's corresponding file name (converted to upper case)
Sentence rules in Rule-editor window Explicitly entered
Derived rules (generated by Pro/3) Same as the originating rule
Inexact rules entered in inexact rules windows. Explicitly entered (also a default realm name for inexact rules set in the Directories and Files Preferences window).
Records entered in the New Record-window Explicitly entered
Misc. system administration sentences generated by Pro/3 $SYS
Sentences entered in Sentence-window $DAT
Derived sentences (generated by Pro/3) $DER
Dependency, derivation and sentence model graphs (generated by Pro/3) $GRAPH
Terminology sentences entered in terminology-related windows in the Structure-menu. $TRM
Sentence model sentences entered in the Sentence Model-window. $SM
Sentences imported from ST-tables $IMPORT
Inexact rule reasoning sentences (generated by Pro/3) $IRR

 

RECORD NO AND SUB-NO

Record numbering is only important for sentence rules (although non-sentence rule input from files in 3NL or 3PR formats (sentences, function definitions) are assigned records numbers 1,2,3,... (sub-number is always 0). Record numbering consists of a record number and a sub-number. Note the following conventions: 

  • Sentence rules which generate multiple rule records (rules with logical OR) use sub-number 1, 2, 3 etc. for the generated rule records. 
  • Sentence rules which do not generate multiple records are assigned sub number 0. 
  • Derived sentence rules (which are generated by Pro/3) are assigned sub numbers n01, n02, n03 etc., where n is the sentence number of the original rule.

Record numbering and sub-numbering for non-sentence rules might differ from these conventions for records created under older versions of Pro/3. This has no particular side-effects.

CONDITION AND CONCLUSION FIELDS

The condition and conclusion fields are terms which represent the core knowledge part of the record (the other fields are essentially meta-data).
KNOWLEDGE TYPE CONDITION CONCLUSION
SENTENCE RULE the rule's condition the rule's conclusion
SENTENCE atom("true") the sentence (a sentence can be viewed as a rule with condition TRUE).
CERTAINTY RULE nill() (this is simply a convention without any particular logical significance) the certainty rule's body
FUNCTION the function's definition the function's header

 

KNOWLEDGE CACHES
Pro/3 uses three caches i.e. RAM-based logical duplicates for information already in the knowledge base (KB). The cache mechanisms are not transparent to the knowledge engineer (KE), and some understanding of the caches are thus needed. The purpose of the caches are to improve response speeds, both during inference and during knowledge base building and maintenance. The improvement in response speed is more important in SQL-type KBs than with 3KB-type KBs.

GRAPHS

Pro/3 uses three graphs to track dependencies between the different elements of knowledge in the KB. These are the sentence model graph, the knowledge dependency graph and the derivation graph. These three graphs are loaded into a graph-structured cache when the KB is opened (the graphs are stored as sentences in the KB); referred to and also updated in the cache; and eventually re-stored to the KB (if there have been changes) when the KB is closed.

The graph caching is mostly transparent to KE. However, when querying the sentences representing the graphs (or using the Sentences-window to browse graph sentences), then it is important to note that the queries only considers the sentences in the KB (and not the graphs in the cache). To compensate for this, a command is included in the KB-menu (Update cached graphs in the KB). The command will save the cached graphs to the KB. Responses to queries involving graph sentences will then reflect the current (cached) graphs.    

TERMINOLOGY CACHE

The terminology cache contains the two is in the terminology-sentence types (for the current terminology).  The cache is loaded when the KB is opened. The cache is never updated, that is, changes are made directly to the terminology stored in the database (and the cache is simply turned off to avoid errors). The status of the cache is shown in the toolbar, i.e. the presence of a yellow T indicates that the cache is on. You can use the toggle switch to the left to turn the cache on (i.e. to reload it) or off. (There is also a corresponding command in the Structure-menu). A change in current terminology will trigger a cache reload (if the cache is on).

SENTENCE MODEL CACHE

The sentence model cache contains the eight is in the sentence model-sentence types, which works in the same way as the terminology cache. The cache is loaded when the KB is opened. The cache is never updated, that is, changes are made directly to the sentence model stored in the database (and the cache is simply turned off to avoid errors). The status of the cache is shown in the toolbar, i.e. the presence of a yellow S indicates that the cache is on. You can use the toggle switch to the left to turn the cache off and on (i.e. to reload it) (there is also a corresponding command in the Structure-menu).