G2 provides three ways to organize knowledge globally in a KB: by class, by workspace, and by module. Each of these organizing techniques is global, because you can reference each object in your KB only by its class, only by its location within the KB's workspace hierarchy, or only by its association with a module.
A standard way to use the class-orientation of your KB's objects is to use methods. By coding your KB's programmatic activities as methods, you can reuse the procedural knowledge that is associated with a more generic class as you define the procedure knowledge required for a more specific class. For more information about using G2's methods, see Chapter 22, Methods.
You can also use the inheritance paths defined in the KB's class hierarchy to configure the behavior of the KB's objects. Instance configurations affect the default behavior of the KB's objects, based on each object's class. For more information about instance configurations, see Chapter 7, Configurations.
Arranging Knowledge Among Workspaces
For your own convenience, you can organize your KB's objects into collections by placing each upon a workspace (that is, upon items of the KB-WORKSPACE class). A workspace both contains a set of objects (some of which can have their own subworkspaces) and establishes their arrangement as a set when the workspace is displayed. For more information, see Chapter 4, Workspaces.
Although you can organize your KB's objects in any manner you prefer, you should develop guidelines for how you arrange your KB's objects among a set of workspaces.
After you create a module in the current KB, you can save as a unit the module object, its system tables, its associated workspaces, and all items below those workspaces in the KB's workspace hierarchy, into a distinct KB file.
You can design your modules to have well-defined dependencies upon each other, or to have no dependencies upon each other at all (other than directly-required module dependencies). For more information, see Chapter 5, Modules and Modularized KBs.