{Begin SubSec Review of Knowledge Base Concepts}
{Title Review of Knowledge Base Concepts}
{Text


{note currently, this sub section is duplicated in the overview.  This really should go into a separate file, accessed from both sections....}


{index knowledge bases}

{it Knowledge Bases:}  Knowledge bases in LOOPS are files that are built up as a sequence of layers, where each layer contains changes to the information in previous layers.  A user can choose to get the most recent version of a knowledge base (that is, all of the layers) or any subset of layers.  The second option offers the flexibility of being able to share a community knowledge base without necessarily incorporating the most recent changes.  It also provides the capability of referring to or restoring any earlier version.  {FigureRef 123KnowledgeBase2} illustrates this with an example.


{Begin Figure}
{Tag 123KnowledgeBase2}
{Text
{lispcode
------------------------- Layer 1 -------------------------
Obj1 (x 4) ...
Obj2 (y 5) (w 3) ...
------------------------- Layer 2 -------------------------
Obj2 (y 7) (w 2) ...
Obj3 (z 6) ...
------------------------- Layer 3 -------------------------
Obj1 (x 8) ...
Obj4 (z 9) ...}
}
{Caption
Knowledge bases in LOOPS are files that are built-up incrementally as a sequence of layers.  Each layer contains updated descriptions of objects.  When a knowledge base is opened, the information in the later layers overrides the information in the earlier layers.  LOOPS makes it possible to select which layers will be used when a knowledge base is opened.  In this example, if the knowledge base is opened and only the first 2 layers are used, then {lisp Obj1} will have an {lisp x} variable with value {lisp 4}.  If all three layers were connected, then the value would be {lisp 8}.
}
{End Figure}


{it Community Knowledge Bases:}  LOOPS partitions the process of updating a community knowledge base into two steps.  Any user of a community knowledge base can make tentative changes to a community knowledge base in his own (isolated) environment.  These changes can be saved in a layer of his personal knowledge base, and are marked as associated with the community knowledge base.  In a separate step, a data base manager can later copy such layers into a community knowledge base.  This separation of tasks is intended to encourage experimentation with proposed changes.  It separates the responsibility for exploring possibilities from the responsibility of maintaining consistent and standardized knowledge bases for shared use by a community.  The same mechanisms can be used by two individuals using personal knowledge bases to work on the same design.  They can conveniently exchange and compare layers that update portions of a design.        

{it Unique Identifiers:}  The ability to determine when different layers are referring to the same entity is critical to the ability to share data bases.  To support this feature the LOOPS data base assigns unique identifiers (based on the computer's identification numbers, the date, and an unbounded count) to objects before they are written to a knowledge base.  This facility provides a grounding for more sophisticated notions of equality that might be desired in knowledge representation languages built on LOOPS.	 

{it Environments:}{index environments}  A user of LOOPS works in a personalized {it environment}.  An environment provides a lookup table that associates unique identifiers with objects in the connected knowledge bases.  In an environment, user indicate dominance relationships between selected knowledge bases.  When an object is referenced through its unique identifier, the dominance relationships determine the order in which knowledge bases are examined to resolve the reference.  By making personal knowledge bases dominate over community knowledge bases, a user can override portions of community knowledge bases with his own knowledge bases.  

{it Multiple Alternatives:}{index multiple alternatives}  An important use of environments is for providing speedy access to alternative versions (e.g., multiple alternatives in a design).  A user can have any number of environments available at the same time.  Each environment is fully isolated from the others.  Operations that move information between environments are always done explicitly through knowledge bases.


}{End SubSec Review of Knowledge Base Concepts}



{Begin SubSec Environmental Objects and Boot Layers}
{Title Environmental Objects and Boot Layers}
{Text


Knowledge bases, environments, and layers are represented in Loops by special objects called {it environmental objects}.{index environmental objects}  All knowledge base and environment operations are performed by sending messages to these objects.  Environmental objects are accessible from any environment in Loops.  

In this section, we will need to distinguish between environmental objects and the things that they represent.  {FigureRef SummaryOfEnvTerms} summarizes some of the terminology that we will use.


{Begin Figure}
{Tag SummaryOfEnvTerms}
{Text
{Begin Table}

{COLUMN} {COLUMN} {COLUMN 50percent}

{First {it Loops Object}}
	{Next {it Represents}}
		{Next {it Description}}
{First Layer}
	{Next file layer}
		{Next Portion of a file which contains descriptions of objects.}
{First KB}
	{Next knowledge base}
		{Next A file and sequence of file layers.  A knowledge is known by the name field of its file name.}
{First KBState}
	{Next State of a knowledge base}
		{Next A sequence of file layers.  Used to access a fixed explicit set of file layers (e.g., a version of a knowledge base that is older than the most recent version).}
{First Environment}
	{Next environment}
		{Next An environment associates names and unique identifiers with objects in working memory.}
{End Table}
}
{Caption
Summary of terminology for environmental Loops objects and the entities that they represent.
}
{End Figure}


{it Environments:}{index environments}  An Environment provides a name space in working memory.  Each Environment associates names and unique identifiers with objects.  In general, Environments are designed to be independent.  For convenience, Environments are usually named.  An Environment is always associated with a particular knowledge base.   The specifications for creating an Environment come from some knowledge base, and changes to the Environment are stored on that knowledge base.


{it Layers:}{index layers}  A file layer is a portion of a file which contains descriptions of objects.  An object description consists of a unique identifier and an expression that can be read by Interlisp to create the Loops object.  A different unique identifier is associated with each expression.  In addition, a file layer contains a mapping from names (Interlisp atoms) to unique identifiers.  A file layer is represented in Loops by a Layer object.  A Layer indicates the file on which it is written, the starting address of the file layer, and the name of the knowledge base with which it is conceptually associated.  A Layer also contains various bookkeeping information such as the name of its creator and the date of its creation.


{it KBs and KBStates:}{index KBs}{index KBStates}  A knowledge base is a set of file layers.  Typically, most of the layers of a knowledge base are located on a single file.  A knowledge base is known by its file name.  By convention, such files have the extension "{lisp KB}".  A KB is a Loops object that represents a knowledge base.  A KB has a name equal to the name field of the file name of the knowledge base that it represents.  For example, the KB with name {lisp Test} would be associated with a version of the file {lisp Test.KB}.

A KBState is a generalization of a KB.  It refers to an explicit set of file layers.  KBs and KBStates indicate their Layers using a list on an instance variable named {lisp contents}.{index contents (IV of KB))}{index contents (IV of KBState))}  An element of this list must be either a Layer or a KBState.  When a KBState appears in the list, it is as if the Layers listed in the KBState's contents variable appeared explicitly in the list.  This provides a mechanism for indirect fetching of layers from other knowledge bases.  

