|
It is important to distinguish between two types of dependencies in the knowledge base:
Pro/3 analyzes and tracks these two types of dependencies in two acyclic graphs - referential dependencies in the sentence model graph (SM-graph for short) and logical dependencies in the knowledge dependency graph (DP-graph for short). There is also a third graph which is a "lower-level" version of the knowledge dependency graph called the derivation graph (DR-graph for short). The edges of these graphs are known as knowledge nodes or simply nodes. The edges of the graphs are represented as sentences in the knowledge base, corresponding to the following three sentences types:
The node entity type node has two data elements node type (an integer) and node name (a string). The sentences representing the graphs are referred to constantly by Pro/3, and they are performance reason stored in RAM cache which mirrors the sentences in the KB. The many elements of structural and application knowledge are referred to as knowledge nodes:
Knowledge nodes are represented in the graphs by their node type and node name. An edge in the graph represents the directed dependency (node type,node name) ---> (node type,node name). The directed relationship is known The first node is known as the determinant, while the second is known as the dependent. The table under shows the types of direct dependencies in the sentence model graph.
There are also indirect sentence model dependencies found in the dependency graph (under).
Pro/3 analyzes referential dependencies in and between structural knowledge and application knowledge in the KB, for the purpose of preventing inconsistencies and invalid references. In the simplest case, if a data element type is deleted, then all entity types defined with this data element type, and indirectly, all sentences involving entities of this type would become inconsistent. Referential dependencies form a directed acyclic graph referred to as the sentence model graph. Like any other factual knowledge in Pro/3, the dependencies are represented as sentences in the KB. The following NL format is used:
The sentence model graph and the dependency graph are loaded into a cache data structure upon opening of the KB. Changes in the graphs during processing, are only reflected in this data structure while interacting with Pro/3 (i.e. they are not reflected in the KB). The graphs are stored in the KB upon closing. QUERYING THE GRAPHS Queries only consider knowledge in the KB. This means that queries involving the graphs (such as the standard Pro/3 knowledge dependency queries), will not reflect changes which have taken place after the KB was opened. To compensate for this potential problem, a command to update the graph knowledge in the KB has been included the KB-menu. This command can then be used prior to running such queries. PREVENTING INCONSISTENCIES Potential inconsistencies resulting from delete or update actions, are prevented by forced deletions (or suspensions) of all direct and indirect dependents. The process of determining a node's dependents (with respect to referential integrity), starts with looking at the sentence model graph and then combining the finding in this graph with looking at the dependency graph. Pro/3 will always present a list of dependent knowledge for deletion whenever a delete or an update of a node is attempted:
The list includes direct as well as indirect dependents of the changed or deleted knowledge node. It is often desirable not to delete the dependent knowledge nodes (to avoid having to re-enter e.g. a sentence rule) - it is better to mark them as suspended for subsequent review and change, to once again make them consistent with other knowledge nodes. The options to suspend is available for sentence rules, function definitions and inexact rules. Dependent facts, whether entered or derived, cannot be suspended (i.e. they must be deleted). All suspended records can be viewed in the Suspended Records-window. The suspended state should be looked upon as temporary, and suspended records should as soon as possible be re-instated as (non-suspended) records (or deleted). Processing queries or deriving sentences could give unexpected results with suspended records present. Suspended records are never considered by the inference engine, however they are included in some windows: Suspended sentence rules are shown in the Sentence Rules-window. The rule editor will try to update the rule where possible when opened by the Rule Editor. Suspended inexact rules are listed in the Certainty Rules-window preceded by an asterisk. Updating the inexact rule may or may not work depending on the presence of integrity problems (i.e. the integrity issues which generated the suspension originally). The suspension will be removed if the update succeeds. If errors, then try to update the inexact rule (first) using the Record-window. An error message will be displayed if a suspended inexact rule is encountered during inferences (i.e. processing of queries/derivations). Suspended function definitions are shown in the Function-window preceded by an asterisk. Updating the function may or may not work depending on the presence of integrity problems (i.e. the integrity issues which generated the suspension originally). The suspension will be removed if the update succeeds. If errors, then try to update the function (first) using the Record-window. Suspended functions will NOT be detected during inferences (i.e. processing of queries/derivations). A call to a suspended function will simply fail. The Suspended Records-window has a button to remove the suspensions of selected or all suspended records. These buttons are especially useful for removing suspensions which do not require any changes to the suspended records (note that a suspended record is potentially inconsistent only). Sometimes the removal-action has to be repeated several times by closing and re-opening the window (the number of suspended records will always decrease each time). Ignoring potential integrity issues You can choose to ignore the potential integrity issue if you understand what they are and how they eventually can be resolved. Note that the displayed list of affected knowledge nodes include direct as well as indirect depend knowledge. Choosing to ignore the integrity issues will only affect the direct dependents since by leaving these unchanged, the indirect dependents will not have any issues. |