2. Conceptual Framework

This chapter presents the fundamental conceptual building blocks that are used to construct PowerLoom knowledge bases. The PowerLoom language is based on KIF, which provides a syntax and a declarative semantics for first-order predicate calculus expressions. KIF is a proposed ANSII standard language used by a variety of knowledge representation systems. Practical knowledge representation systems necessarily add a procedural semantics that defines the interpretation of knowledge structures when definitions and facts are retracted or modified. This chapter assumes that the reader has some familiarity with the semantics of the predicate calculus, and instead focuses on aspects of the semantics that go beyond the traditional (KIF) semantics.

A PowerLoom knowledge base is constructed by first defining the terminology (concepts and relations) for a domain, and then asserting additional rules and facts about that domain. Facts can be asserted and later retracted, so the answers returned by queries may change over time. The knowledge structures are organized into logical containers called “modules”. The division into modules means that in general, facts are not asserted globally, but instead hold only within a specific context. For example, a logical proposition may evaluate as true within one module, and evaluate as false within a different one.

The discussion below uses some examples of actual PowerLoom syntax to illustrate certain points. However, we gloss over the fine points of syntax, and instead focus on semantic issues. The next chapter reverses that emphasis, and presents a series of examples that illustrate the breadth of syntactic constructs implemented for the PowerLoom language.

2.1 Terms and Propositions

A knowledge base attempts to capture in abstract (machine interpretable) form a useful representation of a physical or virtual world. The entities in that world are modeled in the knowledge base by objects we call terms. Examples of terms are “Georgia” (denoting the U.S., state), “BenjaminFranklin” (denoting the historical person by that name), the number three, the string "abc", and the concept “Person”. Unlike objects in an object-oriented programming language, the terms in a PowerLoom knowledge base usually have distinct names (unless there are sufficiently many that naming them all becomes impractical).

Terms are categorized or related to one another by objects called relations. Examples of relations are “has age”, “greater than”, “is married to”, “plus”. Concepts such as “Person”, “State”, “Company”, and “Number” are considered a subcategory of relations.

A proposition is a logical sentence that has an associated truth value. Examples are “Ben Franklin is a person”, “Bill is married to Hillary”, “Two plus three equals six” (which is false). PowerLoom follows KIF in adopting a prefix notation for the predicate calculus to represent propositions. Possible representations of the three propositions just mentioned are (person ben-franklin), (married-to Bill Hillary), and (= (+ 2 3) 6). These three propositions make reference to relations named person, married-to, plus, and =.

The predicate calculus constructs complex sentences out of simpler ones using the logical connectives and, or, not, <=, =>, and <=>, and the quantifiers exists and forall. Some examples are (not (crook richard)) “Richard is not a crook”, and (forall ?p (=> (person ?p) (exists ?m (has-mother ?p ?m)))) “every person has a mother”.

2.2 Definitions

PowerLoom requires that relations are defined before they are used within assertions and queries. The commands defconcept, defrelation, and deffunction are used to define concepts, relations, and functions, respectively. The definitions