To indicate all of the layers of the most recent version of a knowledge base, the contents of the KBState can be the special value "{lisp CURRENT}".  When such a KBState appears in the list, it is as if the Layers of the most recent version of the knowledge base were inserted in the list.  These Layers are retrieved by retrieving the KB from the referenced knowledge base.


{it Boot Layers:}{index boot layers}  Environmental objects are distinguished from other objects when they are accessed and when they are written out to a knowledge base.  They are accessed differently in that they are kept in a global name table accessible in all environments.  This means that an Environment can be described in terms of the environmental objects before the Environment is made current.  

Environmental objects are also special in that the file layer that describes them is a special file layer at the end of a knowledge base called the boot layer.  In order to access the contents of a knowledge base, it is necessary to read the boot layer first because it contains the environmental objects that describe the knowledge base.  A boot layer for a knowledge base contains a single KB describing itself, a Layer describing each of its file layers, and the KBStates mentioned (directly or indirectly) in the KB.


{it The Global Name Table:}{index global name table}  Loops keeps environmental objects in a global name table that is accessible from any environment.  This name table also includes the basic classes that are part of the Loops kernel.  If Loops is used without exercising the Environments feature, then all created objects are also placed in the global table.

When another environment is opened, objects not in core are first looked for by UID or name in the open environment.  If no object is found there, then the UID or name is looked up in the Global Environment.  Thus, object descriptions in a new environments override those in Global Envrionment, but old objects which have no counterparts are still available.


}{End SubSec Environmental Objects and Boot Layers}



