PowerLoom Manual


PowerLoom Manual

Powerful knowledge representation and reasoning with delivery in Common-Lisp, C++, (and, eventually, Java)

This manual describes PowerLoom 1.0.alpha or later.

9 November 1997

The PowerLoom development team

Robert M. MacGregor
Hans Chalupsky
Eric R. Melz
{macgregor,hans,melz}@isi.edu

Copyright (C) 1997 University of Southern California, Information Sciences Institute, 4676 Admiralty Way, Marina Del Rey, CA 90292, USA

Permission is granted to make and distribute verbatim copies of this manual provided the copyright notice and this permission notice are preserved on all copies.

Introduction

This document describes the PowerLoom knowledge representation and reasoning system. PowerLoom is the successor to the Loom knowledge representation system. It provides a language and environment for constructing intelligent applications. PowerLoom uses a fully expressive, logic-based representation language (a variant of KIF). It uses a Prolog-technology backward chainer as its deductive component. The backward chainer is (not yet) a complete theorem prover, but it can handle Horn rules, negation, and simple equality reasoning. Contrary to Prolog, it also handles recursive rules without the risk of infinite recursion. Once the classifier is completed, it will be able to classify descriptions expressed in full first order predicate calculus. PowerLoom uses modules as a structuring device for knowledge bases, and ultra-lightweight worlds to support hypothetical reasoning.

To implement PowerLoom we developed a new programming language called STELLA, which is a Strongly Typed, Lisp-like LAnguage that can be translated into Lisp and C++. STELLA tries to preserve those features of Lisp that facilitate symbolic programming and rapid prototyping, while still allowing translation into readable as well as efficient C++ code. By writing PowerLoom in STELLA, we are able to deliver it in Common-Lisp as well as in C++. Once the STELLA-to-Java translator has been completed, PowerLoom will also become available in Java.

Content Language

PowerLoom uses a variant of KIF (the Knowledge Interchange Format) with object-oriented extensions to express definitional and assertional content. The sentential component of this variant is closest in flavor to that of KIF 3.0 . The main differences are that relations in PowerLoom are (by default) polymorphic, and that variables in quantified sentences and terms can be typed. Not yet supported are logical terms generated by if or cond, the biconditional <=>, and the holds predicate. PowerLoom does not have sequence variables, but it allows the definition of functions and relations with a variable number of arguments. PowerLoom does not support quotation via quote, instead, it will support sentences that take propositional arguments. PowerLoom's definitional language is somewhat more different from its counterpart in KIF 3.0. It has similarities with parts of Ontolingua and is described in more detail in the manual. Future versions of PowerLoom will have translation frontends to support knowledge bases and ontologies written in vanilla KIF or Ontolingua.

Typed Variables

Write me.

Command Interpreter

Currently, the primary means for interacting with PowerLoom is its command interpreter. The command interpreter can be used either interactively, or it can be invoked directly from a program to evaluate individual commands. Future versions of PowerLoom will include additional APIs such as the Generic Frame Protocol (GFP). All PowerLoom commands (see section Commands) can be evaluated using the command interpreter.

The interactive command interpreter is invoked by calling the function powerloom without any arguments. In the distributed C++ version of PowerLoom, this is the top-level function called within the main routine. In the Lisp version, (STELLA::powerloom) has to be called explicitly. However, in Lisp it is not really necessary to use the command interpreter, since all commands can also be executed directly at the Lisp top level.

The interactive command interpreter functions as a simple read/eval/print loop that prompts for input with a |= prompt, reads a user command from standard input, evaluates it, and prints the result to standard output. To exit the command interpreter, type quit or stop.

To evaluate commands directly from a program, the following evaluator functions can be used:

Function: evaluate ((expression OBJECT)) : OBJECT TYPE-SPEC BOOLEAN
Evaluate the expression expression and return the result. Currently, only the evaluation of (possibly nested) commands and global variables is supported. The second return value indicates the actual type of the result (which might have been wrapped), and the third return value indicates whether an error occurred during the evaluation.

