Loom® 3.0 Release Notes

Three major changes have been made. The first major change in Loom® 3.0 is the addition of a full context mechanism. (This was in Loom 3.0b1 as well). The second major change was to eliminate the distinction between tell and tellm. All assertions now advance agent time! Details are below. The third major change is that a Web-based Browser is now available for Loom. . The is being made available as a separate software package. It requires MIT's CL-HTTP program (version 60.17) to be used.

Other changes are the addition of a new method for reification and support for writing Loom contexts out in an HTML browsable form. The SAVE-CONTEXT function has been improved in various ways. In addition, there have been a few changes made to the TBox. Some of the changes are not backwards compatible. Obsolete relation and concept names have been retained for compatibility, but they are not loaded by default! In order to have them present you will need to set the loom feature :load-obsolete-concepts and then call (initialize-network). There are some incompatible changes to contexts and the patch file has been renamed in a way that will make updating patches simpler. Finally, we have improved some of the reasoning that involves host constants like numbers, symbols and strings.

  1. Incompatible Changes from Loom 3.0b1
  2. Upper-Structure-KB Changed
  3. Tell and Tellm are Now the Same
  4. Context Mechanism
  5. HTML Support
  6. New Model for Reified Relations
  7. Changes to the TBox
  8. New and Changed loom-features
  9. CLOS Instances Support
  10. Preview of Loom 3.1 Features

Installation instructions for all systems can be found in the file


Incompatible Changes from Loom 3.0b1

There are several changes that are incompatible with previous versions of Loom (including the beta release of Loom 3.0). The following details those differences:

The query operator :within-context has been removed from the query language. It has been replaced with two constructs :within-world and :within-theory. For details see below under Context Mechanism. Note that this does not affect the macro within-context, just the query operator.

Open/Closed world default is now handled at the context level. Whether newly defined concepts use open or closed world reasoning is now determined by a setting on the context (theory) that they are defined in. The global setting via (set-feature :open-world) or (set-feature :closed-world) now applies only to the creation of contexts. For details see below under Context Mechanism.

Patch file renamed. The patch file has been renamed from "loom-patches.lisp" to "loom3-0-patches.lisp". This change means that the system patch file will now match the file name we use on the ftp server. The upshot is that you will be able to copy the file directly from the ftp server into the patch directory without the need to rename it.

The function get-role-types has been changed to take the range of a relation into account when computing the type restriction of a role on a concept or instance. system-defined-p is no longer a macro. It is now a function.

Upper-Structure-KB Renamed

The standard knowledge base has becomes a context (see below) named BUILT-IN-THEORY. There is no knowledge base object associated with this context. For compatibility, the extended prefix "UPPER-STRUCTURE-KB^" will be interpreted correctly. This will only affect those users who refer to the knowledge base directly by name. This change was already made in version 2.1

Tell and Tellm are Now the Same

The distinction between TELL and TELLM and their analogues has been removed. Now all assertions cause the knowledge base state to advance. This can change when production rules fire in applications. To address this issue, a new macro WITHOUT-PRODUCTIONS has been introduced. This is part of a more general transaction system.

WITHOUT-PRODUCTIONS &body                                       [Macro]
Execute the forms in `body' with the triggering of production rules suspended until the end of the form. After exiting without-productions, all eligble production rules are fired. [Note: Rete match changes will be displayed during the execution of `body' but the associated rules will not fire until all forms in `body' have been executed.]

Context Mechanism

Knowledge bases have been modified extensively, although most of the modifications should be hidden from most users. All KBs now have a context associated with them. The context has a name generated by taking the root name of the KB and adding the suffix -THEORY to it.

The major changes in behavior is that all names (for concepts, instances, etc.) are context sensitive. The extensions of concepts are now context-sensitive. Also, assertions are now context sensitive, as are the triggers for production rules. Contexts are hierarchical and information is inherited from parent contexts. Any assertions made in a context are also automatically made seperately in all of its sub-contexts.

