****** LOOM 3.0 RELEASE NOTES **** Three major changes have been made. The first major change in Loom(R) 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. Details can be found at the URL . 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. Installation instructions for all systems can be found in the file loom3.0-install.text CONTENTS: o INCOMPATIBLE CHANGES FROM LOOM 3.0b1 (the previous beta release) o UPPER-STRUCTURE-KB RENAMED o TELL AND TELLM ARE NOW THE SAME o CONTEXT MECHANISM o HTML SUPPORT o NEW MODEL FOR REIFIED RELATIONS o CHANGES TO THE TBOX o NEW AND CHANGED LOOM-FEATURES o CLOS INSTANCES SUPPORT o PREVIEW OF LOOM 3.1 FEATURES ------------------------------------------------------------------------ === 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. Also, the :within-context form for queries does not currently affect the name lookup for concepts, relations or instances. 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. The difference is that :WITHIN-THEORY affects name lookup in the `queryExpression' inside its scope and :WITHIN-WORLD does not. That means that :WITHIN-WORLD is faster. Examples: (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". ------------------------------------------------------------------------ === 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. ** INCOMPATIBLE CHANGE ** 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) (initialize-network) Note that doing this will clear out all existing information in all contexts loaded into Loom. ** INCOMPATIBLE CHANGE ** 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. == DEFPROPERTY 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]. == NEW CONCEPTS AND RELATIONS 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: min-cardinality max-cardinality cardinality (Only has a value of min = max) types ** 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 Loom feature :EXPAND-SYSTEM-DEFINED-PRINT-NAMES has been changed to :LONG-PRINT-NAMES The following new Loom features have been added: :DONT-DWIMMIFY-KEYWORDS -- 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. :APPROXIMATE-OPEN-INTERVALS -- 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. :ALLOW-MULTIPLE-CREATES -- 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. == Context-Sensitive-Instance 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. == Instance-With-Everything 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. ------------------------------------------------------------------------ END OF RELEASE NOTES