Ontolingua Reference Manual

Content

• Introduction
• Functions and Macros
• Variables

Introduction

This is the Ontolingua Reference Manual in hypertext.

Ontolingua consists of a KIF parser, tools for analyzing ontologies, and a set of translators for converting Ontolingua sources into forms acceptable to implemented knowledge representation systems. Currently supported target representation systems are: (:LOOM :EPIKIT :GENERIC-FRAME :KIF)

A set of example ontologies may be found in the examples subdirectory of the Ontolingua release directory tree (which is rooted at /tmp_mnt/vol/c/htw/ontolingua/).
You can load them using ordinary Lisp load, which has been modified to do the right thing for ontolingua ontologies.

You can analyze a loaded ontology with the function (XREF-THEORY <theory-name>)
This will do a two-pass cross-reference of the ontology, pointing out problems with the definitions and generating a report on dependencies among theories. XREF-THEORY uses the :KIF implementation for storing definitions. If you're current target implementation is something else, like :LOOM, then XREF-THEORY might ask you for file in which the ontology resides so that it can translate the file into :KIF for analysis.

To translate into an implemented representation system, use (OL:IN-IMPLEMENTATION <target system name>)
and then load a file or buffer containing definitions. For example (in-implementation :LOOM) causes output from Ontolingua to go to LOOM.

Another way (new) to translate entire files is the command (OL:TRANSLATE-FILE <file name>)
which sends output to a file rather than calling the target system in memory. This which works even if the target representation system is not loaded.

Setting the variable *ONTO-TRACE* to a stream or :print-only will produce a trace of the translation for debugging.

If you use the ILISP interface from within GNU Emacs, you can get Ontolingua translations directly from your buffer containing the definitions. It's best to load the ontology file before examining individual definitions from emacs, to ensure that the required theories have been created. See the README.TEXT under the tools subdirectory for more information on installing and using the ILISP commands in Ontolingua.

See the reference manual (reference-manual.text in the doc subdirectory) and the documentation strings on Ontolingua functions and variables for more information. The list of exported symbols for Ontolingua can be obtained by calling this function with with a true argument: (ol:onto-help t).

Functions And Macros

• Clear-Theory
• Create-Axiom
• Create-Class
• Create-Function
• Create-Instance
• Create-Relation
• Create-Theory
• Define-Axiom
• Define-Class
• Define-Frame
• Define-Function
• Define-Instance
• Define-Relation
• Define-Theory
• Delete-Theory
• Delete-Theory-And-Children
• Find-Theory
• Htmlify-Directory
• Implementation-P
• In-Implementation
• In-Theory
• Onto-Help
• Onto-Load
• Reset-Implementation
• Theory-Equal-P
• Theory-P
• Translate-File
• Uninclude-Theory
• Xref-Theory
• Xref-Theory-To-File

Variables

• *All-Implementations*
• *All-Theories*
• *Current-Theory*
• *Disable-Theory-Switching-Side-Effects*
• *Implementation*
• *Onto-Trace*
• *Supported-Second-Order-Relations*
• *Translation-Output-Stream*

Function Clear-Theory

Resets the specified theory, effectively removing definitions and other facts. Does not alter includees or includers of the specified theory.

<theory> may be any object acceptable to FIND-THEORY. If unspecified,

the current theory is assumed (see IN-THEORY.)

If <theory> is not a theory object, <implementation> will be examined to determine which implementation of the specified theory should be cleared. <implementation> should be a symbol (usually a keyword) which names an OntoLingua implementation; if unspecified, the current implementation is assumed (see IN-IMPLEMENTATION.)

Function Create-Axiom

(create-axiom <axiom-name> 
   [:docucmentation <docstring>] 
   := <sentence> 
   [:theory <theory-name>] 
   [:implementation <target-system-name>] 
   [:issues <issue-tree>]) 

Allows one to assert an arbitrary axiom in an ontology. Most axioms can be associated with a definition, and belong there. Some axioms involve several basic terms and are central to the theory being specified by the ontology. Such axioms are given with this form. See also DEFINE-AXIOM, which is the macro form.

<axiom-name> should be a symbol which names the axiom being defined.

The various keyword arguments may occur in any order, and are described below:

:= - The value of this keyword argument should be a KIF sentence which embodies the axiom to be defined.

:DOCUMENTATION - The value of this keyword argument should be a string which describes the axiom being defined. It will be stored as the Lisp documentation (of type OL:ONTO-AXIOM) for the symbol which names the axiom.

:THEORY - The value of this keyword argument should be a symbol which names the theory in which the axiom should be defined. If the :THEORY argument is not supplied, the current theory is assumed (see IN-THEORY.)

:IMPLEMENTATION - The value of this keyword argument should be a symbol (usually a keyword) which names the target representation system in which the axiom should be defined. This is independent of the theory in which the axiom is defined. If the :IMPLEMENTATION argument is not supplied, the current implementation is assumed (see IN-IMPLEMENTATION.)

:ISSUES - The value of this argument should be a Lisp "tree" of strings. It is ignored by the translators, and is meant to provide a standard place for ontology authors to add human readable annotatations to their definitions.

Function Create-Class

(create-class <class-name> (<var>) 
   [:documentation <docstring>] 
   {:def | :iff-def} <sent-with-arg-vars> 
   [:constraints <sent-with-arg-vars>] 
   [:equivalent <sent-with-arg-vars>] 
   [:sufficient <sent-with-arg-vars>] 
   [:default-constraints <sent-with-arg-vars>] 
   [:axiom-def <sent-without-arg-vars>] 
   [:axiom-constraints <sent-without-arg-vars>] 
   [:axiom-defaults] 
   [:theory <theory-name>] 
   [:implementation <target-system-name>] 
   [:class-slots (<slot-spec>*)] 
   [:instance-slots (<extended-slot-spec>*)] 
   [:default-slot-values (<slot-spec>*)] 
   [:issues <issue-tree>]) 

Defines an OntoLingua class. See also DEFINE-CLASS, which is the macro form.

<class-name> should be a symbol which names the class being defined.

OntoLingua will convert this symbol into a format which is appropriate for the selected target representation system during translation (e.g., if one were translating into CycL, the symbol would be converted into a string which would obey the CycL conventions for case and word delimiters.)

<argument-list> should be a list of a single symbol; within the

sentences in the body of the DEFINE-CLASS form, this symbol is treated as a variable bound to an instance of the class. The current KIF convention is to use a symbol which begins with a "?", but since OntoLingua converts all variables to this format internally it is not strictly necessary to adhere to this convention.

<docstring> when provided, should be a string which describes the

class being defined. It will be stored as the Lisp documentation (of type OL:ONTO-CLASS) for the symbol which names the class. If a docstring is provided, it must immediately follow the argument list.

The various keyword arguments may occur in any order, and are described below:

:DEF - The value of this keyword argument should be a KIF sentence

that "defines" the class; that is, a KIF sentence using the argument symbol as a free variable that holds over all instances of the class. The purpose of the :DEF sentence is to specify constraints on consistent use of the class; it should reflect the textual definition given in the docstring. Some implementations make special use of sentences labeled as definitions.

Logically, the :DEF sentence is implied by membership in the class, and membership in a class is specfied by something satisfying a unary precicate. That is, the :DEF sentence is a necessary condition for class membership. For example,

        (define-class human (?human) 
          "The human animal." 
          :def (animal ?human)) 

is logically equivalent to

        (=> (human ?human) 
            (animal ?human)) 

It also is way of saying that human is a subclass of animal (human is subsumed by animal).

:IFF-DEF - The value of this keyword argument should be a KIF

sentence that "completely defines" the class. This is just like the :DEF keyword, except that the sentence specifies both necessary and sufficient conditions for membership in the class. For example:

        (define-class female-person (?person) 
          "female humans" 
          :iff-def (and (human ?person) 
                        (= (gender ?person) female))) 

specifies that

        (<=> (female-person ?person) 
             (and (human ?person) (gender ?person))) 

and that this fact is the definition of (what it means to be) a female-person.

It is not legal use both the :DEF and :IFF-DEF keyword arguments in the same definition.

:CONSTRAINTS - The value of this keyword argument should be a KIF

sentence which specifies necessary constraints on membership in the class that are not meant as part of the definition. The :CONSTRAINTS sentence says what is true of all instances. One can also think of the :CONSTRAINTS sentence as a (monotonically) inherited fact about instances.

:CONSTRAINTS sentences are logically equivalent to :DEF sentences, and take the same form (i.e., sentences with terms that include the free variable from ARGUMENT-LIST.) The purpose of the distinction between definitional and nondefinitional constraints is to support terminological reasoning apart from other kinds of deductive inference. The :CONSTRAINTS sentence is an assertion used in nonterminological inference, such as inheritence of sentences that would be checked on the creation of instances.

A list of sentences may be supplied instead of a single sentence; OntoLingua will automatically construct a conjunction of all the supplied :CONSTRAINTS sentences in this case.

:SUFFICIENT - The value of this keyword argument should be a KIF

sentence that specifies sufficient constraints for membership in the class; it may be used as a backward chaining deductive rule whose consequent is an instantiation of the class.

A list of sentences may be supplied instead of a single sentence; OntoLingua will automatically construct a disjunction of all the supplied :SUFFICIENT sentences in this case.

:EQUIVALENT - The value of this keyword should be a list of KIF

sentences that specify facts that are both necessary and sufficient for class membership, but are not meant as part of the definition of the class.

:EQUIVALENT sentences are logically equivalent to :IFF-DEF sentences. The purpose of the distinction between definitional and nondefinitional constraints is to support terminological reasoning apart from other types of deductive inference. The :EQUIVALENT sentences are assertions used in nonterminological inference.

:DEFAULT-CONSTRAINTS - The value of this keyword argument should be

a list of KIF sentences that specify what "follows by default" from membership in the class. The precise operational semantics of nonmonotonic inference will depend on the target representation system. The intended use of :DEFAULT-CONSTRAINTS is to specify "default inheritance" of facts about instances of the class. The :DEFAULT-CONSTRAINTS sentences have the the same form as the :DEF and :CONSTRAINTS sentences.

When it is asserted that an individual is an instances of the class, then each of the :DEFAULT-CONSTRAINTS sentences will hold ("by default") with the ARGUMENT-LIST variable bound to that individual, until and unless a sentence that contradicts that :DEFAULT-CONSTRAINTS sentence is asserted for that individual. For example:

        (define-class american (?person) 
           :default-constraints (owns-tv ?person)) 

specifies

        (=> (american ?person) 
            (<= (owns-tv ?person)  
                (not (provable (not (owns-tv ?person)))))) 

:AXIOM-DEF - The value of this keyword should be KIF sentence; it

will be asserted along with the definition. Logically, this sentence neither implies nor is implied by membership in the class being defined; it is a standalone sentences. It should mention the class being defined, however. If this axiom happens to mention the variables in ARGUMENT-LIST, then these variables are treated like any other unquantified KIF variables: they are assumed to be universally quantified. Thus, it is confusing to use the ARGUMENT-LIST variables in the :AXIOM-DEF sentence.

The :AXIOM-DEF sentence is considered to be definitional. That is, it is part of the definition as are :DEF and :IFF-DEF sentences.

A list of sentences may be supplied instead of a single sentence; OntoLingua will automatically construct a conjunction of all the supplied :AXIOM-DEF sentences in this case.

:AXIOM-CONSTRAINTS - The value of this keyword should be a KIF