Contexts can inherit from multiple parents. This is only allowed if all name references can be uniquely resolved. Also, assertions can be made about contexts themselves. That means that once can attach roles and assert role fillers on contexts. Contexts can be accessed by name using the relation the-context with a quoted name.

Temporal information is not yet context sensitive. There may still be some problems with concepts and relations that are defined in subcontexts interacting with supercontexts and sibling contexts. This can potentially cause some problems.

The following new functions have been added to the Loom programmer's interface to support contexts. The existing functions change-kb, in-kb, save-kb, etc. continue to function as before.

CC   &optional contextName		                         [Macro]
Change context, or if `contextName' is null, return the current context.

CHANGE-CONTEXT   contextOrName		                      [Function]
Replace the top of the context stack with the context `contextOrName' and reset the current context. Return the new current context.

CONTEXT-STACK   		                              [Function]
Return the current context stack. The context stack is manipulated by pushing and popping contexts or by executing `change-context'.

CREATION-POLICY   &optional policy		              [Function]
Set the creation policy of the current context to `policy'. Legal values are :classified-instance, :lite-instance, or :clos-instance. If `policy' is null, return the creation policy of the current context.

CURRENT-CONTEXT   		                              [Function]
Return the current context.

DEFCONTEXT   contextName typeOfContext parentContexts            [Macro]
             &key :creation-policy :monotonic-p :open-closed-mode
Create a new context called `contextName' of type `typeOfContext' that inherits the contexts `parentContexts'. Legal types are :theory, :workspace, :island, and :world. `creation-policy' indicates the meta-class for instances created in this context -- this establishes the inference policy for the context. Legal policies are `:classified-instance', `:lite-instance', and :clos-instance. The default policy creates CLOS instances for workspaces and LITE instances for theories. `open-closed-mode' indicates the setting for open or closed world reasoning for this context. If not provided, the global setting as determined by the Loom features is used.

DEFINE-CONTEXT   name typeOfContext parentContexts            [Function]
                 &key :creation-policy :monotonic-p :open-closed-mode
Create a new context called `contextName' of type `typeOfContext' that inherits the contexts `parentContexts'. Legal types are :theory, :workspace, :island, and :world. `creation-policy' indicates the meta-class for instances created in `context' -- this establishes the inference policy for the context. Legal policies are `:classified-instance', `:lite-instance', and :clos-instance. The default policy creates CLOS instances for workspaces and LITE instances for theories. `open-closed-mode' indicates the setting for open or closed world reasoning for this context. If not provided, the global setting as determined by the Loom features is used.

DESTROY-CONTEXT   contextOrName		                      [Function]
Destroy the context `context' and all contexts below it.

EXPORT-NAMES-IN-CONTEXT   contextOrName		              [Function]
Place names of all objects belonging to `contextOrName' on package export list(s).

FIND-CONTEXT contextOrName &key :error-p [Function] Return the context whose name matches `contextOrName'. If `error-p', then generate an error if there is no such context. Note: `get-context' is slightly faster, but can't handle strings and eliminates type checking.

GET-CONTEXT   contextOrName		                      [Function]
Return the context whose name matches `contextOrName'. Assumes that a non-symbol is a legal context.

IN-CONTEXT   contextName                                         [Macro]
Replace the top of the context stack with the context `contextName' and reset the current context. Unlike `change-context', `in-context' evaluates at compile and load time. It can only appear at top-level in a Lisp program. (See also the macro WITHIN-CONTEXT)

LIST-CONTEXT   &rest arguments		                         [Macro]
Return a list of objects in the specified `partitions' of the context named `context'.
The :partitions keyword indicates what partitions are to be retrieved, while the optional parameter `context' indicates what context to use.
Setting the keyword :sort-p to t causes the result to be sorted. Setting :sort-p to :sort-each-partition causes individual partitions to be sorted.

LIST-CONTEXTS                                                 [Function]
Return a list of all contexts defined in Loom.

 OPEN-CLOSED-MODE context		        [Slot Accessor Function]
Return the reasoning mode used by default for newly created concepts and relations in `context'. The value returned will be `:open' or `:closed'. The default setting can be changed using setf with this accessor function. Note that this setting only affects newly defined (or redefined) concepts and relations in the context. Existing concepts and relations will not be affected by changes in this mode.

PUSH-CONTEXT   contextOrName	                              [Function]
Push the context `contextOrName' onto the context stack, and make it the current context. Return the new current context.