{Begin SubSec Starting With No Preexisting Knowledge Bases}
{Title Starting With No Preexisting Knowledge Bases}
{Text

The knowledge base facility in Loops has been designed to cover a number of situations.  Because of this generality, it is not always easy for a newcomer to discover the simplest way of using the features.  The following sections describe all the features of the Knowledge Base system;  however each feature is introduced within a particular scenario that shows how to do some of the most common operations for which Loops was designed. 

In the first scenario, a user wants to start from scratch using no preexisting knowledge bases.  The results of this Loops session are saved in a personal knowledge base.	  

When a user invokes Loops, the Loops name space will contain some objects from the Loops kernel.  Before creating any new objects, the user should type an expression of the form:

{lispcode
(← $KB New '{arg KBName} '{arg environmentName} {arg newVersionFlg})}
{index New (Method of KBMeta)}

where {arg KBName} is an atom (e.g., use {lisp FOO} to create a knowledge base named {lisp FOO.KB}) and {arg environmentName} will be the name of the Environment.  This will create both a new KB corresponding to the {arg KBName} and a new Environment with the name {arg environmentName}.  

Loops checks that a knowledge base with {arg KBName} does not already exist.  If it does exist and {arg newVersionFlg} is {lisp NIL}, Loops will report an error.  If {arg newVersionFlg} is {lisp T}, then Loops will create a new version of the file.  Because of the way the file system works, the name of a KB must be all in upper case.  If the user attempts to use a {arg KBName} which contains lowercase letters, Loops will correct the name to all upper case and print a warning message.	

Warning:  Objects created before creating and opening an Environment are placed in the global name table.  Hence, any objects so created will be shared by all Environments.  However, Loops will not save such objects in a knowledge base later in the session unless they are explicitly moved to some environment.  Alternatively, such objects can be saved using the Interlisp file package.

The next step is to open the Environment:

{lispcode (← ${arg environmentName} Open)}
{index Open (Method of Environment)}

This makes the new Environment be the current environment. New objects that are created will be associated with the KB.  

Having created an Environment, the user can then proceed to create whatever new objects he desires in the session.  To dump the current state of the environment and continue afterwards, the user can type:

{lispcode (← ${arg environmentName} Cleanup)}
{index Cleanup (Method of Environment)}

This does not close any files, and leaves the environment as it was, except that all changed objects have been dumped to the knowledge base, and then marked as unchanged.  {lisp Cleanup} can be done any number of times in a session.  

At the end of a session the user should do a {lisp Close}:

{lispcode (← ${arg environmentName} Close)}
{index Close (Method of Environment)}


This writes out all of the objects to a file layer, updates the environmental objects accordingly, and writes them out to a boot layer, deletes these objects from memory, and closes all files associated with the environement.  The user can then exit from Interlisp.  After a {lisp Close} is done, the user must go through the following scenario to start up again. 

}{End SubSec Starting With No Preexisting Knowledge Bases}



{Begin SubSec Continuing from a Previous Session}
{Title Continuing from a Previous Session}
{Text

The case where a user wants to create a new knowledge base is less common than the case where he wants to modify or add objects to a knowledge base that he has previously created.  In this scenario a user wants to resume from where he was at the end of his previous session.	

The first step is to obtain the user's knowledge base, and link it to an environment.  This is done by a message to the class {lisp KB} as follows:

{lispcode (← $KB Old '{arg KBName} '{arg environmentName})}
{index Old (Method of KBMeta)}

This reads the boot layer of the knowledge base named {arg KBName} and creates an Environment named {arg environmentName} that is then connected to the KB.  At this point the user must open the environment to make the contents of the KB available in this environment:

{lispcode (← ${arg environmentName} Open)}
{index Open (Method of Environment)}

This causes Loops to read in each Layer contained (possibly implicitly) in the contents of the associated KB (named {arg KBName}).  It also makes the new Environment be the current environment.  Having opened an Environment, the user can then proceed to define whatever new objects he desires in the session.  New objects that are created will be associated with the KB.  When he is done, he should type as in the previous scenario:	

{lispcode (← ${arg environmentName} Cleanup)}
{index Cleanup (Method of Environment)}

or 

{lispcode (← ${arg environmentName} Close)}
{index Close (Method of Environment)}


}{End SubSec Continuing from a Previous Session}