sentence that is a standalone sentence not related to the variables in ARGUMENT-LIST. This is the same as the :AXIOM-DEF sentence except it is nonterminological -- outside of the definition.

A list of sentences may be supplied instead of a single sentence; OntoLingua will automatically construct a conjunction of all the supplied :AXIOM-CONSTRAINTS sentences in this case.

:AXIOM-DEFAULTS - the value of this keyword should be a list of KIF

sentences with are not related to the variables in ARGUMENT-LIST. They should mention the class being defined, however. Each of these sentences is taken to hold until and unless a contradictory sentence is asserted.

:THEORY - The value of this keyword argument should be a symbol

which names the theory in which the class should be defined. If the :THEORY argument is not supplied, the current theory is assumed (see IN-THEORY.)

:IMPLEMENTATION - The value of this keyword argument should be a

symbol (usually a keyword) which names the target representation system in which the class should be defined. This is independent of the theory in which the class is defined. If the :IMPLEMENTATION argument is not supplied, the current implementation is assumed (see IN-IMPLEMENTATION.)

:ISSUES - The value of this argument should be a Lisp "tree" of

strings. It is ignored by the translators, and is meant to provide a standard place for ontology authors to add human readable annotatations to their definitions.

:CLASS-SLOTS, :INSTANCE-SLOTS, and :DEFAULT-SLOT-VALUES - These

keyword arguments are discussed below, under "Alternate Slot Syntax."

Second Order Sentences

Within the :AXIOM-DEF there may be sentences that specify properties of the class being defined, denoted by CLASS-NAME, rather than properties of instances of the class, denoted by the variable in ARGUMENT-LIST. Such sentences use the names of relations as arguments to special "second order" relations.

In the following example, human is defined as a subclass-of animal, which was previously stated in a first-order style above.

      (define-class human (?human) 
        "The human animal." 
        :axiom-def (subclass-of human animal)) 

Alternate Slot Syntax

OntoLingua supports additional syntax for writing some definition sentences in a frame/slot style instead of the predicate calculus style of KIF. This additional syntax is supported via three additional keyword arguments, whose values should be lists of sentences in the following format:

      (slot-name slot-value1 slot-value2 ...)  

SLOT-NAME is the name of a binary relation. The first argument to this binary-relation (the frame) is made implicit by the keyword with which the sentence is associated, and each SLOT-VALUE is a second argument to the relation.

During the translation process, OntoLingua will transform such a sentence into the equivalent KIF sentences

      (slot-name frame slot-value-1) 
      (slot-name frame slot-value-2)... 

These resulting sentences will be added to the :DEF, :IFF-DEF,

:CONSTRAINTS, or :DEFAULT-CONSTRAINTS sentences depending on the

keyword with which the original slot-syntax sentences are associated.

The three keyword arguments supported in this manner are as follows:

:CLASS-SLOTS - The value of this keyword should be a list of slot sentences whose frames are taken to be the class being defined. Thus, the relations corresponding to the slot names are

      second-order relations (see "Second Order Sentences" above.) 

Sentences translated from :CLASS-SLOTS are added to the :DEF or

      :IFF-DEF sentence. 

:INSTANCE-SLOTS - The value of this keyword should be a list of slot sentences whose frames are taken to be the instances of the class being defined. Sentences translated from :INSTANCE-SLOTS are added to the :CONSTRAINTS sentence.

An extended slot syntax is supported for this keyword which allows values for "facets" of slots to be provided. Within the SLOT-VALUE-SPECS any of the slot-values may be a list of the

      form: 

         (facet facet-value1 facet-value2...). 

OntoLingua will transform these into the equivalent KIF

      sentences: 

         (facet class slot facet-value1) 
         (facet class slot facet-value2) 

...

:DEFAULT-SLOT-VALUES - The value of this keyword should be a list of slot sentences whose frames are taken to be the instances of the class being defined. Sentences translated form

      :DEFAULT-SLOT-VALUES are added to the :DEFAULT-CONSTRAINTS 

sentences, and will therefore hold for each instance of the class until and unless a contrary assertion is made about that instance.

Function Create-Function

(create-function <function-name> (<var>+) [:-> <var>] 
   [:documentation <docstring>] 
   [:when <sent-with-arg-vars>] 
   [{:def | :iff-def} <sent-with-arg-vars>] 
   [:constraints <sent-with-arg-vars>] 
   [:axiom-def <sent-without-arg-vars>] 
   [:axiom-constraints <sent-without-arg-vars>] 
   [{{:lambda-body | :=} <term-expression-with-arg-vars>} | 
    {:lisp-body <lisp-function-body-using-arg-vars>}] 
   [:theory <theory-name>] 
   [:implementation <target-system-name>] 
   [:issues <issue-tree>]) 

Defines an OntoLingua function. See also DEFINE-FUNCTION, which is the macro form.

<function-name> should be a symbol which names the function being

defined. OntoLingua will convert this symbol into a format which is appropriate for the selected target representation system during translation (e.g., if one were translating into CycL, the symbol would be converted into a string which would obey the CycL conventions for case and word delimiters.)

<argument-list> should be a list of symbols which serve as the

arguments to the function. Within the body of the DEFINE-FUNCTION form, there may be KIF sentences which refer to these symbols as variables in order to establish the constraints between the arguments to the function being defined and its value. Such constraints constitute the definition of an OntoLingua function. The symbols in ARGUMENT-LIST may also be used as formal arguments in a procedural attachment.

:-> - The value of this keyword argument should be a symbol which will

be used to represent the result of the function within the KIF sentences of the definition. It is not necessary to explicitly supply a result variable to talk about the result of the function; the term formed by prepending the FUNCTION-NAME to the ARGUMENT-LIST may be used within the KIF sentences of the definition to stand for a nameless result variable. If this keyword argument is supplied, however, it must immediately follow the argument list.

<docstring> when provided, should be a string which describes the

function being defined. It will be stored as the Lisp documentation (of type OL:ONTO-FUNCTION) for the symbol which names the function. If a docstring is provided, it must immediately follow the :-> argument (or immediately follow the argument list if no :-> argument is provided.)

The remaining keyword arguments may occur in any order, and are described below:

:DEF - The value of this keyword argument should be a KIF sentence

which refers to the free variables in ARGUMENT-LIST and the RESULT-VARIABLE. Logically, the :DEF sentence is "implied by" the function; i.e. the :DEF sentence holds for every variable binding such that the value of the function when applied to the variables in ARGUMENT-LIST is the value of the RESULT-VARIABLE.

:IFF-DEF - The value of this keyword argument should be a list of

KIF sentences which refer to the free variables in ARGUMENT-LIST and the RESULT-VARIABLE. Logically, the :IFF-DEF sentence both "implies" and "is implied by" the function; i.e. in addition to the property ascribed to the :DEF sentence above, for every variable binding such that the :IFF-DEF sentence holds, the value of the function applied to the variables in ARGUMENT-LIST is the value of the RESULT-VARIABLE.

It is not permisible to use both the :DEF and :IFF-DEF keywords within a single DEFINE-FUNCTION form.

:CONSTRAINTS - The value of this keyword argument should be a list

of KIF sentences which refer to the free variables in the ARGUMENT-LIST and the RESULT-VARIABLE that are not meant as part of the definition.

:CONSTRAINTS sentences are logically equivalent to :DEF sentences. The purpose of the distinction between definitional and nondefinitional constraints is to support terminological reasoning apart from other types of deductive inference. The :CONSTRAINTS sentences are assertions used in nonterminological inference.

A list of sentences may be provided instead of a single sentence; OntoLingua automatically constructs a conjunction of all the supplied :CONSTRAINTS sentences in this case.

:LAMBDA-BODY or :=

- The value of this keyword argument should be a KIF term expression (a sentence denoting and object, not a truth value) which, when given bindings for the variables in ARGUMENT-LIST, can produce a value for the function. Logically, the fact that the result variable is equivalent to the :LAMBDA-BODY expression implies and is implied by the fact that the value of the function applied to the variables in ARGUMENT-LIST is the value of the RESULT-VARIABLE, for all variable bindings.

For example, the following form defines the 'feature value' of a feature in a simulation:

        (define-function val (?feature ?step) :-> ?value 
          "function which returns the value of a DSL feature.  
           It dispatches on the type of the feature." 

          :DEF (and (feature ?feature)  
                    (timepoint ?step)  
                    (feature-value ?value)) 
          :LAMBDA-BODY (cond ((constant-feature ?feature)  
                              (initial-value ?feature)) 
                             ((connected-feature ?feature)  
                              (val (source ?feature) ?step)) 
	                     ((functional-feature ?feature)  
                              (valcompute ?feature ?step)) 
	                     ((markov-feature ?feature) 
	                      (if (= ?step 1)  
                                  (initial-value ?feature) 
                                  (valcompute ?feature (1- ?step)))))) 

:LISP-BODY is a Lisp expression that returns the value of the

function when evaluated in an environment where the variables in RESULT-VARIABLE are bound. Within the :LISP-BODY expression, references to a function with FUNCTION-NAME work as expected; OntoLingua takes care of the mechanism by which Lisp function are defined and connected to KIF functions. "Appropriate" procedural attachment may take place, depending on the target representation system.