POP-CONTEXT   		                                      [Function]
Pop the current context from the context stack, and make the new top-most context on the stack the current context. Return the new current context.

SAVE-CONTEXT [contextOrName] &key pathname stream partitions  [Function]
Save `contextOrName' if specified, otherwise the current context. If `partitions' is specified, then only the listed partitions are saved. Otherwise all partitions are saved. The output will be sent to the file `pathname' or the stream `stream'. If both are specified, then `pathname' takes precedence. If neither is specified then a warning is printed and the context is not saved.

WITHIN-CONTEXT   contextOrName  &body body	                 [Macro]
Execute `body' with context temporarily set to `contextOrName'. This wrapper performs a `push-context' before executing `body' and a `pop-context' afterwards.

Addition to Query language

(:WITHIN-THEORY context queryExpression)
(:WITHIN-WORLD context queryExpression)
The forms :within-theory and :within-world have been added to the query language. The `context' can be either the name of a context or a variable. The variable can be either bound or generated by Loom. `queryExpression' is any legal Loom query expression.


    (retrieve ?x (:and (:within-world C1 (R Fred ?x))
  	               (:within-world C2 (R Sue ?x))))
retrieves all values of Fred's R relation in context C1 that are also values of Sue's R relation in context C2. `R', `Fred' and `Sue' refer to the relation and instances visible in the context in which the retrieve statement is executed or compiled.

    (retrieve ?x (:and (:within-theory C1 (R Fred ?x))
	               (:within-theory C2 (R Sue ?x))))
retrieves all values of Fred's R relation in context C1 that are also values of Sue's R relation in context C2. The first `R' and `Fred' are looked up in context C1. The second `R' and `Sue' are looked up in context C2. The relations referred to by `R' may or may not be the same. They would be the same only if C1 and C2 shared a common parent and inherited R from there. The values returned by ?x must be fillers in both contexts.

     (retrieve ?c (:within-world ?c (Married Bill Jane)))
retrieves all contexts in which Bill and Jane are Married. Again, `Bill', `Jane' and `Married' are looked up in the context in which the retrieve statement occurs or is compiled.

     (retrieve ?c (:within-theory ?c (Married Bill Jane)))
retrieves all contexts in which Bill and Jane are Married. In this case `Bill', `Jane' and `Married' are dynamically looked up in the current context bound to the variable `?c'. If `Married' is not defined in that context or if there are no instances named `Bill' or `Jane' then the query will fail for that particular binding of `?c'. It is NOT an error.

Assertions about contexts

One can now make assertions about contexts. A short example follows:

(defcontext Cx1 :theory nil)
(defcontext Cx2 :theory nil)
(defcontext Cx3 :theory nil)

