The module concept provides the facility to divide a ConceptBase application into an arbitrary number of autonomous clusters. We use the term module for such a cluster. A module is autonomous in the sense that the visibility of objects and validity of deductive rules and integrity constraints is limited to the scope of a certain module. This implies that for each server operation (TELL, UNTELL, ASK) the user has to define a module in whose context he wants the operation to be executed.
One useful application of modules in ConceptBase are modelling situations where different objects are labeled with identical names. In earlier versions of ConceptBase this was prohibited by the Naming Axiom which demands that different objects have different names. Now objects with identical names can be stored in different modules without interferences. As another application users can manage alternative conceptual models of the same domain in different modules.
The set of visible objects in a module-context is not limited to the set of objects defined for the module. The ConceptBase module concept permits to reuse existing objects from different modules via import and export interfaces. Furthermore, modules can be nested: a nested module is only visible within the context of its "father" module. Objects that are visible in a "father" module are visible (and can be reused) to all its "child" modules.
ConceptBase users can be assigned to so-called home modules, i.e. the module they start working with when registering with the ConceptBase server. So-called auto home modules force every user in her own module to further reduce potential unwanted interferences. A flexible access control mechanism allows to define access rights of users simply by query classes defined either globally or locally to a module.