In the following example, the Lisp function INTPOWER is defined and it is related to the function constant INTPOWER in such a way that a query of the form '(= ?x (intpower 2 3)) will bind the result 8 to the variable ?x:

        (define-function intpower (?x ?y) :-> ?result 
          "Function which returns X to the power Y. Where Y is an Integer." 
          :def (and (integer ?x) (integer ?y) (integer ?result)) 
          :lisp-body (if (<= ?y 0) 1 (* ?x (intpower ?x (1- ?y)))) 

It is not permisible to use both :LAMBDA-BODY and :LISP-BODY keywords within the same DEFINE-FUNCTION form.

:AXIOM-DEF - The associated value should be a KIF sentence

to be asserted along with the definition of the function. Logically, this sentence stands alone, and has no relation to the variables in ARGUMENT-LIST or the RESULT-VARIABLE. Terminologically, this sentence is considered definitional.

Second order sentences may be specified here (see Second Order Sentences, under DEFINE-RELATION.)

For example:

       (define-function identity (?anything) :-> ?same-thing 
         "returns its argument." 
         :lambda-body ?anything	 
         :axiom-def (and (symmetric-function identity) 
                         (transitive-function identity))) 

The fact that the function identity is symmetric and transitive is considered to be part of the definition of identity.

A list of sentences may be supplied instead of a single sentence; OntoLingua will automatically construct a conjunction of all the supplied :AXIOM-DEF sentences in this case.

:AXIOM-CONSTRAINTS - The associated value should be a KIF sentence

that is a standalone sentence not related to the variables in ARGUMENT-LIST. This is the same as the :AXIOM-DEF sentence except that is it nonterminological -- outside of the definition.

A list of sentences may be supplied instead of a single sentence; OntoLingua will automatically construct a conjunction of all the supplied :AXIOM-CONSTRAINTS sentences in this case.

:THEORY - The value of this keyword argument should be a symbol

which names the theory in which the function should be defined. If the :THEORY argument is not supplied, the current theory is assumed (see IN-THEORY.)

:IMPLEMENTATION - The value of this keyword argument should be a

symbol (usually a keyword) which names the target representation system in which the function should be defined. This is independent of the theory in which the function is defined. If the :IMPLEMENTATION argument is not supplied, the current implementation is assumed (see IN-IMPLEMENTATION.)

:ISSUES - The value of this argument should be a Lisp "tree" of

strings. It is ignored by the translators, and is meant to provide a standard place for ontology authors to add human readable annotatations to their definitions.

Function Create-Instance

(create-instance <instance-name> (<class-name>+) 
   [:documentation <docstring>] 
   {{:= <term-expression-without-arg-vars>} | 
    {:axiom-def <sent-without-arg-vars>}} 
   [:slots (<slot-spec>*)] 
   [:theory <theory-name>] 
   [:implementation <target-system-name>] 
   [:issues <issue-tree>]) 

Defines an OntoLingua instance. See also DEFINE-INSTANCE, which is the macro form.

Macro for defining instances of OntoLingua classes. No arguments are evaluated. See also CREATE-INSTANCE, which is the functional form.

<instance-name> should be a symbol which names the instance being

defined. OntoLingua will convert this symbol into a format which is appropriate for the selected target representation system during translation (e.g., if one were translating into CycL, the symbol would be converted into a string which would obey the CycL conventions for case and word delimiters.)

<class-list> should be a list of symbols which name the OntoLingua

classes of which the instance is to be a member. Logically, this means that the unary predicates corresponding to each of the classes in <class-list> hold when their argument is the instance being defined. For example,

      (define-instance FRED (GUYS-WITH-GENERIC-NAMES 
                             GUYS-WITH-FOUR-LETTER-NAMES) 
          "The canonical random person name.") 

is logically equivalent to:

      (and (GUYS-WITH-GENERIC-NAMES FRED) 
           (GUYS-WITH-FOUR-LETTER-NAMES FRED)) 

<docstring> should be a string which describes the instance being

defined. It will be stored as the Lisp documentation (of type OL:ONTO-INSTANCE) for the symbol which names the instance.

The remaining keyword arguments may occur in any order, and are described below:

:= - The value of this keyword argument should be a KIF term

expression which denotes the instance being defined. For example:

        (define-instance PI (real-number) 
          "PI is the ratio of the perimeter of a circle to  
           its diameter." 
          := 3.145) 

:AXIOM-DEF - The value of this keyword argument should be a KIF

sentence which mentions the instance being defined; it will be asserted when the instance is defined. Terminologically, this sentence will be considered part of the definition of the instance. For example:

        (define-instance FRED (GUYS-WITH-GENERIC-NAMES) 
          "The canonical random person name." 
          :axiom-def (usual-temperament fred nice)) 

means that FRED is a member of the class GUYS-WITH-GENERIC-NAMES, and that FRED is usually nice. The axiom that fred is usually nice is considered part of the definition of FRED.

A list of sentences may be supplied instead of a single sentence; OntoLingua will automatically construct a conjunction of all the supplied :AXIOM-DEF sentences in this case.

:THEORY - The value of this keyword argument should be a symbol

which names the theory in which the instance should be defined. If the :THEORY argument is not supplied, the current theory is assumed (see IN-THEORY.)

:IMPLEMENTATION - The value of this keyword argument should be a

symbol (usually a keyword) which names the target representation system in which the instance should be defined. This is independent of the theory in which the instance is defined. If the :IMPLEMENTATION argument is not supplied, the current implementation is assumed (see IN-IMPLEMENTATION.)

:ISSUES - The value of this argument should be a Lisp "tree" of

strings. It is ignored by the translators, and is meant to provide a standard place for ontology authors to add human readable annotatations to their definitions.

In principle one could define OntoLingua classes, relations, and functions by making them instances of OL:CLASS, KIF:RELATION, and KIF:FUNCTION, but this is not guaranteed to do the right thing in supported implementations. For these cases, use DEFINE-CLASS (or CREATE-CLASS), DEFINE(CREATE)-RELATION, and DEFINE(CREATE)-FUNCTION.

Function Create-Relation

(create-relation <relation-name> (<var>+) 
   [:documentation <docstring>] 
   [:when <sent-with-arg-vars>] 
   {:def | :iff-def} <sent-with-arg-vars> 
   [:constraints <sent-with-arg-vars>] 
   [:equivalent (<sent-with-arg-vars>*)] 
   [:sufficient <sent-with-arg-vars>] 
   [:default-constraints (<sent-with-arg-vars>*)] 
   [:axiom-def <sent-without-arg-vars>] 
   [:axiom-constraints <sent-without-arg-vars>] 
   [:axiom-defaults (<sent-without-arg-vars>*)] 
   [:theory <theory-name>] 
   [:implementation <target-system-name>] 
   [:class-slots (<slot-spec>*)] 
   [:instance-slots (<extended-slot-spec>*)] 
   [:default-slot-values (<slot-spec>*)] 
   [:issues <issue-tree>]) 

Defines an OntoLingua relation. See also DEFINE-RELATION, which is the macro form.

<relation-name> should be a symbol which names the relation being

defined. OntoLingua will convert this symbol into a format which is appropriate for the selected target representation system during translation (e.g., if one were translating into CycL, the symbol would be converted into a string which would obey the CycL conventions for case and word delimiters.)

<argument-list> is a list of symbols which name the entities related

by the relation being defined, e.g. (define-relation father-of (?father ?child)...) Within the sentences in the body of the DEFINE-RELATION form, these symbols are treated as variables bound to the objects related by the relation. The current KIF convention is to use symbols which begin with a "?", but since OntoLingua converts all variables to this format internally it is not strictly necessary to adhere to this convention.

Note: sequence-variables (indicated by a '@' prefix in KIF and Epikit) are not guaranteed to be supported in all target representation systems. This means that "portable" OntoLingua relations always have a fixed arity.

<docstring> when provided, should be a string which describes the

function being defined. It will be stored as the Lisp documentation (of type OL:ONTO-RELATION) for the symbol which names the relation. If a docstring is provided, it must immediately follow the argument list.

The remaining keyword arguments may occur in any order, and are described below:

:DEF - The value of this keyword argument should be a KIF sentence

that "defines" the relation; that is, a KIF sentence using the variables in ARGUMENTS as free variables that holds when the relation is asserted on specific instances. The purpose of the :DEF sentence is to specify constraints on consistent use of the relation; it should reflect the textual definition given in the docstring. Some implementations make special use of sentences labeled as definitions.

Logically, the :DEF sentence is implied by the relation. For example:

        (define-relation has-parent (?child ?parent) 
          "the relation from children to parents." 
          :def (and (person ?child) (person ?parent))) 

is logically equivalent to

        (=> (has-parent ?parent ?child)  
            (and (person ?parent) (person ?child))). 

:IFF-DEF - The value of this keyword argument should be a KIF

sentence that "completely defines" the relation. This is just like the :DEF keyword, except that the supplied sentence specifies both necessary and sufficient conditions for the relation to hold on any given bindings for the ARGUMENTS. For example:

        (define-relation has-mother (?child ?mother) 
          "child's mother" 
          :iff-def (and (has-parent ?child ?mother) 
                        (female ?mother))) 

is logically equivalent to

        (<=> (has-mother ?parent ?child) 
             (and (has-parent ?child ?other)  
	          (female ?mother))) 

It is not legal use both the :DEF and :IFF-DEF keywords in the same definition.

:CONSTRAINTS - The associated value should be a KIF sentence that

specifies necessary constraints on the relation that are not meant as part of the definition of the relation. The :CONSTRAINTS sentence is taken to be true for any bindings of ARGUMENTS for which the relation holds; it "follows" from the definition. One can also think of constraints as (monotonically) inherited facts about sets of instances for which the relation holds.

:CONSTRAINTS sentences are logically equivalent to :DEF sentences, and take the same form (i.e., sentences with terms that include free variables from the ARGUMENTS list.) The purpose of the distinction between definitional and nondefinitional constraints is to support terminological reasoning apart from other kinds of deductive inference. The :CONSTRAINTS sentence is an assertion used in nonterminological inference, such as inheritence of sentences used to ensure consistency.

A list of sentences may be supplied instead of a single sentence; OntoLingua will automatically construct a conjunction of all the supplied :CONSTRAINTS sentences in this case.

:SUFFICIENT - The value of this keyword arg should be a KIF sentence

that specifies sufficient constraints for the relation to hold for a given binding of ARGUMENTS. The :SUFFICIENT sentence thus specifies conditions under which the relation may be inferred; it may be used as a backward chaining deductive rule whose consequent is an instantiation of the relation.

A list of sentences may be supplied instead of a single sentence; OntoLingua will automatically construct a disjunction of all the supplied :SUFFICIENT sentences in this case.

:EQUIVALENT - The value of this keyword argument should be a list of

KIF sentences that specify biconditional constraints on the relation that are not meant as part of the definition of the relation.

:EQUIVALENT constraints are logically equivalent to :IFF-DEF constraints. The purpose of the distinction between definitional and nondefinitional constraints is to support terminological reasoning apart from other types of deductive inference. The :EQUIVALENT sentences are assertions used in nonterminological inference.

:DEFAULT-CONSTRAINTS - The value of this keyword argument should be

a list of KIF sentences that specify what "follows by default" from the relation. The precise operational semantics of nonmonotonic inference will depend on the target representation system. The intended use of :DEFAULT-CONSTRAINTS is to specify "default rules" whose anticendents are the relation with ARGUMENTS as free variables and whose consequents are each of the :DEFAULT-CONSTRAINTS sentences. The :DEFAULT-CONSTRAINTS sentences have the the same form as the :DEF and :CONSTRAINTS sentences.

When a ground assertion using the relation is asserted, then each of the :DEFAULT-CONSTRAINTS sentences will hold ("by default") for those bindings of ARGUMENTS until and unless a sentence that contradicts that DEFAULT-CONSTRAINTS sentence is asserted for those bindings. For example:

        (define-relation country-of-citizenship (?person ?country) 
          :default-constraints  

(exists ?language

            (and (languages-spoken ?person ?language) 
                 (official-language ?country ?language)))) 

means that if the country-of-citizenship of a person is known, then at least one of the languages that the person speaks is an official-language of the person's country-of-citizenship, unless this is explicitly asserted not to be the case.

:AXIOM-DEF - The associated value should be a KIF sentence; it will

be asserted along with the definition. Logically, this sentence neither implies nor is implied by the relation holding for a given binding of the variables in ARGUMENT-LIST; it is a standalone sentence. It should mention the relation being defined, however. If this axiom happens to mention the variables in ARGUMENT-LIST, then these variables are considered as any other unquantified KIF variables: they are assumed to be universally quantified. Thus, it's confusing to use the ARGUMENT-LIST variables in the :AXIOM-DEF sentences.

The :AXIOM-DEF sentence is considered to be definitional. That is, it is part of the definition as are :DEF and :IFF-DEF sentences.

A list of sentences may be supplied instead of a single sentence; OntoLingua will automatically construct a conjunction of all the supplied :AXIOM-DEF sentences in this case.

:AXIOM-CONSTRAINTS - The associated value should be a KIF sentence

which is a standalone sentence not related to the variables in ARGUMENT-LIST. It is the same as the :AXIOM-DEF sentence except it is nonterminological -- outside of the definition.

A list of sentences may be supplied instead of a single sentence; OntoLingua will automatically construct a conjunction of all the supplied :AXIOM-CONSTRAINTS sentences in this case.

:AXIOM-DEFAULTS - the value of this keyword should be a list of KIF

sentences with are not related to the variables in ARGUMENT-LIST. They should mention the relation being defined, however. Each of these sentences is taken to hold until and unless a contradictory sentence is asserted.

:THEORY - The value of this keyword argument should be a symbol

which names the theory in which the relation should be defined. If the :THEORY argument is not supplied, the current theory is assumed (see IN-THEORY.)

:IMPLEMENTATION - The value of this keyword argument should be a

symbol (usually a keyword) which names the target representation system in which the relation should be defined. This is independent of the theory in which the relation is defined. If the :IMPLEMENTATION argument is not supplied, the current implementation is assumed (see IN-IMPLEMENTATION.)

:ISSUES - The value of this argument should be a Lisp "tree" of

strings. It is ignored by the translators, and is meant to provide a standard place for ontology authors to add human readable annotatations to their definitions.

:CLASS-SLOTS, :INSTANCE-SLOTS, and :DEFAULT-SLOT-VALUES - These

keyword arguments are discussed below, under "Alternate Slot Syntax."

Second Order Sentences

Within the :AXIOM-DEF there may be sentences that specify properties of the relation being defined, rather than properties of the instances related by the relation being defined. Such sentences use the names of relations as arguments to special "second order" relations. For example, consider the following definition:

     (define-relation in-module (?port ?module) 
       "Function from a port to its associated module. 
        Each port has at most one associated module." 
       :def (and (port ?port) 
                  (module ?module)) 
       :axiom-def (OL:SINGLE-VALUED in-module)) 

In the :AXIOM-DEF sentence, IN-MODULE is said to be a SINGLE-VALUED relation, which means:

      (=> (and (in-module ?x ?y) (in-module ?x ?z)) (= ?y ?z)). 

The symbol IN-MODULE denotes the relation of that name. Since the argument to SINGLE-VALUED, IN-MODULE, is also a relation, SINGLE-VALUED is called a second-order relation.

Second order relations capture many conventions for defining and organizing terms in concise ways. For example, in the following definition, MODULE-PORTS is defined as the inverse of IN-MODULE. That is all that needs to be stated about this term; everything true of IN-MODULE is true of MODULE-PORTS with its arguments reversed:

      (define-relation module-ports (?module ?port) 
        "The ports associated with a module." 
        :axiom-def (OL:INVERSE module-ports in-module)) 

Terminologically, second-order sentences are always considered to be definitional. Only a restricted set of second-order relations are allowed; these are defined in the frame ontology.

Alternate Slot Syntax

OntoLingua supports additional syntax for writing some definition sentences in a frame/slot style instead of the predicate calculus style of KIF. This additional syntax is supported via three additional definition keywords, whose associated values are lists of sentences in the following format, called a SLOT-VALUE-SPEC:

      (slot-name slot-value1 slot-value2 ...)  

SLOT-NAME is the name of a binary relation. The first argument to this binary-relation (the frame) is made implicit by the keyword with which the sentence is associated, and each SLOT-VALUE is a second argument to the relation.

During the translation process, OntoLingua will transform such a sentence into the equivalent KIF sentences

      (slot-name frame slot-value-1) 
      (slot-name frame slot-value-2)... 

These resulting sentences will be added to the :AXIOM-DEF, :CONSTRAINTS,

:AXIOM-CONSTRAINTS, or :DEFAULT-CONSTRAINTS sentences depending on the

keyword with which the original slot-syntax sentences are associated.

The three keywords supported in this manner are as follows:

:CLASS-SLOTS - The associated value should be a list of SLOT-VALUE-SPECs whose frames are taken to be the relation being defined. Thus, the relations corresponding to the slot

      names are second-order relations (see "Second Order Sentences" 

above.) Sentences translated from :CLASS-SLOTS are added to the

      :AXIOM-DEF sentence. 

:INSTANCE-SLOTS - This keyword is only valid in the definition of unary relations (or equivalently, classes.) The associated value should be a list of SLOT-VALUE-SPECs sentences whose frames are taken to be individuals for which the unary relation holds. Sentences translated from :INSTANCE-SLOTS are added to the :CONSTRAINTS sentence.

An exteded slot syntax is supported for this keyword which allows values for "facets" of slots to be provided. Within the SLOT-VALUE-SPECS any of the slot-values may be a list of the

      form: 

         (facet facet-value1 facet-value2...). 

OntoLingua will transform these into the equivalent KIF

      sentences: 

         (facet relation slot facet-value1) 
         (facet relation slot facet-value2) 

...

:DEFAULT-SLOT-VALUES - This keyword is only valid in the definition of unary relations (or equivalently, classes.) The associated value should be a list SLOT-VALUE-SPECs sentences whose frames are taken to be individuals for which the unary relation holds. Sentences translated form :DEFAULT-SLOT-VALUES are added to the :DEFAULT-CONSTRAINTS sentences, and will therefore hold for each instance of the class until and unless a contrary assertion is made about that instance.

Function Create-Theory

Defines or modifies an OntoLingua theory. See also DEFINE-THEORY, which is the functional form.

<theory-name> - a symbol which names the theory to be defined of modified.

Package is significant. If an appropriate theory already exists, it will be updated; IT WILL NOT BE EMPTIED OR RESET.

<included-theories> - a list of theory objects (or symbols which name

theories) to be included in the theory being defined or modified.

<docstring> if supplied, should be a string describing the theory

being defined or modified. This string will be stored as the documentation (of type OL:ONTO-THEORY) of the symbol which names the theory.

<key-arg-pairs> - an alternating list of keywords an values preceded by

an optional docstring. Supported keywords are:

The following keyword arguments are also supported; all other supplied keyword arguments will be spliced into the init-plist of the CLOS object which represents the theory being defined of modified when it is instantiated or reinitialized, respectively.

:IMPLEMENTATION - The value of this keyword argument indicates the

desired implementation for the theory to be defined or modified. It may be either a symbol (usually a keyword) which names an implementation, or a list whose first element is such a symbol. If a list, the tail of the list will be included in the init-plist of the CLOS object which represents the theory being defined or modified when it is instantiated or reinitialized, respectively. This provides a convenient way to individually tailor theory instances within a single implementation.

If this keyword is unspecified, the current implementation (see IN-IMPLEMENTATION) will be assumed.

:IO-PACKAGE - The value of this keyword arg should be a package or a

symbol or string which names one; this value is put in the IO-PACKAGE slot on the theory object being defined or modified. User interface code which operates on behalf of the theory can then examine this slot for a suggestion of a good package to use when printing and reading.

Function Define-Axiom

<axiom-def> :== (DEFINE-AXIOM <axiom-name> 
                  [<docstring>] 
                  := <sentence> 
                  [:theory <theory-name>] 
                  [:implementation <target-system-name>] 
                  [:issues <issue-tree>]) 

Macro for asserting an arbitrary OntoLingua axiom. No arguments are evaluated. See also CREATE-AXIOM, which is the functional form. Most axioms can be associated with a definition, and belong there. Some axioms involve several basic terms and are central to the theory being specified by the ontology. Such axioms are given with this form.

Function Define-Class

<class-def> :== (DEFINE-CLASS <class-name> (<var>) 
                  [<docstring>] 
                  {:def | :iff-def} <sent-with-arg-vars> 
                  [:constraints <sent-with-arg-vars>] 
                  [:equivalent <sent-with-arg-vars>] 
                  [:sufficient <sent-with-arg-vars>] 
                  [:default-constraints <sent-with-arg-vars>] 
                  [:axiom-def <sent-without-arg-vars>] 
                  [:axiom-constraints <sent-without-arg-vars>] 
                  [:axiom-defaults (<sent-without-arg-vars>*)] 
                  [:theory <theory-name>] 
                  [:implementation <target-system-name>] 
                  [:class-slots (<slot-spec>*)] 
                  [:instance-slots (<extended-slot-spec>*)] 
                  [:default-slot-values (<slot-spec>*)] 
                  [:issues <issue-tree>]) 

<class-name> should be a symbol which names the class being defined.

OntoLingua will convert this symbol into a format which is appropriate for the selected target representation system during translation (e.g., if one were translating into CycL, the symbol would be converted into a string which would obey the CycL conventions for case and word delimiters.)

<argument-list> should be a list of a single symbol; within the

sentences in the body of the DEFINE-CLASS form, this symbol is treated as a variable bound to an instance of the class. The current KIF convention is to use a symbol which begins with a "?", but since OntoLingua converts all variables to this format internally it is not strictly necessary to adhere to this convention.

<docstring> when provided, should be a string which describes the

class being defined. It will be stored as the Lisp documentation (of type OL:ONTO-CLASS) for the symbol which names the class. If a docstring is provided, it must immediately follow the argument list.

The various keyword arguments may occur in any order, and are described below:

:DEF - The value of this keyword argument should be a KIF sentence

that "defines" the class; that is, a KIF sentence using the argument symbol as a free variable that holds over all instances of the class. The purpose of the :DEF sentence is to specify constraints on consistent use of the class; it should reflect the textual definition given in the docstring. Some implementations make special use of sentences labeled as definitions.

Logically, the :DEF sentence is implied by membership in the class, and membership in a class is specfied by something satisfying a unary precicate. That is, the :DEF sentence is a necessary condition for class membership. For example,

        (define-class human (?human) 
          "The human animal." 
          :def (animal ?human)) 

is logically equivalent to

        (=> (human ?human) 
            (animal ?human)) 

It also is way of saying that human is a subclass of animal (human is subsumed by animal).

:IFF-DEF - The value of this keyword argument should be a KIF

sentence that "completely defines" the class. This is just like the :DEF keyword, except that the sentence specifies both necessary and sufficient conditions for membership in the class. For example:

        (define-class female-person (?person) 
          "female humans" 
          :iff-def (and (human ?person) 
                        (= (gender ?person) female))) 

specifies that

        (<=> (female-person ?person) 
             (and (human ?person) (gender ?person))) 

and that this fact is the definition of (what it means to be) a female-person.

It is not legal use both the :DEF and :IFF-DEF keyword arguments in the same definition.

:CONSTRAINTS - The value of this keyword argument should be a KIF

sentence which specifies necessary constraints on membership in the class that are not meant as part of the definition. The :CONSTRAINTS sentence says what is true of all instances. One can also think of the :CONSTRAINTS sentence as a (monotonically) inherited fact about instances.

:CONSTRAINTS sentences are logically equivalent to :DEF sentences, and take the same form (i.e., sentences with terms that include the free variable from ARGUMENT-LIST.) The purpose of the distinction between definitional and nondefinitional constraints is to support terminological reasoning apart from other kinds of deductive inference. The :CONSTRAINTS sentence is an assertion used in nonterminological inference, such as inheritence of sentences that would be checked on the creation of instances.

A list of sentences may be supplied instead of a single sentence; OntoLingua will automatically construct a conjunction of all the supplied :CONSTRAINTS sentences in this case.

:SUFFICIENT - The value of this keyword argument should be a KIF

sentence that specifies sufficient constraints for membership in the class; it may be used as a backward chaining deductive rule whose consequent is an instantiation of the class.

A list of sentences may be supplied instead of a single sentence; OntoLingua will automatically construct a disjunction of all the supplied :SUFFICIENT sentences in this case.

:EQUIVALENT - The value of this keyword should be a list of KIF

sentences that specify facts that are both necessary and sufficient for class membership, but are not meant as part of the definition of the class.

:EQUIVALENT sentences are logically equivalent to :IFF-DEF sentences. The purpose of the distinction between definitional and nondefinitional constraints is to support terminological reasoning apart from other types of deductive inference. The :EQUIVALENT sentences are assertions used in nonterminological inference.

:DEFAULT-CONSTRAINTS - The value of this keyword argument should be

a list of KIF sentences that specify what "follows by default" from membership in the class. The precise operational semantics of nonmonotonic inference will depend on the target representation system. The intended use of :DEFAULT-CONSTRAINTS is to specify "default inheritance" of facts about instances of the class. The :DEFAULT-CONSTRAINTS sentences have the the same form as the :DEF and :CONSTRAINTS sentences.

When it is asserted that an individual is an instances of the class, then each of the :DEFAULT-CONSTRAINTS sentences will hold ("by default") with the ARGUMENT-LIST variable bound to that individual, until and unless a sentence that contradicts that :DEFAULT-CONSTRAINTS sentence is asserted for that individual. For example:

        (define-class american (?person) 
           :default-constraints (owns-tv ?person)) 

specifies

        (=> (american ?person) 
            (<= (owns-tv ?person)  
                (not (provable (not (owns-tv ?person)))))) 

:AXIOM-DEF - The value of this keyword should be KIF sentence; it

will be asserted along with the definition. Logically, this sentence neither implies nor is implied by membership in the class being defined; it is a standalone sentences. It should mention the class being defined, however. If this axiom happens to mention the variables in ARGUMENT-LIST, then these variables are treated like any other unquantified KIF variables: they are assumed to be universally quantified. Thus, it is confusing to use the ARGUMENT-LIST variables in the :AXIOM-DEF sentence.

The :AXIOM-DEF sentence is considered to be definitional. That is, it is part of the definition as are :DEF and :IFF-DEF sentences.

A list of sentences may be supplied instead of a single sentence; OntoLingua will automatically construct a conjunction of all the supplied :AXIOM-DEF sentences in this case.

:AXIOM-CONSTRAINTS - The value of this keyword should be a KIF

sentence that is a standalone sentence not related to the variables in ARGUMENT-LIST. This is the same as the :AXIOM-DEF sentence except it is nonterminological -- outside of the definition.

A list of sentences may be supplied instead of a single sentence; OntoLingua will automatically construct a conjunction of all the supplied :AXIOM-CONSTRAINTS sentences in this case.

:AXIOM-DEFAULTS - the value of this keyword should be a list of KIF

sentences with are not related to the variables in ARGUMENT-LIST. They should mention the class being defined, however. Each of these sentences is taken to hold until and unless a contradictory sentence is asserted.

:THEORY - The value of this keyword argument should be a symbol

which names the theory in which the class should be defined. If the :THEORY argument is not supplied, the current theory is assumed (see IN-THEORY.)

:IMPLEMENTATION - The value of this keyword argument should be a

symbol (usually a keyword) which names the target representation system in which the class should be defined. This is independent of the theory in which the class is defined. If the :IMPLEMENTATION argument is not supplied, the current implementation is assumed (see IN-IMPLEMENTATION.)

:ISSUES - The value of this argument should be a Lisp "tree" of

strings. It is ignored by the translators, and is meant to provide a standard place for ontology authors to add human readable annotatations to their definitions.

:CLASS-SLOTS, :INSTANCE-SLOTS, and :DEFAULT-SLOT-VALUES - These

keyword arguments are discussed below, under "Alternate Slot Syntax."

Second Order Sentences

Within the :AXIOM-DEF there may be sentences that specify properties of the class being defined, denoted by CLASS-NAME, rather than properties of instances of the class, denoted by the variable in ARGUMENT-LIST. Such sentences use the names of relations as arguments to special "second order" relations.

In the following example, human is defined as a subclass-of animal, which was previously stated in a first-order style above.

      (define-class human (?human) 
        "The human animal." 
        :axiom-def (subclass-of human animal)) 

Alternate Slot Syntax

OntoLingua supports additional syntax for writing some definition sentences in a frame/slot style instead of the predicate calculus style of KIF. This additional syntax is supported via three additional keyword arguments, whose values should be lists of sentences in the following format:

      (slot-name slot-value1 slot-value2 ...)  

SLOT-NAME is the name of a binary relation. The first argument to this binary-relation (the frame) is made implicit by the keyword with which the sentence is associated, and each SLOT-VALUE is a second argument to the relation.

During the translation process, OntoLingua will transform such a sentence into the equivalent KIF sentences

      (slot-name frame slot-value-1) 
      (slot-name frame slot-value-2)... 

These resulting sentences will be added to the :DEF, :IFF-DEF,

:CONSTRAINTS, or :DEFAULT-CONSTRAINTS sentences depending on the

keyword with which the original slot-syntax sentences are associated.

The three keyword arguments supported in this manner are as follows:

:CLASS-SLOTS - The value of this keyword should be a list of slot sentences whose frames are taken to be the class being defined. Thus, the relations corresponding to the slot names are

      second-order relations (see "Second Order Sentences" above.) 

Sentences translated from :CLASS-SLOTS are added to the :DEF or

      :IFF-DEF sentence. 

:INSTANCE-SLOTS - The value of this keyword should be a list of slot sentences whose frames are taken to be the instances of the class being defined. Sentences translated from :INSTANCE-SLOTS are added to the :CONSTRAINTS sentence.

An exteded slot syntax is supported for this keyword which allows values for "facets" of slots to be provided. Within the SLOT-VALUE-SPECS any of the slot-values may be a list of the

      form: 

         (facet facet-value1 facet-value2...). 

OntoLingua will transform these into the equivalent KIF

      sentences: 

         (facet class slot facet-value1) 
         (facet class slot facet-value2) 

...

:DEFAULT-SLOT-VALUES - The value of this keyword should be a list of slot sentences whose frames are taken to be the instances of the class being defined. Sentences translated form :DEFAULT-SLOT-VALUES are added to the :DEFAULT-CONSTRAINTS sentences, and will therefore hold for each instance of the class until and unless a contrary assertion is made about that instance.

Function Define-Frame

Define-frame is a syntax for giving definitions that look like frames. It is designed to make it easy to map into object-oriented representations.

The syntax is:

 (define-frame <frame-name> 
   :own-slots ((<own-slot-spec>)*) 
   :template-slots ((<template-slot-spec>)*) 
   :axioms (<KIF sentence mentioning frame-name>*) 
   ) 
<own-slot-spec> :== (<slot-name> <value-spec>+) 
<template-slot-spec> :== (<slot-name> <facet-or-value-spec>+) 

<frame-name> :== symbol naming a class, relation, function, or object

<slot-name> :== symbol naming a binary relation or unary function

<value-spec> :== <constant> | (SETOF <constant>*) | (LISTOF <constant>*) 
                 | (QUOTE <lisp s-expression>) 
<constant> :== <string> | <symbol> | <number> 
<facet-or-value-spec> :== <value-spec> | (<facet> <value-spec>*) 

<facet> :== symbol naming a slot constraint relation, such as VALUE-TYPE

In this syntax, all named objects are frames. Whether a frame is a class, relation, function, or other kind of object is given by the values of the INSTANCE-OF slot. :Own-slots are binary relations applied to frames, with the frame inserted as a first argument. Thus, for a frame named X the own-slot spec (instance-of class) translates to the KIF sentence

  (instance-of X class). 

The value of a slot may be either a constant like a number or symbol, or it may be a list beginning with one of the KIF operators SETOF, LISTOF, and QUOTE. The expression (SETOF a b c) denotes the set containing a, b, and c. The expression (LISTOF d e f) denotes the sequence d,e,f. The expression (QUOTE x) denotes the expression x, where x may be any lisp expression.

:Template-slots only make sense if the frame is an instance of CLASS. In that case, template slots describe properties of instances of the class. For example, the template slot spec (slot (SLOT-VALUE-TYPE type)) for the frame C translates to the KIF sentence

  (slot-value-type C slot type) 

which is a second-order way of saying

  (forall ?c (=> (and (instance-of ?c C) 
		      (defined (foo ?c))) 
		 (instance-of (foo ?c) bar))) 

A value of a template slot is a downward inherited value (it is a slot value for all instances of the class). For frame C, the template slot spec (slot value) translates into the KIF sentence

  (inherited-slot-value C slot value) 

The value of :axioms is a list of KIF sentences mentioning <frame-name>. These axioms can be used to say things that can't be expressed in the restricted slot/value format.

Function Define-Function

<function-def> :== (DEFINE-FUNCTION <function-name> (<var>+) [:-> <var>] 
                     [<docstring>] 
		     [:when <sent-with-arg-vars>] 
                     [{:def | :iff-def} <sent-with-arg-vars>] 
                     [:constraints <sent-with-arg-vars>] 
                     [:axiom-def <sent-without-arg-vars>] 
                     [:axiom-constraints <sent-without-arg-vars>] 
                     [{{:lambda-body | :=} <term-expression-with-arg-vars>} | 
                      {:lisp-body <lisp-function-body-using-arg-vars>}] 
                     [:theory <theory-name>] 
                     [:implementation <target-system-name>] 
                     [:issues <issue-tree>]) 

Macro for defining OntoLingua functions. No arguments are evaluated. See also CREATE-FUNCTION, which is the functional form. Macro for defining OntoLingua functions and procedural attachments. No arguments are evaluated. See also CREATE-FUNCTION, which is the functional form.

<function-name> should be a symbol which names the function being

defined. OntoLingua will convert this symbol into a format which is appropriate for the selected target representation system during translation (e.g., if one were translating into CycL, the symbol would be converted into a string which would obey the CycL conventions for case and word delimiters.)

<argument-list> should be a list of symbols which serve as the

arguments to the function. Within the body of the DEFINE-FUNCTION form, there may be KIF sentences which refer to these symbols as variables in order to establish the constraints between the arguments to the function being defined and its value. Such constraints constitute the definition of an OntoLingua function. The symbols in ARGUMENT-LIST may also be used as formal arguments in a procedural attachment.

:-> - The value of this keyword argument should be a symbol which will

be used to represent the result of the function within the KIF sentences of the definition. It is not necessary to explicitly supply a result variable to talk about the result of the function; the term formed by prepending the FUNCTION-NAME to the ARGUMENT-LIST may be used within the KIF sentences of the definition to stand for a nameless result variable. If this keyword argument is supplied, however, it must immediately follow the argument list.

<docstring> when provided, should be a string which describes the

function being defined. It will be stored as the Lisp documentation (of type OL:ONTO-FUNCTION) for the symbol which names the function. If a docstring is provided, it must immediately follow the :-> argument (or immediately follow the argument list if no :-> argument is provided.)

The remaining keyword arguments may occur in any order, and are described below:

:DEF - The value of this keyword argument should be a KIF sentence

which refers to the free variables in ARGUMENT-LIST and the RESULT-VARIABLE. Logically, the :DEF sentence is "implied by" the function; i.e. the :DEF sentence holds for every variable binding such that the value of the function when applied to the variables in ARGUMENT-LIST is the value of the RESULT-VARIABLE.

:IFF-DEF - The value of this keyword argument should be a list of

KIF sentences which refer to the free variables in ARGUMENT-LIST and the RESULT-VARIABLE. Logically, the :IFF-DEF sentence both "implies" and "is implied by" the function; i.e. in addition to the property ascribed to the :DEF sentence above, for every variable binding such that the :IFF-DEF sentence holds, the value of the function applied to the variables in ARGUMENT-LIST is the value of the RESULT-VARIABLE.

It is not permisible to use both the :DEF and :IFF-DEF keywords within a single DEFINE-FUNCTION form.

:CONSTRAINTS - The value of this keyword argument should be a list

of KIF sentences which refer to the free variables in the ARGUMENT-LIST and the RESULT-VARIABLE that are not meant as part of the definition.

:CONSTRAINTS sentences are logically equivalent to :DEF sentences. The purpose of the distinction between definitional and nondefinitional constraints is to support terminological reasoning apart from other types of deductive inference. The :CONSTRAINTS sentences are assertions used in nonterminological inference.

A list of sentences may be provided instead of a single sentence; OntoLingua automatically constructs a conjunction of all the supplied :CONSTRAINTS sentences in this case.

:LAMBDA-BODY or :=

- The value of this keyword argument should be a KIF term expression (a sentence denoting and object, not a truth value) which, when given bindings for the variables in ARGUMENT-LIST, can produce a value for the function. Logically, the fact that the result variable is equivalent to the :LAMBDA-BODY expression implies and is implied by the fact that the value of the function applied to the variables in ARGUMENT-LIST is the value of the RESULT-VARIABLE, for all variable bindings.

For example, the following form defines the 'feature value' of a feature in a simulation:

        (define-function val (?feature ?step) :-> ?value 
          "function which returns the value of a DSL feature.  
           It dispatches on the type of the feature." 

          :DEF (and (feature ?feature)  
                    (timepoint ?step)  
                    (feature-value ?value)) 
          :LAMBDA-BODY (cond ((constant-feature ?feature)  
                              (initial-value ?feature)) 
                             ((connected-feature ?feature)  
                              (val (source ?feature) ?step)) 
	                     ((functional-feature ?feature)  
                              (valcompute ?feature ?step)) 
	                     ((markov-feature ?feature) 
	                      (if (= ?step 1)  
                                  (initial-value ?feature) 
                                  (valcompute ?feature (1- ?step)))))) 

:LISP-BODY is a Lisp expression that returns the value of the

function when evaluated in an environment where the variables in RESULT-VARIABLE are bound. Within the :LISP-BODY expression, references to a function with FUNCTION-NAME work as expected; OntoLingua takes care of the mechanism by which Lisp function are defined and connected to KIF functions. "Appropriate" procedural attachment may take place, depending on the target representation system.

In the following example, the Lisp function INTPOWER is defined and it is related to the function constant INTPOWER in such a way that a query of the form '(= ?x (intpower 2 3)) will bind the result 8 to the variable ?x:

        (define-function intpower (?x ?y) :-> ?result 
          "Function which returns X to the power Y. Where Y is an Integer." 
          :def (and (integer ?x) (integer ?y) (integer ?result)) 
          :lisp-body (if (<= ?y 0) 1 (* ?x (intpower ?x (1- ?y)))) 

It is not permisible to use both :LAMBDA-BODY and :LISP-BODY keywords within the same DEFINE-FUNCTION form.

:AXIOM-DEF - The associated value should be a KIF sentence

to be asserted along with the definition of the function. Logically, this sentence stands alone, and has no relation to the variables in ARGUMENT-LIST or the RESULT-VARIABLE. Terminologically, this sentence is considered definitional.

Second order sentences may be specified here (see Second Order Sentences, under DEFINE-RELATION.)

For example:

       (define-function identity (?anything) :-> ?same-thing 
         "returns its argument." 
         :lambda-body ?anything	 
         :axiom-def (and (symmetric-function identity) 
                         (transitive-function identity))) 

The fact that the function identity is symmetric and transitive is considered to be part of the definition of identity.

A list of sentences may be supplied instead of a single sentence; OntoLingua will automatically construct a conjunction of all the supplied :AXIOM-DEF sentences in this case.

:AXIOM-CONSTRAINTS - The associated value should be a KIF sentence

that is a standalone sentence not related to the variables in ARGUMENT-LIST. This is the same as the :AXIOM-DEF sentence except that is it nonterminological -- outside of the definition.

A list of sentences may be supplied instead of a single sentence; OntoLingua will automatically construct a conjunction of all the supplied :AXIOM-CONSTRAINTS sentences in this case.

:THEORY - The value of this keyword argument should be a symbol

which names the theory in which the function should be defined. If the :THEORY argument is not supplied, the current theory is assumed (see IN-THEORY.)

:IMPLEMENTATION - The value of this keyword argument should be a

symbol (usually a keyword) which names the target representation system in which the function should be defined. This is independent of the theory in which the function is defined. If the :IMPLEMENTATION argument is not supplied, the current implementation is assumed (see IN-IMPLEMENTATION.)

:ISSUES - The value of this argument should be a Lisp "tree" of

strings. It is ignored by the translators, and is meant to provide a standard place for ontology authors to add human readable annotatations to their definitions.

Function Define-Instance

<instance-def> :== (DEFINE-INSTANCE <instance-name> (<class-name>+) 
                     [<docstring>] 
                     [:= <term-expression-without-arg-vars>] 
                     [:axiom-def <sent-without-arg-vars>] 
                     [:slots (<slot-spec>*)] 
                     [:theory <theory-name>] 
                     [:implementation <target-system-name>] 
                     [:issues <issue-tree>]) 

Macro for defining ontolingua instances. No arguments are evaluated. See also CREATE-INSTANCE, which is the functional form.

Macro for defining instances of OntoLingua classes. No arguments are evaluated. See also CREATE-INSTANCE, which is the functional form.

<instance-name> should be a symbol which names the instance being

defined. OntoLingua will convert this symbol into a format which is appropriate for the selected target representation system during translation (e.g., if one were translating into CycL, the symbol would be converted into a string which would obey the CycL conventions for case and word delimiters.)

<class-list> should be a list of symbols which name the OntoLingua

classes of which the instance is to be a member. Logically, this means that the unary predicates corresponding to each of the classes in <class-list> hold when their argument is the instance being defined. For example,

      (define-instance FRED (GUYS-WITH-GENERIC-NAMES 
                             GUYS-WITH-FOUR-LETTER-NAMES) 
          "The canonical random person name.") 

is logically equivalent to:

      (and (GUYS-WITH-GENERIC-NAMES FRED) 
           (GUYS-WITH-FOUR-LETTER-NAMES FRED)) 

<docstring> should be a string which describes the instance being

defined. It will be stored as the Lisp documentation (of type OL:ONTO-INSTANCE) for the symbol which names the instance.

The remaining keyword arguments may occur in any order, and are described below:

:= - The value of this keyword argument should be a KIF term

expression which denotes the instance being defined. For example:

        (define-instance PI (real-number) 
          "PI is the ratio of the perimeter of a circle to  
           its diameter." 
          := 3.145) 

:AXIOM-DEF - The value of this keyword argument should be a KIF

sentence which mentions the instance being defined; it will be asserted when the instance is defined. Terminologically, this sentence will be considered part of the definition of the instance. For example:

        (define-instance FRED (GUYS-WITH-GENERIC-NAMES) 
          "The canonical random person name." 
          :axiom-def (usual-temperament fred nice)) 

means that FRED is a member of the class GUYS-WITH-GENERIC-NAMES, and that FRED is usually nice. The axiom that fred is usually nice is considered part of the definition of FRED.

A list of sentences may be supplied instead of a single sentence; OntoLingua will automatically construct a conjunction of all the supplied :AXIOM-DEF sentences in this case.

:THEORY - The value of this keyword argument should be a symbol

which names the theory in which the instance should be defined. If the :THEORY argument is not supplied, the current theory is assumed (see IN-THEORY.)

:IMPLEMENTATION - The value of this keyword argument should be a

symbol (usually a keyword) which names the target representation system in which the instance should be defined. This is independent of the theory in which the instance is defined. If the :IMPLEMENTATION argument is not supplied, the current implementation is assumed (see IN-IMPLEMENTATION.)

:ISSUES - The value of this argument should be a Lisp "tree" of

strings. It is ignored by the translators, and is meant to provide a standard place for ontology authors to add human readable annotatations to their definitions.

In principle one could define OntoLingua classes, relations, and functions by making them instances of OL:CLASS, KIF:RELATION, and KIF:FUNCTION, but this is not guaranteed to do the right thing in supported implementations. For these cases, use DEFINE-CLASS (or CREATE-CLASS), DEFINE(CREATE)-RELATION, and DEFINE(CREATE)-FUNCTION.

Function Define-Relation

<relation-def> :== (DEFINE-RELATION <relation-name> (<var>+) 
                     [<docstring>] 
                     [:when <sent-with-arg-vars>] 
                     {:def | :iff-def} <sent-with-arg-vars> 
                     [:constraints <sent-with-arg-vars>] 
                     [:equivalent (<sent-with-arg-vars>*)] 
                     [:sufficient <sent-with-arg-vars>] 
                     [:default-constraints (<sent-with-arg-vars>*)] 
                     [:axiom-def <sent-without-arg-vars>] 
                     [:axiom-constraints <sent-without-arg-vars>] 
                     [:axiom-defaults (<sent-without-arg-vars>*)] 
                     [:theory <theory-name>] 
                     [:implementation <target-system-name>] 
                     [:class-slots (<slot-spec>*)] 
                     [:instance-slots (<extended-slot-spec>*)] 
                     [:default-slot-values (<slot-spec>*)] 
                     [:issues <issue-tree>]) 

Macro for defining relations. No arguments are evaluated. See also CREATE-RELATION, which is the functional form.

<relation-name> should be a symbol which names the relation being

defined. OntoLingua will convert this symbol into a format which is appropriate for the selected target representation system during translation (e.g., if one were translating into CycL, the symbol would be converted into a string which would obey the CycL conventions for case and word delimiters.)

<argument-list> is a list of symbols which name the entities related

by the relation being defined, e.g. (define-relation father-of (?father ?child)...) Within the sentences in the body of the DEFINE-RELATION form, these symbols are treated as variables bound to the objects related by the relation. The current KIF convention is to use symbols which begin with a "?", but since OntoLingua converts all variables to this format internally it is not strictly necessary to adhere to this convention.

Note: sequence-variables (indicated by a '@' prefix in KIF and Epikit) are not guaranteed to be supported in all target representation systems. This means that "portable" OntoLingua relations always have a fixed arity.

<docstring> when provided, should be a string which describes the

function being defined. It will be stored as the Lisp documentation (of type OL:ONTO-RELATION) for the symbol which names the relation. If a docstring is provided, it must immediately follow the argument list.

The remaining keyword arguments may occur in any order, and are described below:

:DEF - The value of this keyword argument should be a KIF sentence

that "defines" the relation; that is, a KIF sentence using the variables in ARGUMENTS as free variables that holds when the relation is asserted on specific instances. The purpose of the :DEF sentence is to specify constraints on consistent use of the relation; it should reflect the textual definition given in the docstring. Some implementations make special use of sentences labeled as definitions.

Logically, the :DEF sentence is implied by the relation. For example:

        (define-relation has-parent (?child ?parent) 
          "the relation from children to parents." 
          :def (and (person ?child) (person ?parent))) 

is logically equivalent to

        (=> (has-parent ?parent ?child)  
            (and (person ?parent) (person ?child))). 

:IFF-DEF - The value of this keyword argument should be a KIF

sentence that "completely defines" the relation. This is just like the :DEF keyword, except that the supplied sentence specifies both necessary and sufficient conditions for the relation to hold on any given bindings for the ARGUMENTS. For example:

        (define-relation has-mother (?child ?mother) 
          "child's mother" 
          :iff-def (and (has-parent ?child ?mother) 
                        (female ?mother))) 

is logically equivalent to

        (<=> (has-mother ?parent ?child) 
             (and (has-parent ?child ?other)  
	          (female ?mother))) 

It is not legal use both the :DEF and :IFF-DEF keywords in the same definition.

:CONSTRAINTS - The associated value should be a KIF sentence that

specifies necessary constraints on the relation that are not meant as part of the definition of the relation. The :CONSTRAINTS sentence is taken to be true for any bindings of ARGUMENTS for which the relation holds; it "follows" from the definition. One can also think of constraints as (monotonically) inherited facts about sets of instances for which the relation holds.

:CONSTRAINTS sentences are logically equivalent to :DEF sentences, and take the same form (i.e., sentences with terms that include free variables from the ARGUMENTS list.) The purpose of the distinction between definitional and nondefinitional constraints is to support terminological reasoning apart from other kinds of deductive inference. The :CONSTRAINTS sentence is an assertion used in nonterminological inference, such as inheritence of sentences used to ensure consistency.

A list of sentences may be supplied instead of a single sentence; OntoLingua will automatically construct a conjunction of all the supplied :CONSTRAINTS sentences in this case.

:SUFFICIENT - The value of this keyword arg should be a KIF sentence

that specifies sufficient constraints for the relation to hold for a given binding of ARGUMENTS. The :SUFFICIENT sentence thus specifies conditions under which the relation may be inferred; it may be used as a backward chaining deductive rule whose consequent is an instantiation of the relation.

A list of sentences may be supplied instead of a single sentence; OntoLingua will automatically construct a disjunction of all the supplied :SUFFICIENT sentences in this case.

:EQUIVALENT - The value of this keyword argument should be a list of

KIF sentences that specify biconditional constraints on the relation that are not meant as part of the definition of the relation.

:EQUIVALENT constraints are logically equivalent to :IFF-DEF constraints. The purpose of the distinction between definitional and nondefinitional constraints is to support terminological reasoning apart from other types of deductive inference. The :EQUIVALENT sentences are assertions used in nonterminological inference.

:DEFAULT-CONSTRAINTS - The value of this keyword argument should be

a list of KIF sentences that specify what "follows by default" from the relation. The precise operational semantics of nonmonotonic inference will depend on the target representation system. The intended use of :DEFAULT-CONSTRAINTS is to specify "default rules" whose anticendents are the relation with ARGUMENTS as free variables and whose consequents are each of the :DEFAULT-CONSTRAINTS sentences. The :DEFAULT-CONSTRAINTS sentences have the the same form as the :DEF and :CONSTRAINTS sentences.

When a ground assertion using the relation is asserted, then each of the :DEFAULT-CONSTRAINTS sentences will hold ("by default") for those bindings of ARGUMENTS until and unless a sentence that contradicts that DEFAULT-CONSTRAINTS sentence is asserted for those bindings. For example:

        (define-relation country-of-citizenship (?person ?country) 
          :default-constraints  
          (exists ?language  
            (and (languages-spoken ?person ?language) 
                 (official-language ?country ?language)))) 

means that if the country-of-citizenship of a person is known, then at least one of the languages that the person speaks is an official-language of the person's country-of-citizenship, unless this is explicitly asserted not to be the case.

:AXIOM-DEF - The associated value should be a KIF sentence; it will

be asserted along with the definition. Logically, this sentence neither implies nor is implied by the relation holding for a given binding of the variables in ARGUMENT-LIST; it is a standalone sentence. It should mention the relation being defined, however. If this axiom happens to mention the variables in ARGUMENT-LIST, then these variables are considered as any other unquantified KIF variables: they are assumed to be universally quantified. Thus, it's confusing to use the ARGUMENT-LIST variables in the :AXIOM-DEF sentences.

The :AXIOM-DEF sentence is considered to be definitional. That is, it is part of the definition as are :DEF and :IFF-DEF sentences.

A list of sentences may be supplied instead of a single sentence; OntoLingua will automatically construct a conjunction of all the supplied :AXIOM-DEF sentences in this case.

:AXIOM-CONSTRAINTS - The associated value should be a KIF sentence

which is a standalone sentence not related to the variables in ARGUMENT-LIST. It is the same as the :AXIOM-DEF sentence except it is nonterminological -- outside of the definition.

A list of sentences may be supplied instead of a single sentence; OntoLingua will automatically construct a conjunction of all the supplied :AXIOM-CONSTRAINTS sentences in this case.

:AXIOM-DEFAULTS - the value of this keyword should be a list of KIF

sentences with are not related to the variables in ARGUMENT-LIST. They should mention the relation being defined, however. Each of these sentences is taken to hold until and unless a contradictory sentence is asserted.

:THEORY - The value of this keyword argument should be a symbol

which names the theory in which the relation should be defined. If the :THEORY argument is not supplied, the current theory is assumed (see IN-THEORY.)

:IMPLEMENTATION - The value of this keyword argument should be a

symbol (usually a keyword) which names the target representation system in which the relation should be defined. This is independent of the theory in which the relation is defined. If the :IMPLEMENTATION argument is not supplied, the current implementation is assumed (see IN-IMPLEMENTATION.)

:ISSUES - The value of this argument should be a Lisp "tree" of

strings. It is ignored by the translators, and is meant to provide a standard place for ontology authors to add human readable annotatations to their definitions.

:CLASS-SLOTS, :INSTANCE-SLOTS, and :DEFAULT-SLOT-VALUES - These

keyword arguments are discussed below, under "Alternate Slot Syntax."

Second Order Sentences

Within the :AXIOM-DEF there may be sentences that specify properties of the relation being defined, rather than properties of the instances related by the relation being defined. Such sentences use the names of relations as arguments to special "second order" relations. For example, consider the following definition:

     (define-relation in-module (?port ?module) 
       "Function from a port to its associated module. 
        Each port has at most one associated module." 
       :def (and (port ?port) 
                  (module ?module)) 
       :axiom-def (OL:SINGLE-VALUED in-module)) 

In the :AXIOM-DEF sentence, IN-MODULE is said to be a SINGLE-VALUED relation, which means:

      (=> (and (in-module ?x ?y) (in-module ?x ?z)) (= ?y ?z)). 

The symbol IN-MODULE denotes the relation of that name. Since the argument to SINGLE-VALUED, IN-MODULE, is also a relation, SINGLE-VALUED is called a second-order relation.

Second order relations capture many conventions for defining and organizing terms in concise ways. For example, in the following definition, MODULE-PORTS is defined as the inverse of IN-MODULE. That is all that needs to be stated about this term; everything true of IN-MODULE is true of MODULE-PORTS with its arguments reversed:

      (define-relation module-ports (?module ?port) 
        "The ports associated with a module." 
        :axiom-def (OL:INVERSE module-ports in-module)) 

Terminologically, second-order sentences are always considered to be definitional. Only a restricted set of second-order relations are allowed; these are defined in the frame ontology.

Alternate Slot Syntax

OntoLingua supports additional syntax for writing some definition sentences in a frame/slot style instead of the predicate calculus style of KIF. This additional syntax is supported via three additional definition keywords, whose associated values are lists of sentences in the following format, called a SLOT-VALUE-SPEC:

      (slot-name slot-value1 slot-value2 ...)  

SLOT-NAME is the name of a binary relation. The first argument to this binary-relation (the frame) is made implicit by the keyword with which the sentence is associated, and each SLOT-VALUE is a second argument to the relation.

During the translation process, OntoLingua will transform such a sentence into the equivalent KIF sentences

      (slot-name frame slot-value-1) 
      (slot-name frame slot-value-2)... 

These resulting sentences will be added to the :AXIOM-DEF, :CONSTRAINTS,

:AXIOM-CONSTRAINTS, or :DEFAULT-CONSTRAINTS sentences depending on the

keyword with which the original slot-syntax sentences are associated.

The three keywords supported in this manner are as follows:

:CLASS-SLOTS - The associated value should be a list of SLOT-VALUE-SPECs whose frames are taken to be the relation being defined. Thus, the relations corresponding to the slot

      names are second-order relations (see "Second Order Sentences" 

above.) Sentences translated from :CLASS-SLOTS are added to the

      :AXIOM-DEF sentence. 

:INSTANCE-SLOTS - This keyword is only valid in the definition of unary relations (or equivalently, classes.) The associated value should be a list of SLOT-VALUE-SPECs sentences whose frames are taken to be individuals for which the unary relation holds. Sentences translated from :INSTANCE-SLOTS are added to the :CONSTRAINTS sentence.

An exteded slot syntax is supported for this keyword which allows values for "facets" of slots to be provided. Within the SLOT-VALUE-SPECS any of the slot-values may be a list of the

      form: 

         (facet facet-value1 facet-value2...). 

OntoLingua will transform these into the equivalent KIF

      sentences: 

         (facet relation slot facet-value1) 
         (facet relation slot facet-value2) 

...

:DEFAULT-SLOT-VALUES - This keyword is only valid in the definition of unary relations (or equivalently, classes.) The associated value should be a list SLOT-VALUE-SPECs sentences whose frames are taken to be individuals for which the unary relation holds. Sentences translated form :DEFAULT-SLOT-VALUES are added to the :DEFAULT-CONSTRAINTS sentences, and will therefore hold for each instance of the class until and unless a contrary assertion is made about that instance.

Function Define-Theory

<theory-def> :== (DEFINE-THEORY <theory-name> ([<theory-name>]*) 
                   [<docstring>] 
                   [:implementation <target-KR-system-name>] 
                   [:io-package <lisp-package-name>] 
                   [:issues <issue-tree>] 
                   <other-initargs>*) 

Macro for defining or modifying OntoLingua theories. No arguments are evaluated. See also CREATE-THEORY, which is the functional form.

<theory-name> - a symbol which names the theory to be defined of modified.

Package is significant. If an appropriate theory already exists, it will be updated; IT WILL NOT BE EMPTIED OR RESET.

<included-theories> - a list of theory objects (or symbols which name

theories) to be included in the theory being defined or modified.

<docstring> if supplied, should be a string describing the theory

being defined or modified. This string will be stored as the documentation (of type OL:ONTO-THEORY) of the symbol which names the theory.

<key-arg-pairs> - an alternating list of keywords an values preceded by

an optional docstring. Supported keywords are:

The following keyword arguments are also supported; all other supplied keyword arguments will be spliced into the init-plist of the CLOS object which represents the theory being defined of modified when it is instantiated or reinitialized, respectively.

:IMPLEMENTATION - The value of this keyword argument indicates the

desired implementation for the theory to be defined or modified. It may be either a symbol (usually a keyword) which names an implementation, or a list whose first element is such a symbol. If a list, the tail of the list will be included in the init-plist of the CLOS object which represents the theory being defined or modified when it is instantiated or reinitialized, respectively. This provides a convenient way to individually tailor theory instances within a single implementation.

If this keyword is unspecified, the current implementation (see IN-IMPLEMENTATION) will be assumed.

:IO-PACKAGE - The value of this keyword arg should be a package or a

symbol or string which names one; this value is put in the IO-PACKAGE slot on the theory object being defined or modified. User interface code which operates on behalf of the theory can then examine this slot for a suggestion of a good package to use when printing and reading.

Function Delete-Theory

Deletes the specified theory. All included theories will be unincluded. All including theories will be made to uninclude the theory being deleted. Returns T if an appropriate theory was found and deleted, nil otherwise. See also DELETE-THEORY-AND-CHILDREN.

<theory> may be any object acceptable to FIND-THEORY. If unspecified,

the current theory is assumed (see IN-THEORY.)

If <theory> is not a theory object, <implementation> will be examined to determine which implementation of the specified theory should be deleted. <implementation> should be a symbol (usually a keyword); if unspecified, they current implementation is assumed (see IN-IMPLEMENTATION.)

Function Delete-Theory-And-Children

  [<theory>] [<implementation>] 

Deletes the specified theory and all theories which include it, recursively. Theories which are included by theories being deleted will be unincluded prior to deletion. Returns T if at least one appropriate theory was found and deleted, nil otherwise. See also DELETE-THEORY.

<theory> may be any object acceptable to FIND-THEORY. If unspecified,

the current theory is assumed (see IN-THEORY.)

If <theory> is not a theory object, <implementation> will be examined to determine which implementation of the specified theory should be deleted. <implementation> should be a symbol (usually a keyword); if unspecified, they current implementation is assumed (see IN-IMPLEMENTATION.)

Function Find-Theory

Looks for a theory associated with <object>. <object> may be a theory in which case it is simply returned, a symbol which names a theory, or a string which is the printed representation of such a symbol.

If <object> is a symbol or string, a theory named by <object> and associated with implementation <implementation> is sought.

<implementation> should be a symbol (usually a keyword); if

unspecified, the current implementation is assumed (see IN-IMPLEMENTATION.)

If IMPLEMENTATION is NIL (not the same as the default), then any theory matching the OBJECT is acceptable (i.e., the theory returned can be in any implementation).

<error-p> determines what action will be taken if an appropriate theory cannot be found: if <error-p> is nil FIND-THEORY will return nil; otherwise, an error will be signalled.

Function Htmlify-Directory

(htmlify-directory INPUT-DIRECTORY OUTPUT-DIRECTORY

     :NON-ONTO-FILES ([(<file-name> [<theory-name>]*)]*) 
     :THEORIES-TO-INCLUDE ([<theory-name>]*) 

HTMLIFY-DIRECTORY processes a directory of files, some of which are Ontolingua source files, and produces a directory of HTML documents. Any files that have type "lisp" in the input-directory are assumed to be readable by Lisp and will be loaded by Ontolingua. Any other files are candidate non-onto-files. These non-onto files will also be indexed, against the theories specified in :non-onto-files.

INPUT-DIRECTORY is a pathname specification of the directory from which to read the source files. It should be a pathname, NOT A DIRECTORY SPEC. For example, "/users/fred/ontos/" is a valid spec for the pathname

     whose directory component is '(:absolute "users" "fred" "ontos"). 

Notice that the string has a trailing '/' character. In Unix this

     is important to include (on Macs the character is ':'). 

OUTPUT-DIRECTORY is a pathname specification for the directory into which the HTML documents will be written. Ontolingua will arrange the HTML links so that all URLs are relative to this directory. That means that the resulting directory of HTML documents can be moved and will still work.

:NON-ONTO-FILES is a list of lists of the form

(<file-name> <theory-name> <theory-name> ...) Each of these forms specifies a non-ontolingua source file to process and a set of theories against which to index it. For example,

     ("my-intro.text" :my-theory) 

says to index my-intro.text with respect to the theory :my-theory. Any works in my-intro.text that are defined in :my-theory or any of its included theories will be linked by hypertext links to their definitions. If a file is not listed on :non-onto-files, then it will be indexed against all of the loaded ontolingua theories.

     <file-name> is a string of the form "name.type" 

and each <theory-name> is a symbol naming a theory. Theories can be specified with keywords, and this is the safest way to specify theories that haven't yet been loaded.

:THEORIES-TO-INCLUDE is a list of theory-names (e.g. keywords) that allows

the user to select just some of the loaded theories for processing. The default is NIL, which means process all loaded theories.

Function Implementation-P

Predicate which tests whether or not <thing> is the name of a valid OntoLingua implementation (an OntoLingua implementation is a CLOS object which represents a supported target representation system.) See also *ALL-IMPLEMENTATIONS*.

Function In-Implementation

Changes the current OntoLingua implementation to the one indicated by

<name> (an OntoLingua implementation is a CLOS object which represents

a supported target representation system.) <name> should be a symbol; if no implementation of that name exists, an error is signalled. A list of acceptable implementation names may be found on the variable

*ALL- IMPLEMENTATIONS*. 

If the keyword argument :THEORY-ACTION is supplied and is non-nil, OntoLingua will attempt to locate a theory of the new implementation with the same name as the current theory and make that theory current (see IN-THEORY); if such a theory cannot be located it will be instantiated. If the value of :THEORY-ACTION is :QUERY (the default) the user will be queried before any such instantiated takes place.

Unlike IN-PACKAGE, an IN-IMPLEMENTATION form at top level in a file affects only the load environment (see ONTO-LOAD.)

Function In-Theory

Changes the current default theory to the one indicated by <theory> and <implementation>.

<theory> may be any type acceptable to FIND-THEORY. If it is not a

theory object, <implementation> will be examined to determine which implementation of the specified theory should be made current. <implementation> should be a symbol (usually a keyword); if unspecified, the current implementation is assumed (see IN-IMPLEMENTATION.)

The action taken if appropriate theory does not exist depends on the :CREATE-P keyword argument. If :CREATE-P not supplied or supplied and nil, then an error is signalled. If :CREATE-P is supplied and non-nil, an appropriate theory is instantiated. If CREATE-P is :QUERY (the default), the user will be queried before any such instantiation takes place.

Unlike IN-PACKAGE, an IN-THEORY form at top level in a file side-effects only the load environment (with the possible exception of theory instantiation, as described above.) See also ONTO-LOAD.

NOTE: Somewhat bogusly, evaluation of an IN-THEORY form when not loading a file will cause "appropriate" side effects in the indicated implementation; this behavior may be corrected by setting OLI:*DISABLE-THEORY-SWITCHING-SIDE-EFFECTS* to T.

Function Onto-Help

Prints a short introduction to ontolingua. With a non-NIL argument, returns a list of supported ontolingua symbols.

Function Onto-Load

Just like COMMON-LISP:LOAD, except that loading is done with OL:*DISABLE- THEORY-SWITCHING-SIDE-EFFECTS bound to T and with fresh bindings of *CURRENT-THEORY* and *IMPLEMENTATION*. This is necessary to limit the effect of IN-THEORY and IN-IMPLEMENTATION forms to the file which contains them.

NOTE: In most OntoLingua ports, COMMON-LISP:LOAD is "advised" to make the appropriate bindings

Function Reset-Implementation

Clears all theories (see CLEAR-THEORY) associated with an OntoLingua implementation except the OL:FRAME-ONTOLOGY theory. This may have other implementation dependent side effects, as well.

<implementation> should be a symbol (usually a keyword) which names a

valid OntoLingua implementation; if unspecified, the current implementation is a assumed (see IN-IMPLEMENTATION.)

Function Theory-Equal-P

Predicate for testing wheter <thing1> and <thing2> refer to the same theory. <thing1> and <thing2> may be any object acceptable to FIND-THEORY; if either of them is not a theory object then

<implementation> will be examined to determine which implementation of

the specified theory to consider. <implementation> should be a symbol (usually a keyword); if unspecified, the current implementation is will be assumed (see IN-IMPLEMENTATION.)

Function Theory-P

Predicate which tests whether <thing> is a theory, or the name of a theory of implementation <implementation>. <implementation> should be a symbol (usually a keyword); if not specified, the current implementation is assumed (see IN-IMPLEMENTATION.)

Function Translate-File

Translates an ontolingua file. Input is taken from the file

<ontology-file>, translated under implemenation <implementation> (or

ol:*implementation* if <implementation> is not provided) and any output sent to ol:*translation-output-stream* is sent to the file <output-file>. If <output-file> is not provided, it defaults to <input-file> with an appropriate extension suffixed.

Function Uninclude-Theory

Unincludes the theory specified by <includee> from the theory specified by <includer>. Returns T if an appropriate theory was found and unincluded, nil otherwise.

<includee> and <includer> may be any objects acceptable to FIND-THEORY.

If <includer> is not specified, the current theory will be assumed

(see IN-THEORY.) 

If either <includee> or <includer> is not a theory object, <implementation> will be examined to determine which implementation of the specified theory to consider. <implementation> should be a symbol (usually a keyword); if unspecified, the current implementation will be assumed

(see IN-IMPLEMENTATION.) 

Function Xref-Theory

Cross reference utility for Ontolingua theories. Tries to cross reference the theory specified by <theory-or-name>. If no such theory can be found, the file specified by <theory-filename> will be loaded. If <theory-filename> was not provided, the user will be prompted for a file to load. A cross reference report for the specified is then output on *standard-output*. If use-html-p is T then then the report will be generated in html with hyper-text references.

Function Xref-Theory-To-File

Generates a cross reference report on THEORY, printed to OUTPUT-FILE. If OUTPUT-FILE is NIL or bot supplied, then it uses INPUT-FILE with the file type '.xref'. If INPUT-FILE is nil or not given, then it assumes the theory has been loaded and uses the file from which it was loaded.

Variable *All-Implementations*

The value of this variable is a list of the names of all currently defined OntoLingua implementations. An OntoLingua implementation is a CLOS object which represents a supported target representation system. This variable should never be altered by the user. Implementations are added to this list when back-end translators are loaded. For example, the LOOM translator will be loaded if LOOM is around when Ontolingua is loaded. Then the symbol :LOOM will be on the *ALL-IMPLEMENTATIONS* list.

Variable *All-Theories*

The value of this variable is a list of all currently defined OntoLingua theories. This variable should never be altered by the user directly; use DEFINE-THEORY or CREATE-THEORY to define new theories and DELETE-THEORY to delete them. The objects on this list are CLOS instances. There can be several theories per ontology, and even several per ontology and implementation.

Variable *Current-Theory*

The value of this variable is the current OntoLingua theory. This variable should never be altered by the user directly; use IN-THEORY to set the current theory.

Variable *Disable-Theory-Switching-Side-Effects*

When the value of this variable is T, IN-THEORY is guaranteed not to have side effects on target representation systems. When nil (the default!) "appropriate" side effects will occur, depending on the implementation of the theory being made current.

Variable *Implementation*

The value of this variable is a symbol which names the current OntoLingua implementation (an OntoLingua implementation is a CLOS object which represents a supported target representation system.) This variable should never be altered by the user directly; use IN-IMPLEMENTATION to set the current implementation.

Variable *Onto-Trace*

Controls the output behavior of OntoLingua Translators:

nil - no tracing information given, and translated definitions side-effect the environment (usually by storing assertions in some database or calling the target representation system)

a stream - a trace of the translation process will be output to the specified stream. Use *translation-output-stream* for creating files of the translation.

:print-only - translations will be output to *trace-output*,

but will not have any side effects

a list - a conjunction of a stream, :print-only, and/or NIL

anything else - translations will be output to *trace-output*

Variable *Supported-Second-Order-Relations*

List of currently supported second-order relations. Supported means that these are either generated by or recognized by ontolingua translators.

Variable *Translation-Output-Stream*

The stream where translation output is sent, if enabled. This is used by TRANSLATE-FILE to generate translations of ontolingua ontologies in some other language syntax. A value of NIL indicates that the translated definitions should be sent as data directly to the target representation system, by function call. If this is not possible, the output is sent to *standard-output*.