(tellm (encodes-beliefs-of (the-context 'CX1) Bill)
       (encodes-beliefs-of (the-context 'CX2) Mary)
       (encodes-beliefs-of (the-context 'CX3) Fred)
       (base-language (the-context 'CX3) Swahili))

(retrieve ?x (:exists ?y (:and (encodes-beliefs-of ?x ?y) (Male ?y))))

  ==> (|CXT|CX1 |CXT|CX3)

Changed Argument Documentation

The following functions and macros used to take :context as a keyword argument. They no longer accept this argument. Instead, calls to the functions should occur in the body of a WITHIN-CONTEXT form. This change is for increased efficiency.

ADD-TYPE      instanceOrId conceptOrName &key  no-error-p
ADD-VALUE     instanceOrId roleOrName fillerOrId &key no-error-p
GET-INVERSE-VALUES instanceOrId roleOrName &key no-error-p
GET-VALUE          instanceOrId roleOrName &key no-error-p
GET-VALUES         instanceOrId roleOrName &key no-error-p
REMOVE-TYPE   instanceOrId conceptOrName &key no-error-p
REMOVE-VALUE  instanceOrId roleOrName fillerOrId &key no-error-p
SET-VALUE     instanceOrId roleOrName fillerOrId &key no-error-p
SET-VALUES    instanceOrId roleOrName fillersOrIds &key no-error-p

HTML Support

A new function that will print a context in an HTML format file for browsing has been added to Loom. This file will have hypertext links between concepts and their definitions. It will also have links between assertions and the concepts, relations and instances that are referenced. References to items defined in other contexts are supported, but require adherence to a naming scheme whereby all files are in the same directory and the filename is the context name with the extension .html added.

HTML-PRINT-CONTEXT context [Function] &optional filename &key link-to-built-in-p Save "context" in html format in the file "filename". If "filename" is not specified, then a name is constructed from the name of the context and given extension `.html'. Names to Loom objects will have hypertext links added. Links to concepts or relations in the BUILT-IN-THEORY will only be added if the keyword parameter "link-to-built-in-p" is not NIL. This parameter is NIL by default.

New Model for Reified Relations

Loom 3.0 has added a new model for using reified relations. The details can be found in the file reification.ps (PostScript) or reification.pdf (PDF).

Changes to the TBox

There have been a number of changes to the TBox. Mostly this has been the substitution of new names for existing concepts and relations. There is a table describing the changes located below. A few new concepts and relations have been added to support new features.


The old names for relations and concepts have been retained for the most part, but they are no longer loaded into BUILT-IN-THEORY by default. To load them, users will have to set a special loom feature and then reinitialize the network:

   (set-feature :load-obsolete-concepts)
Note that doing this will clear out all existing information in all contexts loaded into Loom.


The concept META-CONCEPT has been incompatibly changed. It is now called META-THING. A concept named META-CONCEPT is still present in Loom's BUILT-IN-THEORY BUT IT HAS A DIFFERENT MEANING. This change may require changes to user code.


There is now a DEFPROPERTY form that allows the definition of unary relations. Unary relations operate in ways that are similar to concepts. The can be defined using normal Loom concept building constructs. In addition, they can take a :DOMAIN option.

For modelling purposes, we suggest considering Concepts as being more fundamental and less mutable than Properties. Using this modeling approach, one would choose to have Man be a concept and Teenager a property. That is because Teenager is a transient aspect of a human being while gender (generally) does not change. [Note: The concept that instances belong to can still be changed in the same way as in the past].


Concept    META-CONCEPT		Concept whose instances are Concepts
Concept    META-THING		Replaces previous version's Meta-Concept
Concept    PROPOSITION		
Concept    REIFICATION		New Reification Concept

Relation   ANCESTOR-CONTEXT	Transitive closure of Parent-Context
Relation   ARCHETYPE		Links a meta-concept to the superclass of
				the meta-concept's instances.  To be used for
				inheritance and method definition.
Relation   CHILD-CONTEXT	Relation for finding sub contexts
Relation   DESCENDANT-CONTEXT	Transitive closure of Child-Context
Relation   HOLDS-TRUE-2		
Relation   HOLDS-TRUE-3		
Relation   HOLDS-TRUE-4		
Relation   HOME-CONTEXT		Context in which an object/instance is defined
Relation   IDENTITY		Identity relation
Relation   LINK                 Retrieves a reification object for a particular
                                source/filler relation pair.
Relation   PARENT-CONTEXT	Relation for finding super concepts
Relation   REIFIES		Links a concept to the relation it reifies
Relation   REIFIED-BY         	Links a relation to the concept that reifies it
Relation   TARGET-CASE		Default role for linking the target to a
                                reification link
Relation   TARGET-ROLE          Relation linking a reifying concept to its
				target case role.
Relation   THE-CONTEXT		Relation to map names to contexts
Relation   THE-INSTANCE		Relation to map names to instances
Relation   SOURCE-CASE          Default role for linking the source to a
                                reification link
Relation   SOURCE-ROLE          Relation linking a reifying concept to its
				source case role.

Obsolete Concepts and Relations

The following concepts and relations are now considered obsolete. They are no longer present in BUILT-IN-THEORY by default. If you wish to continue using them, you will need to explicitly set the Loom feature :load-obsolete-concepts:

   (set-feature :load-obsolete-concepts)
At some point in the future (although maybe not in your lifetime :) these concepts and relations will disappear from Loom entirely.

  Type           Old Name        	     New Substitute
--------    ------------------          ------------------------
Concept     Old-Role			
Concept     max-restriction		[Use Roles *]
Concept     max-restriction-p		max-restriction
Concept     min-restriction		[Use Roles *]
Concept     min-restriction-p		min-restriction
Concept     named-p			user-defined
Concept     Restriction			[Use Roles *]
Concept     restriction-p		restriction
Concept     value-restriction		[Use Roles *]
Concept     value-restriction-p		value-restriction
Property    primitive-p			primitive
Property    single-valued-p		single-valued
Property    user-defined-p		user-defined
Relation    concept--attributes		characteristics
Relation    concept--characteristics	characteristics
Relation    concept--instances		instances
Relation    concept--name		loom::name
Relation    concept--restrictions	[Use Roles *] roles
Relation    direct-dependents		
Relation    direct-subconcept		direct-subrelations
Relation    direct-subconcepts		direct-subrelations
Relation    direct-superconcept		direct-superrelations
Relation    direct-superconcepts	direct-superrelations
Relation    has-role			roles
Relation    identifier--instance	the-instance
Relation    instance--asserted-concepts	
Relation    instance--asserted-type	
Relation    instance--cached-concepts	
Relation    instance--concepts		instance-of
Relation    instance--forward-chaining-type	
Relation    instance--identifier	loom::name
Relation    instance--max-restriction	role-max-cardinality
Relation    instance--min-restriction	role-min-cardinality
Relation    instance--type		instance-of
Relation    instance--value-restriction	role-types
Relation    instance-of-p		instance-of
Relation    isa-p			isa
Relation    name--concept		(the-relation  1 )  ***
Relation    name--relation		(the-relation   ) ***
Relation    relation--domain		domain
Relation    relation--name		loom::name
Relation    relation--range		range
Relation    relation--restrictions	restrictions
Relation    restriction--concepts	[Use Roles *] concept
Relation    restriction--max		[Use Roles *] max-cardinality
Relation    restriction--min		[Use Roles *] min-cardinality
Relation    restriction--qualification	qualification
Relation    restriction--relation	[Use Roles *] relation
Relation    restriction--value-restriction	[Use Roles *] types
Relation    role--concept		concept
Relation    role--instance		       (Old Style Roles)
Relation    role--relation		       (Old Style Roles)
Relation    role--value			       (Old Style Roles)
Relation    subconcept*			subrelations
Relation    subconcepts			subrelations
Relation    superconcept*		
Relation    superconcept+		superrelations
Relation    superconcepts		superrelations

Notes about Obsolete Concepts and Relations

* [Use Roles] We are recommending not using the restrictions but using Role objects instead. Role objects can be retrieved using the binary relation "roles" on a concept to return all roles or the ternary relation "the-role" which returns a role object for a Concept, Relation pair. Once a role object is available, information about number and value restrictions can be obtained using the following relations:
cardinality (Only has a value if min = max)

** There is no equivalent for these relations. If you are using them, please contact the loom development team and we will work something out.

*** The relation "the-relation" is a ternary (3-place) relation that relates a SYMBOL, NUMBER and CONCEPT/RELATION. The number is the arity of the relation. Concepts are considered unary relations. Using this form instead of the obsolete "name--relation" requires that you know the arity of the relation you wish to find, but it is probably a good idea to know that anyway. The most common relations are binary, so the arity would be 2. Examples:

   (retrieve ?c (the-relation 'concept 1 ?x))  ==>  (|C|CONCEPT)
   (retrieve ?c (the-relation 'domain 2 ?x))   ==>  (|R|DOMAIN)
   (retrieve ?c (the-relation '< 2 ?x))        ==>  (|R|<)
   (retrieve ?c (the-relation '+ 3 ?x))        ==>  (|R|+)

New and Changed loom-features

This section refers to features set using Loom's set-features (and unset-features) functions.


The following new Loom features have been added:

If set, then Loom's keywords must have colon (:) prefixes. If not set (the default), then the colon is optional. By setting the feature, Loom keywords like "and" and "or" become available for use as concept or relation names.
Loom cannot reason with open numeric intervals, only closed ones. For integers this is not an issue since open integer intervals can be readily converted to closed intervals. This is not possible for rational or real number intervals. If this feature is set (the default), then Loom will create closed interval approximations to the corresponding open interval. This means more inferential power, but has the potential for getting into trouble through round-off errors in the computation of the bounds of the closed-interval approximation.

Normally Loom will complain if the create function is called more than once with a given instance name. If this feature is set, then multiple calls to create will be allowed without generating a warning and question. Loom will attempt to deal with a creation type (if specified in the create) call in an intelligent manner: If no creation type is present, it will be used. If one is already present, then the new type will be asserted and a warning message will be generated. If the instance in question was defined by Loom in the course of building the TBox (say by inclusion in a :filled-by or :one-of construct), then the type of the instance can also be changed via the :creation-policy keyword.

The function list-features now returns and prints features in alphabetical order.

CLOS Instances Support

If you want to roll your own instances, the following mixins have been defined that allow access to the new features added to Loom 3.0:

Instance-With-Time (added in 2.1)
Allows you to make temporal assertions about the instances. Including this mixin (directly or by inheritance) is the only way that you can use temporal concepts and assertions. Instance-With-Everything and lite instances include this mixin.

Instance-With-Negation (added in 2.1)
Allows you to make negated assertions about instances. This permits asserting that the instance does not have a particular role filler, or is not a member of a particular concept.

Makes slot values on the Lite instance sensitive to contexts. Without this mixin, all information specific to the CLOS instance will be globally visible and modifiable.

Has been extended to include the new features. In fact, Lite instances are just instances with everything. This can be added as a mixin to other CLOS classes to provide the same functionality as Loom's Lite instances along with other application-specific behavior that derives from the implementor's own classes.

Preview of Loom 3.1 Features

Disclaimer: This information is provided for information purposes only. It reflects our current plans for further development. It is NOT a promise to provide these features in the future -- in other words, we could change our plans. For Loom 3.1 we expect to expand on the notion of a property. This would either be a unary relation or a binary relation with a range of Boolean. For modeling purposes, we would then expect that concepts would be considered immutable or intrinsic attributes of instances. In other words, one would not expect the concepts to which an instance belongs to change much. Properties, on the other hand would be more transient. Under this guideline, "Person" would be a concept and "Employed" or "Married" would be properties. For Loom 3.1 we expect to extend the notion of roles and add features. For example, we plan to have them indicate any role fillers or minimum/maximum value restrictions. We will also make the use of qualification on roles more obvious. We would also expect to differentiate between direct roles and inherited roles.
Loom is a registered trademark of the University of Southern California.
Information Sciences Institute ISI Intelligent Systems Division Loom Home Page