Function: evaluate-string ((expression STRING)) : OBJECT TYPE-SPEC BOOLEAN
Evaluate the expression represented by expression and return the result. This is equivalent to (evaluate (unstringify expression)).

Commands

This chapter lists all available PowerLoom commands alphabetically. Each command is documented with its name, a (possibly empty) list of parameters specified as (<name> <type>) pairs, its return type, and its command type which can be either Command or N-Command. Regular commands do evaluate their arguments (similar to a Lisp or C++ function), while N-Commands do not (similar to a Lisp macro). For example, the command in-dialect is defined as follows:

N-Command: in-dialect ((dialect NAME)) : KEYWORD
Change the current logic dialect to dialect. Currently supported dialects are KIF, STELLA, and PREFIX-STELLA. The STELLA dialects are not recommended for the construction of knowledge bases, they are mainly used internally by PowerLoom.

This means that it takes one parameter called dialect of type NAME, returns a STELLA KEYWORD as its result, and, since it is an N-Command, does not evaluate its arguments.

Commands can also have &rest parameters (similar to Lisp functions). These are either used to allow a variable number of arguments, or to handle optional arguments, since STELLA does not directly support optional arguments.

Here is a list of important parameter types used in the command specifications below:

Here is the list of all available PowerLoom commands:

N-Command: all-facts-of ((name NAME)) : (LIST OF PROPOSITION)
Return a list of all definite (TRUE or FALSE) propositions that reference the logic-object named name.

N-Command: ask ((proposition PARSE-TREE)) : BOOLEAN
Perform inference to determine whether proposition is true. Return TRUE if proposition was found to be true; return NULL otherwise. KIF example: (ask (happy Fred)) will return TRUE if Fred was indeed found to be happy. Note, that for this query to run, the logic constant Fred and the relation (or slot) happy must already be defined (see assert). Use (set/unset-feature goal-trace) to en/disable goal tracing of the inference engine.

N-Command: assert ((proposition PARSE-TREE)) : OBJECT
Assert the truth of proposition. Return the asserted proposition object. KIF example: (assert (happy Fred)) asserts that Fred is indeed happy. Note, that for this assertion to succeed, the logic constant Fred must already be defined, e.g., as a side-effect of a type assertion such as (assert (Person Fred)), and the relation (or slot) happy must be defined on objects of Freds type, e.g., on the class Person.

N-Command: cc (&rest (name NAME)) : CONTEXT
Change the current context to the one named name. Return the value of the new current context. If no name is supplied, return the value of *context*. cc is a no-op if the context reference cannot be successfully evaluated.

N-Command: clear-instances (&rest (name NAME)) :
Destroy all instances belonging to module name or any of its children. If no name is supplied, the current module will be cleared after confirming with the user.

N-Command: clear-module (&rest (name NAME)) :
Destroy all objects belonging to module name or any of its children. If no name is supplied, the current module will be cleared after confirming with the user. Important modules such as STELLA are protected against accidental clearing.

N-Command: conceive ((proposition PARSE-TREE)) : PROPOSITION
Build proposition without asserting its truth value. Return the conceived proposition object. KIF example: (conceive (happy Fred)) builds the proposition expressing that Fred is happy without explictly asserting or denying it. Note, that for this to succeed, the logic constant Fred and the relation (or slot) happy must already be defined (see assert).

Command: copyright () :
Print detailed PowerLoom copyright information.

N-Command: create ((type GENERALIZED-SYMBOL) &rest (name GENERALIZED-SYMBOL)) : LOGIC-OBJECT
Create a logic object of logical type type and return it. If name is also supplied, convert it into a surrogate and bind it to the newly created object.

N-Command: defclass (&rest (args PARSE-TREE)) : CLASS
Define (or redefine) a class. The accepted syntax is:

  (defclass <class-name> (<superclass-name>*)
     [:documentation <docstring>]
     [:self-variable <var>]
     [[{:definition | :is} <relation-expression>] |
      [<=> <sentence-with-argument-variables>]]
     [:axioms {<sentence> | (<sentence>+)}]
     [:constraints {<sentence-with-argument-variables> |
                    (<sentence-with-argument-variables>+)}]
     [:sort? {TRUE | FALSE}]
     [:properties <list-of-properties>]
     [:meta-attributes <list-of-key-value-pairs>]
     [:slots ({(<slot-name> <slot-options>*)}*)]
     [<other-options>*])