{Begin SubSec Starting from a Community Knowledge Base}
{Title Starting from a Community Knowledge Base}
{Text

Users will not usually start from scratch.  Rather, they will often begin by using previously created community knowledge bases.  This scenario starts with obtaining a single community knowledge base.  The user does not own the community knowledge base, so the results of the session will have to be saved in a personal knowledge base.  The personal knowledge base will contain any new objects that created as well as any objects from the community knowledge base that have changed.	

As in the first or second scenario, the first step is to create a personal knowledge base. 

{lispcode (← $KB New '{arg KBName} '{arg environmentName} {arg newVersionFlg})}
{index New (Method of KBMeta)}

or if the user has a personal knowledge base already, by doing a:

{lispcode (← $KB Old '{arg KBName} '{arg environmentName})}
{index Old (Method of KBMeta)}

This obtains both the KB and an Environment.  The next step is to add the community knowledge base to the KB as follows:

{lispcode (← ${arg KBName} AddToContents '{arg communityKBName})}
{index AddToContents (Method of KB)}

where {arg communityKBName} is an atom that is the name of the community knowledge base.  

This step should be repeated for each knowledge base to be added to the KB named {arg KBName}.  The message creates a KBState describing the "current" state of the community knowledge base and adds that KBState to the contents of the KB for the personal knowledge base.  The effect of this action is that Loops will remember to associate the community knowledge base with the user's knowledge base in the future.  (This step need not be repeated in any future session which uses the knowledge base {arg KBName}.)   

At this point, the user can open the Environment as before:

{lispcode (← ${arg environmentName} Open)}
{index Open (Method of Environment)}

This causes Loops to read in each Layer contained (possibly implicitly) in the contents of the KB named {arg KBName}.  The {lisp Open} message also makes the Environment named {arg environmentName} be the current environment.  

Since the KB associated with the environment contains a KBState for {arg communityKBName}, those Layers will also be read.  They are found by reading the boot layer of the community knowledge base.  The message {lisp AddToContents} on {arg KBName} will work properly even after the environment is {lisp Open}, in the sense that when it is done on a KB connected to an {lisp Open} environment, it causes all the layers of the newly added KB to be read in.  

All creation and modification operations will take place in this Current Environment.  The user can create new objects and modify objects in the community knowledge base.  When done, the results of the session can be saved using {lisp Cleanup} (or {lisp Close}).  This will cause two file layers to be written out to the personal knowledge base (and none to the community knowledge base).  First a file layer is written out to {arg KBName} for changes made to the community knowledge base (if any).  The Layer for this file layer is marked as associated with the community knowledge base.  Second, a file layer is written out for the other objects that have been created.  The Layer for this is marked as associated with {arg KBName}.  Finally, the environmental objects for the knowledge base are written out to a boot layer.

Before the boot layer is written out, the KB for the personal knowledge base named {arg KBName} is updated to contain the new Layers.  It contains the reference to the community knowledge base that was created by the {lisp AddToContents} message.  This continues to be interpreted as a reference to the most recent version of the community knowledge base named {arg communityKBName}.

If {lisp Close} was used, then the files storing the knowledge bases have been closed and all objects in the environment have been destroyed.  The environment was also made not current.  This clean state is recommended as a place from which the user can then exit from Interlisp.


}{End SubSec Starting from a Community Knowledge Base}




{Begin SubSec Freezing and Thawing References to Knowledge Bases}
{Title Freezing and Thawing References to Knowledge Bases}
{Text

In the previous scenarios, the user used the most recent version of the community knowledge base.  Community knowledge bases can be changed over time by their owners (i.e., their human knowledge base managers).  Sometimes a knowledge base manager may update the community knowledge base, but a user may want to continue using a fixed older version.  For example, if the new version of a community knowledge base contains extensive changes, the user may want to finish some project before converting his personal knowledge bases to reflect the changes.  To do this the user must freeze references to the community knowledge base.  Freezing enables a user to continue to access a fixed set of layers even though the community knowledge base may be changed by the knowledge base manager.  In this scenario, the user has a personal knowledge base whose contents include a named community knowledge base.  She anticipates the change to the community knowledge base before it happens and freezes reference to it.  

Later, we will see how a user can return to an earlier version after a change has been made.	

{it Freezing:}  The first step is to obtain access to the user's personal knowledge base.  As in the previous example, this is done by sending an {lisp Old} message to the class {lisp KB}:

{lispcode (← $KB Old '{arg KBName} '{arg environmentName})}
{index Old (Method of KBMeta)}

This creates an Environment named {arg environmentName} with that KB as its outputKB.  To freeze the reference, the user needs to change the KBState in his personal KB that describes the community knowledge base.  This can be done as follows:

{lispcode (← ${arg KBName} FreezeKB '{arg communityKBName})}
{index FreezeKB (Method of KB)}

The user can then open his Environment, do his work, and then write updates as before:

{lispcode
(← ${arg environmentName} Open)
    {it ... <make changes to objects> ...}
(← ${arg environmentName} Close)}


From his point of view, the objects in the community knowledge base will be static even if the knowledge base is changed several times.  After the user ends this session and starts again the next day, his knowledge base will continue to refer to fixed versions of the objects in the community knowledge base, even if new versions are added later.

{it Thawing:}  Eventually, however, the changes (and improvements) to the community knowledge base may provide a compelling reason for the user to switch to the most recent version.  To do this, he should type the following messages at the beginning of a session:

{lispcode
(← $KB Old '{arg KBName} '{arg environmentName})
(← ${arg KBName} ThawKB '{arg communityKBName})}
{index Old (Method of KBMeta)}
{index ThawKB (Method of KB)}

The user can then open his Environment, do his work, and then write updates as before.

}{End SubSec Freezing and Thawing References to Knowledge Bases}