Plugin Mechanism.
	In order to allow a certain degree of scalability and reusability a plugin mechanism has been implemented into AquaLog. The use of a plug-in mechanism allows AquaLog to be configured for different KR languages. With this mechanism AquaLog can now accept plugins to interact with ontologies or KR different from the one provided by default. Plugins are loaded at execution time. All plugins must implement a generic interface defined in the package RelationService.core.plugin.IEPlugin . An abstract class implementing the methods that AquaLog needs to interact with ontologies is provided: RelationService.core.plugin.IEOntologyPlugin . IEOntologyPlugin provides also two additional subtypes of plugin: RelationService.core.plugin.IEOntoServerPlugin to interact with ontologies stored in a server; and RelationService.core.plugin.IEOntoURLPlugin to work with ontologies stored in URL. Thanks to these classes the plugin developer will only have to extend them and override the main methods; a simple implementation for the basic methods has been already defined. Plugins are contained in jar files and placed in the Plugins directory in AquaLog (defined in the configuration file). A manifest file has to be provided in the jar file and it must contain an entry for the main class. At the start-up AquaLog loads each file from the Plugin directory and analyses it in order to find the main class in the package, The plugin is added to a specific list of plugins according to its type. These lists are then consulted when needed. To develop plugins for AquaLog, Java 1.4.1 or higher is required. Currently the plugin used by AquaLog is the AquaWebOntoPlugin over our OCML-based KR infrastructure. This plugin mechanism is similar to the one adopted by MnM .