<slot-options> is a list of keyword/value pairs. The set of legal slot options is the same as those accepted by defrelation. Unless the :sort? option specifies otherwise, classes defined with defclass are assumed to be sorts, i.e., the extensions of two sibling classes that don't share a common subclass are assumed to be disjoint. CAUTION: The semantics of sorts is still somwhat in flux.

N-Command: defconcept (&rest (args PARSE-TREE)) : CLASS
Define (or redefine) a class that is not a sort. The accepted syntax is identical to that of defclass. The only difference is that the value of the :sort? option will always be forced to be FALSE. This means that unrestricted inference might be used to determine whether a particular object is an instance of a non-sortal class defined with defconcept, since no disjointness assumptions can be made. For example, suppose a hierarchy contains the classes Human and Featherless-Biped which share a common superclass, say Living-Thing. If the two classes were defined as sorts, their extensions are assumed to be disjoint. Thus, even if we have a rule

  (forall (?x Living-Thing)
     (=> (and (Featherless ?x) (Biped ?x))
         (Featherless-Biped ?x)))

and Humans are in fact featherless and bipeds, we will not be able to infer Humans to be Featherless-Bipeds. However, if Featherless-Biped was defined with defconcept, the rule will become applicable, since now Humans and Featherless-Bipeds are not necessarily disjoint anymore. CAUTION: The semantics of sorts is still somwhat in flux.

N-Command: deffunction (&rest (args PARSE-TREE)) : RELATION
Define (or redefine) a logic function. The accepted syntax is:

  (deffunction {<function-name> |
                (<function-name> <value-type>)} (<var>+)
     [:documentation <docstring>]
     [:-> <value-variable>]
     [:type <value-type>]
     [[{:definition | :is} <relation-expression>] |
      [<=> <sentence-with-argument-variables>] |
      [:= <term-expression-with-argument-variables>]]
     [:polymorphic? {TRUE | FALSE}]
     [:axioms {<sentence> | (<sentence>+)}]
     [:constraints {<sentence-with-argument-variables> |
                    (<sentence-with-argument-variables>+)}]
     [:properties <list-of-properties>]
     [:meta-attributes <list-of-key-value-pairs>]
     [<other-options>*])

Function parameters can be typed or untyped. An untyped first parameter or a :polymorphic? FALSE specification defines a non-polymorphic function. Otherwise, the function will be polymorphic. If a value variable is specified, it must be specified before any definition options, otherwise, the expansions of definitions might be incorrect. The default KIF value variable is ?value.

N-Command: defmodule ((name NAME) &rest (options OBJECT)) :
Define (or redefine) a module named name. The accepted syntax is:

  (defmodule <module-name>
     [:documentation <docstring>]
     [:includes {<module-name> | (<module-name>*)}]
     [:uses {<module-name> | (<module-name>*)}]
     [:package <package-name-string>]
     [:case-sensitive? {TRUE | FALSE}]
     [:shadow (<symbol>*)])
     [<other-options>*])

name can be a string or a symbol. The list of modules specified in the :includes option plus (if supplied) the parent in the path used for name become the new module's parents. If no :uses option was supplied, the new module will use the STELLA module by default, otherwise, it will use the set of specified modules. :package specifies the name of a native package or name space in which symbols of the module should be allocated when they get translated into a native language such as Lisp or C++. By default, Lisp symbols are allocated in the STELLA package, and C++ names are translated without any prefixes. If :case-sensitive? is supplied as TRUE, symbols in the module will be interned case-sensitively, otherwise (the default), they will be converted to uppercase before they get interned. Modules can shadow definitions of functions and classes inherited from parents or used modules. Shadowing is done automatically, but generates a warning unless the shadowed type or function name is listed in the :shadow option of the module definition. CAUTION: The implementation of shadowing is still somewhat fragile.

