Ecolingua's Life Cycle

With the intention of specifying an ontology for the description of ecological data, Brilhante and Robertson chose not to build the ontology from scratch, but to do it the `proper way', that is, by re-using publicly available ontologies of related fields and incorporating their specifications into Ecolingua. For this reason they turned to the library of sharable ontologies provided by the Ontolingua Server [3]. Hence, Ecolingua was first constructed with the server's editor by re-using classes from other ontologies in the server's library, and then automatically translated into Prolog syntax, Brilhante and Robertson's preferred language, by using the server's translation service.

To their dismay the outcome of the translation was an overly large 5.3 Mb file. The definitions of proper Ecolingua classes use external classes defined in five other ontologies, and because the translation service of the server blindly joins the specification of all ontologies together, including those of very general ontologies likeSimple-Time and Physical-Quantities, before performing the actual translation into Prolog syntax. There was no way that the ontology as produced by the Ontolingua Server was going to be useful, unless it was significantly reduced in order to get a smaller and more manageable set of axioms. This reduction process could not be done manually, since the logical integrity of the ontology may have been affected. This forced Brilhante and Robertson to implement filters that first deleted all extraneous clauses (over-general facts, definitions of self-subclasses, duplicated classes), and then pruned the class hierarchy and removed irrelevant clauses accordingly. Finally, since the translation service did not provide executable Prolog code (it only yielded the ontological axioms originally specified in KIF [4] as Prolog terms) a final translation into Horn clauses was necessary, in order to be able to use the ontology with a standard Prolog interpreter. Figure 1 shows this fragment of Ecolingua's life cycle. The whole reduction process is explained in detail in [2].

Figure 1:Ecolingua's life cycle

We postulate that particular sequences of transformation steps like those illustrated in Figure 1 may be common in particular domains, and perhaps to particular forms of knowledge components. In fact, the same problem encountered by Brilhante and Robertson with Ecolingua, and the same need for automatic ontology reduction will be faced by any knowledge engineer who attempts to specify a particular ontology in the Ontolingua Server, by reusing classes from sharable ontologies, and who asks for a translation into Prolog syntax. The ability to generalise and compile these sequences of transformations into formally represented specifications of life-cycle patterns would encourage more efficient behaviour when faced with the need to make similar modifications in the future, as we shall see next.