Only KB workspaces and the items they contain can participate in a workspace hierarchy.
Items of many system-defined classes can have a subworkspace. Items of any subclass of
OBJECT can also have a subworkspace. An item can have only one subworkspace.
To create a new subworkspace for an item interactively:
Choose the create subworkspace choice from the item's menu.
After the subworkspace of an item exists, the
create subworkspace choice no longer appears on the item's menu.
To go to the subworkspace of an item:
Choose go to subworkspace on an item with a subworkspace.
To create a new subworkspace for an item programmatically:
Execute a create action, followed by a make ... the subworkspace of action:
create an item-list L1 and
create a kb-workspace W and
make W the subworkspace of L1
show action. For instance, this action button creates a new item-list and creates its subworkspace:
![]() |
Displaying the Workspace Hierarchy
Each top-level workspace in your KB has a distinct workspace hierarchy. You can use the Inspect facility to view the current workspace hierarchies.
To display the workspace hierarchy:
Use the Inspect facility to enter this command:
show on a workspace the workspace hierarchy
![]() |
show on a workspace the workspace hierarchy of help-workspace
go to subworkspace choice.
the subworkspace of item exists, which returns a truth value.
the subworkspace of to refer to the subworkspace of an item.
the superior item of to refer to the superior item of a subworkspace.
Item-configuration attributes of a workspace to customize the behavior of items for particular categories of users. Item configurations declared in one workspace can also pertain to all items below that item in the workspace hierarchy. Thus, the workspace hierarchy can serve as a framework for controlling the behavior of whole regions of KB knowledge. For more information about using item configurations, see Chapter 7, Configurations.
Organizing Knowledge in Subworkspaces by Using Connection Posts
You can make the relationship between an item and its subworkspace explicit by using connections and connection posts. To do this, create an object class definition that declares the following instance configuration:
declare properties as follows: subworkspace-connection-posts
This figure shows an instance of a user-defined class named
COMPONENT-SUBASSEMBLY. This definition declares two stubs for each instance.
![]() |
The definition also declares this instance configuration:
declare properties as follows: subworkspace-connection-posts
In this example, each connection drawn between a stub on the instance and any connection post is automatically associated with one of the connection posts on the subworkspace of the instance. G2 associates each connection in the
Superior-connection attribute of the appropriate subworkspace connection post. If the object class definition does not declare stubs, and you interactively create a connection by dragging a stub from a connection post into the instance, G2 automatically creates connection post items on the subworkspace of the instance when you create the subworkspace. G2 locates the connection posts on the subworkspace relative to the location of the connections on the instance. The following figure illustrates this situation:
![]() |
The figure shows a new version of the
COMPONENT-SUBASSEMBLY definition that does not declare stubs. After you make a connection between the custom connection post and the instance, and then create a subworkspace for the instance, G2 automatically creates and places a connection post on the subworkspace, and places it relative to the position of the connection on the instance. Associating Top-Level Workspaces with Modules
By assigning a top-level workspace to a module, you can associate a set of items with a module. Dividing a large KB into modules is the recommended way to organize the knowledge in your KB and to facilitate knowledge reuse.