Examples:

  (defmodule "/PL-USER"
    :uses ("LOGIC" "STELLA")
    :package "PL-USER")

  (defmodule /PL-USER/GENEALOGY)

Modules include objects from other modules via two separate mechanisms: (1) they inherit from their parents specified via the :includes option and/or a fully qualified module name, and (2) they inherit from used modules specified via the :uses option. The main difference between the two mechanisms is that inheritance from parents is transitive, while uses-links are only followed one level deep. I.e., a module A that uses B will see all objects of B (and any of B's parents) but not see anything from modules used by B. Another difference is that only objects declared as public can be inherited via uses-links (this is not yet enforced). Note that - contrary to Lisp - there are separate name spaces for classes, functions, and variables. For example, a module could inherit the class CONS from the STELLA module, but shadow the function of the same name. CAUTION: The implementation of this semantics has not yet been fully completed.

N-Command: defrelation (&rest (args PARSE-TREE)) : RELATION
Define (or redefine) a logic relation. The accepted syntax is:

  (defrelation {<relation-name> | 
                (<relation-name> BOOLEAN)} (<var>+)
     [:documentation <docstring>]
     [:type BOOLEAN]
     [[{:definition | :is} <relation-expression>] |
      [<=> <sentence-with-argument-variables>]]
     [:polymorphic? {TRUE | FALSE}]
     [:axioms {<sentence> | (<sentence>+)}]
     [:constraints {<sentence-with-argument-variables> |
                    (<sentence-with-argument-variables>+)}]
     [:properties <list-of-properties>]
     [:meta-attributes <list-of-key-value-pairs>]
     [<other-options>*])

Relation parameters can be typed or untyped. An untyped first parameter or a :polymorphic? FALSE specification defines a non-polymorphic relation. Otherwise, the relation will be polymorphic.

N-Command: defrule ((ruleName NAME) (rule PARSE-TREE)) : PROPOSITION
Define (or redefine) a rule (any axiom) named ruleName. If an axiom with that name already exists, replace it with the new axiom rule.

N-Command: demo (&rest (fileandpause OBJECT)) :
Read logic commands from a file, echo them verbatimly to standard output, and evaluate them just as if they had been typed in interactively. When called with no arguments, present a menu of example demos, otherwise, use the first argument as the name of the file to demo. Pause for user confirmation after each expression has been read but before it is evaluated. Pausing can be turned off by suppling FALSE as the optional second argument, or by typing c at the pause prompt. Typing ? at the pause prompt prints a list of available commands.

N-Command: deny ((proposition PARSE-TREE)) : PROPOSITION
Assert the falsity of proposition. Return the asserted proposition object. KIF example: (deny (happy Fred)) asserts that Fred is not happy, which could have been done equivalently by (assert (not (happy Fred))). Note, that for this to succeed, the logic constant Fred and the relation (or slot) happy must already be defined (see assert).

N-Command: help (&rest (commands SYMBOL)) :
Describe specific commands, or print a list of available commands.

N-Command: in-dialect ((dialect NAME)) : KEYWORD
Change the current logic dialect to dialect. Currently supported dialects are KIF, STELLA, and PREFIX-STELLA. The STELLA dialects are not recommended for the construction of knowledge bases, they are mainly used internally by PowerLoom.

N-Command: in-module ((name NAME)) : MODULE
Change the current module to the module named name.

Command: load ((file STRING)) :
Read logic commands from file and evaluate them.

Command: print-features () :
Print the currently enabled and available PowerLoom environment features.

N-Command: propagate-constraints (&rest (name NAME)) :
Trigger constraint propagation over all propositions of module name. If no name is supplied, the current module will be used. This also enables incremental constraint propagation for future monotonic updates to the module. Once a non-monotonic update is performed, i.e., a retraction or clipping of a function value, all cached inferences will be discarded and constraint propagation will be turned off until this function is called again.

Command: reset-features () : (LIST OF KEYWORD)
Reset the PowerLoom environment features to their default settings.

N-Command: retract ((proposition PARSE-TREE)) : PROPOSITION
Retract the truth of proposition. Return the retracted proposition object. KIF example: (retract (happy Fred)) retracts that Fred is happy. Note, that for this to succeed, the logic constant Fred and the relation (or slot) happy must already be defined (see assert).

N-Command: retract-facts-of ((name NAME)) :
Retract all definite (TRUE or FALSE) propositions that reference the logic-object named name.

N-Command: retrieve (&rest (query PARSE-TREE)) : QUERY-ITERATOR
Retrieve elements of a relation (tuples) that satisfy a proposition. The accepted syntax is:

  (retrieve [<integer> | all]
            [{<variable-spec> | (<variable-spec>+)}
             [<proposition>]])

The variables and proposition are similar to an exists sentence or kappa term without the quantifier. <proposition> usually contains references to the listed variables. No other free variable references are allowed. If <proposition> is omitted, it defaults to TRUE.

A solution is a set of bindings for the listed variables for which <proposition> is true. The optional first argument controls how many solutions should be generated before control is returned. The keyword all indicates that all solutions should be generated. By default, retrieve returns after it has found one new solution or if it cannot find any more solutions.

retrieve returns an iterator which saves all the necessary state of a query and stores all generated solutions. When used interactively, the returned iterator will print out with the set of solutions collected so far. Calling retrieve without any arguments (or only with the first argument) will generate one (or more) solutions to the most recently asked query.

KIF examples:

  (retrieve (?x Person) (happy ?x)) 

will try to find the next happy person and store it in the returned query iterator.

  (retrieve 10 (?x Person) (happy ?x))

will try to find 10 happy people.

  (retrieve 10)

will try to find the next 10 happy people.

  (retrieve all (?x Person) (happy ?x))

will find all happy people.

  (retrieve all (?x Person))

will find all people.

  (retrieve (?x Person) (or (happy ?x) (parent-of Fred ?x)))

will try to find the next person that is happy or has Fred as a parent.

  (retrieve ((?x Person) (?y Person)) (parent-of ?x ?y))

will try to find the next pair of parent/child.

  (retrieve all (?x Person)
            (exists (?y Person) (parent-of ?x ?y)))

will generate the set of all parents. Note, that for these queries to run, the class Person, the relations happy and parent-of, and the logic constant Fred must already be defined (see assert).

Use (set/unset-feature goal-trace) to en/disable goal tracing of the inference engine.

N-Command: save-module ((name NAME) (file STRING)) :
Save all definitions and assertions of module name to file.

N-Command: set-feature (&rest (features NAME)) : (LIST OF KEYWORD)
Enable the PowerLoom environment feature(s) named by features. Return the list of enabled features. Calling set-feature without any arguments can be used to display the currently enabled features. The following features are supported:

closed-world: Enables closed-world reasoning. NOT YET IMPLEMENTED!

goal-trace: Enables the generation of goal trace information during inference.

N-Command: unassert ((proposition PARSE-TREE)) :
Retract the truth or falsity of proposition. This is a more general version of retract that also handles falsity.

N-Command: unset-feature (&rest (features NAME)) : (LIST OF KEYWORD)
Disable the PowerLoom environment feature(s) named by features. Return the list of enabled features. Calling unset-feature without any arguments can be used to display the currently enabled features. See set-feature for a description of supported features.

Function Index

a

  • all-facts-of
  • ask
  • assert
  • c

  • cc
  • clear-instances
  • clear-module
  • conceive
  • copyright
  • create
  • d

  • defclass
  • defconcept
  • deffunction
  • defmodule
  • defrelation
  • defrule
  • demo
  • deny
  • e

  • evaluate
  • evaluate-string
  • h

  • help
  • i

  • in-dialect, in-dialect
  • in-module
  • l

  • load
  • p

  • print-features
  • propagate-constraints
  • r

  • reset-features
  • retract
  • retract-facts-of
  • retrieve
  • s

  • save-module
  • set-feature
  • u

  • unassert
  • unset-feature

  • This document was generated on 9 November 1997 using the texi2html translator version 1.51.