[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

3. Annotated Example

The section presents a small example of a PowerLoom knowledge base. It introduces the fundamental PowerLoom modelling concepts and illustrates the syntax of basic PowerLoom declarations, assertions, and commands. This section can be read stand-alone, but readers who intend to use PowerLoom to create their own models are encouraged to load the demo file ???, and run the examples “live”.

The conceptual terms introduced in this section include modules, concepts, relations, functions, instances, propositions, assertions, queries, retraction, positive and negative facts, clipping, rules, and contexts.


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

3.1 Using Modules

We begin by creating a PowerLoom “module”, which is a logical container that holds the term definitions, rules, facts, etc. that make up all or a portion of a domain model. We will call our module business. The defmodule command defines a new module. The :includes option within the defmodule tells PowerLoom that the business module inherits all definitions and assertions present in the PL-USER module, or in ancestor modules inherited by the PL-USER module. In particular, by inheriting PL-USER, we indirectly inherit the PL-KERNEL module that contains all of the built-in concepts and relations. The in-module command tells the PowerLoom system to make BUSINESS the current module. Until the current module is changed again, all new introductions of terms and facts will be placed in the business module.

 
(defmodule "BUSINESS"
  :includes ("PL-USER"))
(in-module "BUSINESS")

The basic building blocks of a model are its concepts, relations, and instances.(3) A concept defines classes/categories of entities that populate the domain model. A relation defines attributes and relationships that allow the declaration of facts about an entity. Instances are members of concepts. They appear as arguments to propositional assertions.


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

3.2 Concepts

Concepts are defined using the defconcept command. Here we define the concepts company and corporation:

 
(defconcept company)
(defconcept corporation (?c company))

The first definition tells the system that company is a concept (in the business module). The second definition defines a concept corporation. The type declaration (?c company) indicates that corporation is a subconcept of company, i.e., all instances of corporation are also instances of company. Let us now create a couple of companies:

 
(assert (company ACME-cleaners))
(assert (corporation megasoft))

These two assertions create two new entities denoted by the terms ACME-cleaners and megasoft. Both of these entities are members of the concept company. megasoft is also a member of the concept corporation. We can test this by executing some PowerLoom queries:

 
(retrieve all ?x (company ?x))
⇒
There are 2 solutions:
  #1: ?X=ACME-CLEANERS
  #2: ?X=MEGASOFT

(retrieve all ?x (corporation ?x))
⇒
There is 1 solution:
  #1: ?X=MEGASOFT

[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

3.3 Relations

So far, our two companies aren’t very interesting. In order to say more about them, we can define some relations and functions using the declarations defrelation and deffunction:

 
(defrelation company-name ((?c company) (?name STRING)))

This declaration defines a binary relation company-name. The first value in a company-name tuple must be an instance of type company, while the second value must be a string. We can now give our companies names, using the command assert:

 
(assert (company-name ACME-cleaners "ACME Cleaners, LTD"))
(assert (company-name megasoft "MegaSoft, Inc."))

We can retrieve pairs of companies and their names with the following query (note that we omitted the optional retrieval variables in which case they are determined by collecting the free variables in the query expression):

 
(retrieve all (company-name ?x ?y))
⇒
There are 2 solutions:
  #1: ?X=MEGASOFT, ?Y="MegaSoft, Inc."
  #2: ?X=ACME-CLEANERS, ?Y="ACME Cleaners, LTD"

Using retrieval variables is useful if we want to order the result columns in a certain way, for example:

 
(retrieve all (?y ?x) (company-name ?x ?y))
⇒
There are 2 solutions:
  #1: ?Y="MegaSoft, Inc.", ?X=MEGASOFT
  #2: ?Y="ACME Cleaners, LTD", ?X=ACME-CLEANERS

[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

3.4 Relation Hierarchies

PowerLoom permits the specification of hierarchies both for concepts and relations. Previously , we defined a small concept hierarchy with company on top and corporation below it. We now define a subrelation of the relation company-name called fictitious-business-name:

 
(defrelation fictitious-business-name ((?c company) (?name STRING))
  :=> (company-name ?c ?name))

PowerLoom defines a subconcept/subrelation relationship between a pair of concepts or a pair of relations by asserting an “implication” relation between them. The above implication expands into the assertion “for all values of ?c and ?name, if the fictitious-business-name relation holds for ?c and?name, then the company-name relation also holds for ?c and ?name”. This is equivalent to the assertion

 
(forall (?c ?name) (=> (fictitious-business-name ?c ?name)
                       (company-name ?c ?name)))

Since implication relationships occur very commonly, PowerLoom provides several syntactic shortcuts for defining them. We have seen one such shortcut earlier; our definition of corporation included the clause “(c ?company)”, which specified that corporation is a subconcept of company. In our definition of fictitious-business-name, the keyword :=> introduces a similar shortcut, which tells us that fictitious-business-name is a subrelation of company-name. Let us assert a fictious business name for MegaSoft:

 
(assert (fictitious-business-name megasoft "MegaSoft"))

If we query for the company names of MegaSoft, we get two names, one of them asserted directly, and one of them infered by the subrelation rule:

 
(retrieve all (company-name megasoft ?x))
⇒
There are 2 solutions:
  #1: ?X="MegaSoft, Inc."
  #2: ?X="MegaSoft"

[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

3.5 Functions

This illustrates another point: A PowerLoom relation is by default “multi-valued”, which in the case of a binary relation means that a single first value can be mapped by the relation to more than one second value. In the present case, our model permits a company entity to have more than one company-name. If a (binary) relation always maps its first argument to exactly one value (i.e., if it it “single-valued”) we can specify it as a function instead of a relation. For example, we can use a function to indicate the number of employees for a company:

 
(deffunction number-of-employees ((?c company)) :-> (?n INTEGER))

When defining a function, all arguments but the last appear just as they do for a relation. The last argument (and its type) appears by itself following the keyword :->. Defining a single-valued relation as a function allows us to refer to it using a functional syntax within a logical sentence, as in the following:

 
(assert (= (number-of-employees ACME-cleaners) 8))
(assert (= (number-of-employees megasoft) 10000))

The functional syntax often results in shorter expressions than equivalents that use relational syntax. For example to retrieve all companies with fewer than 50 employees, we can simply write:

 
(retrieve all (and (company ?x) (< (number-of-employees ?x) 50)))
⇒
There is 1 solution:
  #1: ?X=ACME-CLEANERS

Using the syntax for relations, the same query would require the introduction of an existential quantifier, as in:

 
(retrieve all (and (company ?x) 
                   (exists ?n
                     (and (number-of-employees ?x ?n)
                          (< ?n 50)))))
⇒
There is 1 solution:
  #1: ?X=ACME-CLEANERS

To repeat ourselves slightly, Powerloom allows users the choice of using either relational or functional syntax when using a function in predicate position. For example, if f is a function, then the expressions (f ?x ?y) and (= (f ?x) ?y) are equivalent.


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

3.6 Defined Concepts

If we find ourselves writing the same query (or subexpression) repeatedly, we may wish to define a name for the concept embodying that expression. For example, below we define the term small-company to represent the class of all companies with fewer than 50 employees:

 
(defconcept small-company ((?c company))
  :<=> (and (Company ?c)
            (< (number-of-employees ?c) 50)))

Notice that we have used a new keyword, :<=>. This keyword defines a bidirectional implication called “if-and-only-if”. Formally it is equivalent to the following pair of assertions:

 
(assert (forall ?c (=> (and (Company ?c)
                            (< (number-of-employees ?c) 50))
                       (small-company ?c))))
(assert (forall ?c (=> (small-company ?c)
                       (and (Company ?c)
                            (< (number-of-employees ?c) 50)))))

In other words, the :<=> keyword is a shortcut for an assertion that uses the <=> relation, which itself is a shortcut representing the conjunction of two single arrow implications. For example, (<=> P Q) is equivalent to (and (<= P Q) (=> P Q)), where the <= relation is defined to be the inverse of the relation =>.

Its not necessary that we exactly specify the number of employees in a company. Below, all we know about ZZ Productions is that they have fewer than 20 employees:

 
(assert (and (company zz-productions)
             (< (number-of-employees zz-productions) 20)))

These facts are sufficient to classify ZZ Productions as a small business:

 
(retrieve all (small-company ?x))
⇒
There are 2 solutions:
  #1: ?X=ZZ-PRODUCTIONS
  #2: ?X=ACME-CLEANERS

[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

3.7 Negation and Open and Closed World Semantics

PowerLoom implements a three-valued logic—the truth value of each proposition entered into a PowerLoom knowledge base is recorded as being either true, false, or unknown.(4) Many other systems (e.g., relational DBMSs) implement a two-valued logic, wherein if a fact is not asserted to be true, it is assumed to be false. The PowerLoom command ask returns one of three (five) values: true if it can prove the truth of a proposition, false if it can easily prove the falsity of a proposition(5) and otherwise it returns unknown. (The values default-true and default-false are also possible if defaults are used).

Below, PowerLoom knows nothing about a newly-introduced concept s-corporation, so ask returns unknown to both a positive query and its negation:

 
(defconcept s-corporation (?c corporation))
(ask (s-corporation zz-productions))
⇒
UNKNOWN
(ask (not (s-corporation zz-productions)))
⇒
UNKNOWN

If we assert that ZZ Productions is not an S-corporation, then PowerLoom knows that the proposition in question is false:

 
(assert (not (s-corporation zz-productions)))
(ask (s-corporation zz-productions))
⇒
FALSE
(ask (not (s-corporation zz-productions)))
⇒
TRUE

After asserting that ZZ Productions is not an S-corporation, a repeat of the query asking if it is one will now return false, because the explicit assertion of the negation allows a quick disproof of the positive query.

Note: PowerLoom uses all its effort to prove that the proposition in question is true, and only uses some effort to prove that it is false. Therefore, only falsities that are discovered "on the way" or with shallow inference strategies will be found (which was the case above). If you want to check whether a proposition is false with maximum effort, simply ask the negated proposition by wrapping an explicit not arount it. The reason for this asymmetry is that checking for truth and falsity really amounts to asking two separate and possibly expensive queries, and the user or programmer should decide whether the effort should be expended to ask both queries instead of just one.

PowerLoom can sometimes infer a negative fact without the necessity of a direct assertion. For example:

 
(ask (= (number-of-employees ACME-cleaners) 8))
⇒
TRUE
(ask (= (number-of-employees ACME-cleaners) 10))
⇒
FALSE
(ask (not (= (number-of-employees ACME-cleaners) 10)))
⇒
TRUE

PowerLoom can infer the second and third answers because it knows that the function number-of-employees can return only one value, and if that value is the number eight, it cannot also be something else (in this case, ten).

Many systems, in particular, database systems and Prolog, make the assumptions that if a proposition cannot be proved true, then it must be false. This is called the “closed world assumption”. By default, PowerLoom makes an open-world assumption, but for specific relations it can be instructed to assume a closed world if a user wants closed world semantics. For example, suppose we introduce a relation works-for, and we assume that all works-for facts have been entered in our knowledge base:

 
(defrelation works-for (?p (?c Company)))
(assert (works-for shirly ACME-cleaners))
(assert (works-for jerome zz-productions))

If we ask PowerLoom whether Jerome does NOT work for MegaSoft, it will return unknown. But if we assert that the relation works-for is closed, then PowerLoom will assume that Jerome only works for ZZ Productions:

 
(ask (not (works-for jerome megasoft)))
⇒
UNKNOWN

(assert (closed works-for))
(ask (not (works-for jerome megasoft)))
⇒
TRUE

The reasoning employed to achieve the above result (that Jerome does not work for MegaSoft) is called “negation as failure”, which means that if a proof of a proposition fails, then one may assume that the proposition is false. We can achieve a negation-as-failure result a second way (i.e., other than by using a closed world assumption) by employing the query operator fail. Here we retract the closure assumption for works-for and achieve the desired result using fail:

 
(retract (closed works-for))
(ask (not (works-for jerome megasoft)))
⇒
UNKNOWN

(ask (fail (works-for jerome megasoft)))
⇒
TRUE

When you see the operator “not” in an SQL query or a Prolog program, it really stands for “fail”.


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

3.8 Retraction

Below, we introduce a few new terms for defining geographic information. We define a relation called contains to assert that one geographic location (the second argument to contains) is located within another:

 
(defconcept geographic-location)
(defconcept country (?l geographic-location))
(defconcept state (?l geographic-location))
(defconcept city (?l geographic-location))
(defrelation contains ((?l1 geographic-location)
                       (?l2 geographic-location)))

Now, we can assert some facts about U.S. geography (including one deliberate mistake):

 
(assert (and 
         (country united-states)
         (geographic-location eastern-us) 
         (contains united-states eastern-us)
         (state georgia) (contains eastern-us georgia)
         (city atlanta) (contains georgia atlanta)
         (geographic-location southern-us) 
         (contains united-states southern-us)
         (state texas) (contains eastern-us texas)
         (city dallas) (contains texas dallas)
         (city austin) (contains texas austin)))

We would like to repair the incorrect assertion (contains eastern-us texas). The PowerLoom command retract allows us to erase assertions that should not be true:

 
(ask (contains eastern-us texas))
⇒
TRUE

(retract (contains eastern-us texas))
(assert (contains southern-us texas))

(ask (contains eastern-us texas))
⇒
UNKNOWN

Retraction should not be confused with assertion of negative propositions. For example, asserting that Texas is not a state would not retract the assertion that it is (a state). Instead, an evident logical contradiction is detected as a “clash”, and the clashing proposition is disallowed:

 
(assert (not (state texas)))
⇒
Derived both TRUE and FALSE for the proposition `|P|(STATE TEXAS)'.
   Clash occurred in module ``|MDL|/PL-KERNEL-KB/business'.

(ask (not (state texas)))
⇒
UNKNOWN

[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

3.9 Clipping of Values

Programmers are accustomed to changing the values of attributes for program objects just by overwriting previous values. PowerLoom implements a similar semantics for the special case of functions and single-valued relations. When a second value is asserted for one of these relations the previous value is automatically retracted. We call this clipping.

To illustrate this behavior for both kinds of relations (a function is considered a kind of relation), we will define a mapping from a company to a city that contains its headquarters in two different ways:

 
(deffunction headquarters ((?c company)) :-> (?city city))
(defrelation headquartered-in ((?c company) (?city city))
  :axioms (single-valued headquartered-in))

The clause ":axioms (single-valued headquartered-in)" tells PowerLoom that the headquartered-in relation is single-valued, i.e., that it can map a company to at most one city. This makes its behavior similar to that of the function headquarters. Here is an example of clipping for the function headquarters:

 
(assert (= (headquarters zz-productions) atlanta))
(retrieve all (= ?x (headquarters zz-productions)))
⇒
There is 1 solution:
  #1: ?X=ATLANTA

(assert (= (headquarters zz-productions) dallas))
(retrieve all (= ?x (headquarters zz-productions)))
⇒
There is 1 solution:
  #1: ?X=DALLAS

Here is the same kind of clipping using a single-valued relation:

 
(assert (headquartered-in megasoft atlanta))
(retrieve all (headquartered-in megasoft ?x))
⇒
There is 1 solution:
  #1: ?X=ATLANTA

(assert (headquartered-in megasoft dallas))
(retrieve all (headquartered-in megasoft ?x))
⇒
There is 1 solution:
  #1: ?X=DALLAS

[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

3.10 Rule-based Inference

Suppose that we want to retrieve all geographic locations that are contained in the Southern US, based on the set of assertions about geography that we entered in earlier. The following query returns only one of such location:

 
(retrieve all (contains southern-us ?x))
⇒
There is 1 solution:
  #1: ?X=TEXAS

We would like the cities Austin and Dallas to be retrieved as well. To do this, we can assert a rule that states that contains is a transitive relation:

 
(defrule transitive-contains
  (=> (and (contains ?l1 ?l2)
           (contains ?l2 ?l3))
      (contains ?l1 ?l3)))

The defrule declaration does two things—it asserts a proposition, and it associates a name with that proposition (in the above case, the name is transitive-contains). This name is used by the system in displaying traces of its inferencing. It also makes redefinition of the proposition easier. If we wish to retract an unnamed proposition, it is necessary to explicitly retract that proposition using a syntax identical to the assertion(6) If on the other hand, a proposition has a name, then a new defrule declaration that uses the same name will automatically retract any existing proposition having the same name.

Our transitive closure rule failed to include any logical quantifiers for the variables ?l1, ?l2, and ?l3. When PowerLoom parses a top-level proposition, it automatically supplies universal quantifiers for any unquantified variables. So, the above rule is equivalent to the rule:

 
(defrule transitive-contains
  (forall (?l1 ?l2 ?l3)
    (=> (and (contains ?l1 ?l2)
             (contains ?l2 ?l3))
        (contains ?l1 ?l3))))

Note: Instead of defining a transitive-contains rule, we could have achieved the same effect by asserting that the contains relation is transitive, e.g., by stating (assert (transitive contains)).

Now that we have told the system that our contains relation is transitive, let us rerun our query:

 
(retrieve all (contains southern-us ?x))
⇒
There are 3 solutions:
  #1: ?X=TEXAS
  #2: ?X=AUSTIN
  #3: ?X=DALLAS

[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

3.11 Explanation

PowerLoom provides a command called why that you can use to get an explanation of the logic behind one of its answers. The why command explains the last query entered into the system, i.e., it should invoked after one has submitted a retrieve or an ask command. Before asking a why command, you must enable the justifications feature:

 
(set-feature justifications)

Queries execute a bit more slowly with jusifications enabled, which is why it is disabled by default. Having enabled justifications, we must (re)run a query. Here is how we can ask why Dallas is contained in the Southern US:

 
(ask (contains southern-us dallas))
⇒
TRUE
(why)
⇒
1 (CONTAINS SOUTHERN-US DALLAS)
    follows by Modus Ponens
    and substitution {?l3/DALLAS, ?l2/TEXAS, ?l1/SOUTHERN-US}
    since 1.1 ! (forall (?l1 ?l3)
                   (<= (CONTAINS ?l1 ?l3)
                       (exists (?l2)
                          (and (CONTAINS ?l1 ?l2)
                               (CONTAINS ?l2 ?l3)))))
    and   1.2 ! (CONTAINS SOUTHERN-US TEXAS)
    and   1.3 ! (CONTAINS TEXAS DALLAS)

The above explanation tells us that a rule (our transitivity rule) was invoked during the proof, and that two ground assertions (CONTAINS SOUTHERN-US TEXAS) and (CONTAINS TEXAS DALLAS) were accessed to supply preconditions for the rule. These combined assertions lead to the conclusion (CONTAINS SOUTHERN-US DALLAS). Within an explanation, directly asserted propositions are indicated with the prefix ‘!’.

We can also ask why after a retrieve query. However, if the query has multiple solutions, each one has a separate explanation. In order to ask why, we need to ask for one solution at a time. This can be done by omitting the word all from the retrieve query, and subsequently calling (retrieve) to obtain results one-at-a-time. (7)

 
(retrieve (contains southern-us ?x))
⇒
  #1: ?X=DALLAS
(retrieve)
⇒
There are 2 solutions so far:
  #1: ?X=DALLAS
  #2: ?X=TEXAS
(retrieve)
⇒
There are 3 solutions so far:
  #1: ?X=DALLAS
  #2: ?X=TEXAS
  #3: ?X=AUSTIN
(why)
⇒
1 (CONTAINS SOUTHERN-US AUSTIN)
    follows by Modus Ponens
    with substitution {?l1/SOUTHERN-US, ?l3/AUSTIN, ?l2/TEXAS}
    since 1.1 ! (FORALL (?l1 ?l3)
                   (<= (CONTAINS ?l1 ?l3)
                       (EXISTS (?l2)
                          (AND (CONTAINS ?l1 ?l2)
                               (CONTAINS ?l2 ?l3)))))
    and   1.2 ! (CONTAINS SOUTHERN-US TEXAS)
    and   1.3 ! (CONTAINS TEXAS AUSTIN)

The following query combines a variety of relations that have been entered into the business modules. It retrieves names of companies whose headquarters are in the southern US. Note that query variables that do not appear in the output (i.e., variables not listed after the all

 
(retrieve ?name (exists (?city ?company)
                  (and (contains southern-us ?city)
                       (headquartered-in ?company ?city)
                       (company-name ?company ?name))))
⇒
There is 1 solution so far:
  #1: ?NAME="MegaSoft, Inc."

(why)
⇒
1 (and (COMPANY-NAME MEGASOFT MegaSoft, Inc.)
       (HEADQUARTERED-IN MEGASOFT DALLAS)
       (CONTAINS SOUTHERN-US DALLAS))
    follows by And-Introduction
    since 1.1 ! (COMPANY-NAME MEGASOFT MegaSoft, Inc.)
    and   1.2 ! (HEADQUARTERED-IN MEGASOFT DALLAS)
    and   1.3   (CONTAINS SOUTHERN-US DALLAS)

1.3 (CONTAINS SOUTHERN-US DALLAS)
    follows by Modus Ponens
    and substitution {?l3/DALLAS, ?l2/TEXAS, ?l1/SOUTHERN-US}
    since 1.3.1 ! (forall (?l1 ?l3)
                     (<= (CONTAINS ?l1 ?l3)
                         (exists (?l2)
                            (and (CONTAINS ?l1 ?l2)
                                 (CONTAINS ?l2 ?l3)))))
    and   1.3.2 ! (CONTAINS SOUTHERN-US TEXAS)
    and   1.3.3 ! (CONTAINS TEXAS DALLAS)

[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

3.12 Contexts and Modules

The final feature that we will illustrate in this section is the PowerLoom context mechanism. PowerLoom organizes its knowledge into a hierarchy of logical containers called “contexts”. A PowerLoom context is either a “module”, a somewhat heavyweight object that includes its own symbol table, or a “world”, a very lightweight object designed for fast switching from one world to another. All contexts inherit from a single root context. The most important feature of a context is that a fact asserted into it is inherited by all contexts below it. However, a “parent” context is unaware of any knowledge entered into one of its descendants.

Here we concern ourselves only with modules. We first define a second module, called alternate-business, to be a subcontext of our business module, and then we switch into the new module:

 
(defmodule "ALTERNATE-BUSINESS"
  :includes "BUSINESS")
(in-module "ALTERNATE-BUSINESS")

Next, within the scope of the alternate-business module, we will create a new company. And just for good measure, we will change the name of MegaSoft while we are at it:

 
(assert (and (company web-phantoms)
             (company-name web-phantoms "Web Phantoms, Inc.")))
(retract (company-name megasoft "MegaSoft, Inc."))
(assert (company-name megasoft "MegaZorch, Inc."))

First, here are pairs of companies and company names from the vantage point of the Business module:

 
(in-module "BUSINESS")
(retrieve all (company-name ?x ?y))
⇒
There are 3 solutions:
  #1: ?X=ACME-CLEANERS, ?Y="ACME Cleaners, LTD"
  #2: ?X=MEGASOFT, ?Y="MegaSoft, Inc."
  #3: ?X=MEGASOFT, ?Y="MegaSoft"

Now observe the same query executed from within the alternate Business module:

 
(in-module "ALTERNATE-BUSINESS")
(retrieve all (company-name ?x ?y))
⇒
There are 4 solutions:
  #1: ?X=ACME-CLEANERS, ?Y="ACME Cleaners, LTD"
  #2: ?X=MEGASOFT, ?Y="MegaZorch, Inc."
  #3: ?X=WEB-PHANTOMS, ?Y="Web Phantoms, Inc."
  #4: ?X=MEGASOFT, ?Y="MegaSoft"

We see that all facts pertaining to company names have inherited down from the Business to the Alternate Business module, except for the name for MegaSoft that we explicitly retracted. Also, the new facts asserted within the Alternate Business module appear mixed in with the inherited facts.


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

3.13 Equality Reasoning

PowerLoom makes the unique names assumption, so every two different named logic constants are assumed to be different. For example:

 
(assert (= Fred Joe))
⇒
Derived both TRUE and FALSE for the proposition `|P#|FALSE'.
   Clash occurred in module `|MDL|/PL-KERNEL-KB/PL-USER'.

(assert (= Fred Fred))
⇒
|P|TRUE

However, one can assert equality between skolems that represent function terms as well as between a function term skolem and a regular constant. For example:

 
(deffunction age (?x ?y))
(assert (= (age Fred) (age Joe)))
(assert (= (age Fred) 10))

(retrieve (age Joe ?x))
⇒
There is 1 solution so far:
  #1: ?X=10

So, if one needs to model named individuals where equality might be asserted (e.g., to model a person with an alias) one has to resort to using function terms. For example:

 
(deffunction individual (?name ?i))
(assert (= (age (individual A)) 12))
(assert (= (individual A) (individual B)))

(retrieve (age (individual B) ?a))
⇒
There is 1 solution so far:
  #1: ?A=12

[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

3.14 Classification, Subsumption


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

3.15 Truth Maintenance


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

3.16 Inference Control


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

3.17 Keyword Axioms


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

3.18 Cardinality/Type Reasoning with Frame Predicates


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

3.19 Loom-to-PowerLoom


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

3.20 Deviations from KIF


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

3.21 Differences from Loom


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

3.22 Defaults


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

3.23 Sets, Lists, SETOFALL, KAPPA


[ << ] [ >> ]           [Top] [Contents] [Index] [ ? ]

This document was generated by Hans Chalupsky on October 16, 2010 using texi2html 1.82.