(defconcept person)
(defrelation married-to ((?p1 person) (?p2 person))
(deffunction + ((?n1 number) (?n2 number)) :-> (?sum number))

declare that person is a concept, that married-to is a binary relation that takes arguments of type person, and that + is a function that takes arguments of type number(1). The requirement that relations be defined before they are referenced can be inconvenient at times. For example, suppose we wish to define parent as “a person who is the parent of another person” and we also wish to state that the first argument to the parent-of relation has type parent:

(defconcept parent (?p)
  :<=> (and (person ?p) (exists ?c (parent-of ?p ?c))))
(defrelation parent-of ((?p parent) (?c person)))

In this example, the first reference to parent-of occurs before it is defined. PowerLoom permits circular references such as these as long as they occur within definitions. It does so by deferring evaluation of rules that occur within definitions. Here is a specification that is logically equivalent, but is not legal because the parent-of relation appears in an assertion before it is defined:

(defconcept parent (?p))
(assert (forall (?p) (<=> (parent ?p) 
                          (and (person ?p) (exists ?c (parent-of ?p ?c))))))
(defrelation parent-of ((?p parent) (?c person)))

So when does the rule inside of the first parent definition get defined? All axioms (facts and rules) that appear within the boundaries of a definition are evaluated just prior to the next occurrence of a PowerLoom query. Hence, in the example above where the rule occurred within the definition, there was no error because evaluation of that rule occured sometime after the second definition (which defines the otherwise problematic reference to parent-of).

One will sometimes see the command (process-definitions) appearing at intervals within a file containing PowerLoom commands. Each such appearance forces the definitions that preceed it to be fully-evaluated. This is done so that the interval between a definition and its evaluation not be too great; it can get confusing if PowerLoom reports a semantic violation long after the origin of the conflict.

PowerLoom definitions commands (those prefixed by “def”) have one other semantic property that distinguishes them from ordinary assertions. Any axioms that appear within a definition are tied to that definition. If a definition is modified and then reevaluated, axioms that don’t survive the modification are retracted. For example, suppose we evaluate the following two commands.

(defrelation parent-of ((?p1 person) (?p2 person))
  :=> (relative-of ?p1 ?p2))
(defrelation parent-of ((?p1 person) (?p2 person)))

The first definition defines person as a binary relation, and also states a rule that “parent-of implies relative-of”. The second definitions erases that rule, i.e., the cumulative effect is as if the first definition did not appear. In contrast, consider the following commands:

(defrelation parent-of ((?p1 person) (?p2 person)))
(assert (=> (parent-of ?p1 ?p2) (relative-of ?p1 ?p2)))
(defrelation parent-of ((?p1 person) (?p2 person)))

The assertion in this latter sequence is logically equivalent to the axiom introduced by the :=> keyword in the former sequence. However, at the end of this sequence, the “parent-of implies relative-of” rule is still in effect, since it appeared on its own, outside of a definition.

2.3 Truth Values

A PowerLoom proposition is tagged with a truth value that has one of five different settings—true, false, default-true, default-false, or unknown. The most common setting is true; when we make an assertion as in (assert (Person Bill)), the proposition (Person Bill) is assigned the truth value true. To assign the value false to a proposition, one asserts that it is not true, e.g., (assert (not (crook Richard))). The command presume is used to assign a proposition the value default-true, as in (presume (weather-in Los-Angeles Sunny)). Presuming a negated proposition assigns it the value default-false.

The assignment of a truth value to a proposition via assert or presume can upgrade the “strength” of a proposition, but it cannot downgrade it. Hence, if a proposition currently has the value unknown, then it may be assigned any of the other four values. If the value is default-true or default-false, an assertion that assigns the value true or false will overwrite the existing value. However, if the truth value of a proposition is either true or false, assigning it the value default-true or default-false will have no effect.

If a proposition is asserted to be true and subsequently is asserted to be false (or vice-versa), a clash (or contradiction) results. When a clash is detected by PowerLoom, a clash-exception is thrown. The system’s default behavior is for the exception to be caught and ignored, with the result that an assertion that would otherwise cause a clash never takes effect. Applications that execute commands slightly below the top-level (i.e., below the clash exception catcher) can catch the exception themselves and perform a specialized response. PowerLoom’s proof-by-contradiction specialist catches clashes to determine that a contradiction has occurred.

If a user or application wants to assign a proposition a truth value that isn’t stronger than the current value, it must first retract the current value. The PowerLoom retract operator has the effect of undoing a prior assertion. For example, if we assert that Mary is a parent of Fred, and then retract that assertion, the value of the proposition (parent-of Mary Fred) becomes unknown. The proposition can then be assigned any other truth value.

We should note that executing a retraction does not necessarily cause a proposition to cease being true. Consider the following sequence:

(defconcept Person)
(defconcept Employee (?e)
  :=> (Person ?e))
(assert (Person Mary))
(assert (Employee Mary))
(retract (Person Mary))

If we now ask PowerLoom whether or not Mary is a person, the answer will be yes (TRUE) because Mary is asserted to be an employee, and membership in employee implies membership in person. In other words, although the direct assertion that Mary is a person is not present in the knowledge base, a logical proof exists that the proposition “Mary is a person” is true.

2.4 Modules

The knowledge loaded into an executing PowerLoom system is divided into logical partitions called “modules”. The modules are arranged into a hierarchy; knowledge inherits down the hierarchy from parents to children. A convenient way to organize knowledge is to put definitional knowledge higher up in the module hierarchy, and factual knowledge lower down. For example, suppose we want to build a knowledge base that defines a business domain, and include a substantial number of facts about individual companies. We might use one or a few modules to define terminology that relates to the business domain, and then places the set of facts about each company in its own module. If we were querying the knowledge base about one or a few companies, it would not be necessary to load the modules for the remaining companies into the system.

Facts asserted within a module are not visible in sibling modules, or in ancestor modules. Thus, if we enter into PowerLoom an assertion that“Georgia is a state”, we are not asserting that Georgia is a state in all possible worlds, but that, from the vantage point of the current module and those modules below, it is the case that Georgia is a state. If we want the fact that Georgia is a state to be recognized as true in many or most other modules, then we should make our assertion in a module that is relatively high up in the hierarchy, so that is visible to (inherited by) the other modules.

The inheritance of facts is not monotonic—a child module can retract or override facts inherited from its ancestors. For example, suppose we have two modules, called above and below such that the below module is below (inherits from) the above module. Next, suppose we make an assertion within the above module that “Joel is a duck”, and then we shift to the below module and retract the proposition that “Joel is a duck”. From the vantage point of the below module, if we now ask if Joel is a duck, we will get back the value unknown. However, if we switch to the above module and ask the same question, we get back the answer true This occurs because the effect of the retraction operation that was applied to the below module is not “visible” to modules above it (or to any sibling modules). Hence, when module hierarchies are involved, it is oversimplifying to state that a retraction has the effect of erasing a prior assertion.

The PowerLoom execution process maintains a pointer to the current module, and all asserions, queries, etc. are made relative to that module. Hence, when we talk about “switching” from one module to another, we are speaking literally—a change-module command (or one of its equivalents) is invoked to switch from one module to another. (2)

PowerLoom comes with some modules already built-in. The module named PL-KERNEL contains a set of general-purpose concept and relation definitions that collectively form the foundation for constructing application-specific knowledge bases. PowerLoom attaches specialized reasoners to many of the relations in PL-KERNEL. The command interpreter starts up in a module named PL-USER. That module is initially empty, and is intended as a convenient place to experiment with PowerLoom.

This document was generated by Hans Chalupsky on January 6, 2023 using texi2html 1.82.