Even though Ontological Engineering is a very young area in Artificial Intelligence, there exist some methodological proposals for building ontologies: Uschold and King's methodology [Usc95], Grüninger and Fox's methodology [Grü95], METHONTOLOGY [FeG99], etc. A study and analysis of methodologies for building ontologies can be found at [Fer99]. This study shows that METHONTOLOGY is currently the most mature methodology.
Presently, methodologies do not propose to adapt the mechanism of modelling to the different ontologies to be built. However, our experience in different projects (the ( KA) 2 initiative [Ben98], the multidisciplinary project AM9819 about environmental pollutants, etc.) show that different domains should be modelled in different ways. Table 1 shows the components that have been used in different ontologies. We can see that there are variations from some ontologies to others. Some ontologies have been built using a lot of attributes and no relations, others have been built using constants, some of them have first order logic formulas, but others do not, etc.
Apparently, one solution to this problem would be to consider all the "necessary" components (concepts, attributes, first order logic formulas, constants, etc.) when an ontology had to be built. Nevertheless, such solution has the following drawbacks: (1) Our experience has shown it is possible that need for a component is not perceived a priori, that is, it is possible the necessity of a component is only detected when it is needed in an ontology. (2) New research about modelling can provide new components and new ideas about how to use old components. (3) Considering non-useful components when an ontology is built can cause confusion in modellers, and especially when they are not very experienced.
Besides flexibility in the components to be used during the modelling, the knowledge should be presented in diffe rent ways to different experts.
Summarising, a rigid way to model brings us back to the classic knowledge-acquisition bottleneck [Eri99]. Focussing on the case of METHONTOLOGY, it proposes to carry out the following steps to develop an ontology: specification in natural language, conceptualisation using tables and graphs, formalisation (e.g. using frames), and implementation (e.g. using the Ontolingua language [Far97]). According to the METHONTOLOGY viewpoint, conceptualisation is the modelling at the knowledge level [New82], hence, the knowledge is modelled independently of the implementation language to be used 1 . The proposed tables and graphs allow modelling 1 Such idea of conceptualisation is inspired in the Hayes-Roth and colleagues' approach [Hay83]. concepts, attributes, first order logic formulas, etc., and they are thought to be manipulated by experts in the domains to be modelled. Figure 1 presents an example of a graph: a concept classification tree, and table 2 is an example of concept dictionary. Tables and graphs in METHONTOLOGY are not fixed, since the engineer can use tables or graphs that can be different to the proposed ones by the methodology. However, METHONTOLOGY does not propose a precise way to specify how the tables and the graphs to be used during the conceptualisation are. 2).
In the following sections, a solution to these problems will be presented. Section 2.1 will present the bi-phase method and, section 2.2, its software support: ODE. The paper will finish with the conclusions and future trends.
To allow a more flexible modelling of ontologies and to ease the exchange of characteristics of tables and graphs, the bi-phase method proposes to model how to model the ontology. Until now, the purpose of the ontology engineer was to model some parts of the world, for example, flights, chemical elements, etc. (see figure 3), however, with the bi-phase method, modelling the process of modelling is also recommended, that is, building a meta-model is also proposed.
Particularly, the part of the modelling process to model is the conceptualisation, which is the base of the remainder steps of the modelling.
The bi-phase method follows the METHONTOLOGY approach, although in two levels. On the one hand, during phase I, the ontology conceptualisation process is specified in natural language, conceptualised using tables and graphs (called in this phase meta-tables and meta-graphs), formalised using a formal language, and implemented in SQL (see figure 4). Thus, the result of this first phase is a meta-model presented in meta-tables and meta-graphs, in a formal language, and in SQL. The steps of this phase are called: meta-specification, meta-conceptualisation, meta-formalisation and meta-implementation. On the other hand, phase II carries out the specification, conceptualisation (following the meta-model obtained in phase I), formalisation and implementation of the ontology. As you can see, in this bi-phase method, there is a modelling both at Newell's knowledge level and symbolic level during phase I as well as phase II.
To facilitate the building of meta-models, a reference meta-model is proposed. It is possible to modify this reference meta-model according to the modelling needs of each ontology. Such metamodel is expressed by means of meta-tables and meta-graphs, and it is also formally expressed. The reference meta-model allows building ontologies with: concepts, class and instance attributes, facets of such attributes, relations, first order logic formulas, arithmetic formulas, constants, and instances. These components appear in the reference meta-model because each one of them have been used in some of the ontologies developed during the experimentation. Besides, we have checked that the reference metamodel contains the static components of the classic languages for ontology development (Ontolingua, OKBC, OCML, FLogic and LOOM). We say static components because we do not consider rules and procedures. This reminds as future work.
We have also developed a tool, called ODE, in order to provide software support to the bi-phase method. Ode is especially designed to facilitate the application of the method. However, it is not the only tool allowing flexible modelling, since Protégé-2000 [Fri00] permits the user to redefine its components (made by classes, slots, etc.).
In [Fer01] a complete description of the method is presented. Such description includes the tasks to 4. Bi-phase method to build ontologies be performed, the inputs, the outputs and the participants. This description includes a way to manage the changes in meta-models, even when an ontology is being developed with such metamodel and new necessities are detected. There is also a description of the architecture of ODE. The method and the tool have been tested in the above mentioned projects (the ( KA)2 initiative, the multidisciplinary project AM9819 about environmental pollutants, etc.). 10 different metamodels have been built with a total of 33 additions, removals and modifications with regards the reference meta-model; such metamodels have been used in 11 different domains: chemical elements (169 terms with 27 first order formulas), knowledge acquisition community (239 terms with no first order formulas), hardware (190 terms with no first order formulas), ontologies (110 terms with no first order formulas), measure units (93 terms with no first order formulas), monatomic ions (82 terms with 6 first order formulas), silicates (109 terms with no first order formulas), catalogues of cloths (48 terms with no first order formulas), travels (22 terms with no first order formulas), hotels (69 terms with 2 first order formulas) and contracts (37 terms with 1 first order formula). Other meta-models have been built containing meta-graphs and meta-tables to model databases, other meta-models contain metagraphs to model tasks, and other meta-models even contain schemas of bills, invoices, etc. as meta-tables.
In the following sub-sections, a brief description of the steps of phase I will be presented.
During phase I, the meta-specification describes, in natural language: (a) what tables and graphs will be used during the conceptualisation of the ontology; (b) the recommended order to fill in the tables and to build the graphs; and (c) the consistency verification rules between tables, between graphs, and between tables and graphs. For example, it can be ( meta-)specified that a graph to be used during the conceptualisation is the concept classification tree, that the nodes of this graph are concepts, and that the edges are subclass of, subclass in a disjoint partition 2 , and subclass in an exhaustive partition3 . Besides, it can be also specified that a table to use during the conceptualisation of the ontology is the concept dictionary. The possible fields of such table would be: concept name, instances, instance attributes, etc. Concerning the recommended order, it should be said that the elaboration of the concept classification tree should begin before starting the concept dictionary. And with regard to the consistency verification rules between the concept classification tree and the concept dictionary, all the concepts of the tree should be in the concept dictionary and vice versa.
For ( meta-)conceptualising in phase I, the biphase method proposes: (a) a set of meta-tables to describe the tables and graphs to be used during the conceptualisation in phase II; (b) a meta-graph to describe the order in the conceptualisation in phase II; (c) and meta-tables and meta-graphs to describe the consistency verification rules. Thus, for example, the meta-tables of node description, and the meta-tables of edge description are proposed to define the details of the graphs, and the meta-tables of field description are proposed to define the details of the tables. For instance, meta-tables 1, 2 and 3 show the description of the taxonomy and of the concept dictionary, used both in the examples of section 1.1.1. In all these meta-tables, the meta-field symbol is filled in with abbreviations. In the case of meta-table 2, which describes a graph, the meta-fields input and output edges, input multiplicities and output multiplicities are used to establish how many edges can go in and go out to and from a node. In the case of meta-table 3, which describes the concept dictionary, the metafield format restricts the possibilities to fill in the cells (text, list, logic expression, etc). Is it main is true when the described field is the identifier of the row. Repetition in the same table is true when the field can be filled in with the same value in different rows. And multiplicity is true when the same cell can have several values.
The meta-graph to model the order during the conceptualisation is not presented due to the space constraints.
Concerning the consistency verification rules between tables, between graphs, and between tables and graphs, the way to write them is based on operations on matrices representing the tables and the graphs. Such operations are similar to the ones used in the relational model for databases (projection, selection, difference, etc.).
To carry out the meta-formalisation, a formal and declarative language, called LBIR (Language for Building Intermediate Representations), has been elaborated. Such language has the same expressiveness as the meta-tables and meta-graphs used during the meta-conceptualisation. The LBIR description uses a context free grammar for the syntax, and matrices to establish the meaning of the language. The following code:
shows the definition in LBIR of the concept dictionary, that is equivalent to the definition appearing in meta-table 3
In order to allow the efficient use of the methodology proposed in 3.1, we has built ODE (see figure 5).
Although each ontology has its modelling needs, there is not any methodological proposal to use a different kind of modelling for each ontology.
The bi-phase method presented in this paper proposes, during a first phase, to model the modelling process itself (or reusing an existing meta-model) and, during the second phase, to model the ontology. In the first phase, the steps are: meta-specification, meta-conceptualisation, meta-formalisation and meta-implementation.
During the second phase the steps are the ones proposed by METHONTOLOGY: specification, conceptualisation, formalisation and implementation. To carry out the metaformalisation, a formal and declarative language (LBIR) has been elaborated. Moreover, to provide software support to both phases, a tool has been developed: ODE.
To agree in the meta-model to be used, the different groups can exchange this meta-model in meta-tables and meta-graphs, or in LBIR (see figure 6). The second option, LBIR, is mandatory if the current version of ODE is utilised to build the ontologies.
The method and the tool have proved useful in several Spanish and international projects.
One of the most interesting future lines, above all for ODE, would be the fast development of translators from different meta-models into different implementation languages. An interface to manipulate meta-tables and meta-grpahs would be also interesting. Another important future trend would be a structured characterisation of ontologies according to their modelling needs. Now, the modelling necessities are determined by the experience of the ontology engineers, who interacts with the experts in the domain to be modelled.