One of the sources of heterogeneity of ontologies is that different ontologies have different necessities of modelling. This paper presents a biphase method to deal with these different necessities. Phase I of the method models how to model the ontology, obtaining a meta-model. Such meta-model can be expressed in LBIR, a formal and declarative language that has been specifically designed for this task. To save resources, a reference meta-model that can be modified and reused is provided. During phase II of the method, the ontology is modelled following the metamodel obtained in the first phase. Furthermore, a tool (called ODE) provides software support to the method. Such tool generates SQL schemas from LBIR, and allows the modelling of the ontology following the selected meta-model. This approach eases the interoperability between groups located in different geographical locations that have to build the same ontology, since the meta-model to be used can be exchanged through LBIR.
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.
13 37 4 4 2 6 15 8 0 1
Table 1 . Components used in the ontologies developed with the bi-phase method
Constants 20 103 103 102 239 110 93 82 109 190 48 22 47 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 used1. 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. Besides, this methodology does not propose how to add a new type of table, how to add a new field to a type of table, how to delete one of the types of the proposed graphs, or how to elaborate a completely new modelling way with completely new graphs and tables. Therefore, if several groups in different locations have to build an ontology collaboratively, there are problems to agree and exchange the characteristics of the tables and graphs to be used (see figure 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.
2.1. THE METHODOLOGICAL LEVEL OF THE BI-PHASE SOLUTION 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, metaconceptualisation, 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 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 partition2, and subclass 2 ‘Subclass in a disjoint partition’. A disjoint partition of a class is a set of subclasses of this class that do not have common instances. 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. 3 ‘Subclass in an exhaustive partition’. An exhaustive partition of a class is a set of subclasses that covers all the class, that is, there is not an instance of the father class that is not an instance of any of the subclasses of the partition.
Edge Subclass of 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.).
implementation of the process and metaconceptualisation
During the meta-implementation, the meta-model expressed in LBIR is transformed into a SQL Term
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: define table horizontal [Concept dictionary] as CD define field [Concept name] as CN begin type term; repeated no ; multiplicity (1,1); end field ; define field Instances as I begin type term; repeated yes; multiplicity (0,N); define field [Instance attributes] as IA begin type term; repeated yes; multiplicity (0,N); end field ; define field Relations as R begin type term; repeated yes; multiplicity (0,N); end field ; begin placed in [Binary relation diagram]; main field [Concept name]; end table ; shows the definition in LBIR of the concept dictionary, that is equivalent to the definition appearing in meta-table 3. Placed in binary relation diagram indicates that a graph called binary relation diagram should be designed before filling in he concept dictionary .
Meta-table 3. Meta-table of field description defining the table “concept dictionary”
Yes No No No
No Yes Yes Yes (1, 1) (0, n) (0, n) (0, n) schema. This eases the use of databases to store ontologies, taking advantage of the independence and integrity of the data, the minimisation of the redundancy, etc., provided database systems. by the relational 3.2. THE SOFTWARE LEVEL OF THE BIPHASE SOLUTION In order to allow the efficient use of the methodology proposed in 3.1, we has built ODE (see figure 5). The LBIR processing module automates the transformation, without loss of expressiveness, from a meta-model in LBIR to a SQL schema. Besides, it allows conceptualising ontologies following a meta-model selected by the user, and storing the result in a database following the SQL schema associated to the meta-model. Moreover, if you follow the reference meta-model to conceptualise your ontology you can use a generator of Ontolingua code. The main feature of ODE is that a change in the meta-model does not force a change in the program, since SQL schemas are generated in run-time and not in design time (as usual).
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.
SQL schema copying Database creation
MeMtae-tma-omdoedleinliLnBLIBRIR
Meta-model in LBIR
LBIR processing SQL-schema
SQL-schema
SQL-schema Conceptualisation
process Knowledge to be conceptualised conceptualisation
result conceptualisation
content Database to store the conceptualisation
PHASE I
Ontolingua translator
Ontolingua code PHASE II 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.
[Ben98] Benjamins, V.R.; Fensel, D.; GómezPérez, A.; Decker, S.; Erdmann, M.; Motta, E.; Musen, M. 1998. “The Knowledge Annotation Initiative of the Knowledge Acquisition Community (KA)2”. In: Proceedings of the 11th Banff Knowledge Acquisition for KnowledgeBased System Workshop (KAW 98), Banff, Canada. [Eri99] Eriksson, H.; Fergerson, R.W.; Shahar, Y.; Musen, M.A. “Automatic generation of ontology editors”. Knowledge Acquisition Workshop (KAW). Banff (Canada). 1999. [Far97] Farquhar, A.; Fikes, R.; Rice, J. “The Ontolingua Server: Tool for Collaborative Ontology Construction”.
IJHCS, 46(6) (1997) 707-728. [Fen00] Fensel, D. Ontologies: silver bullet for Knowledge Management and Electronic Commerce. Springer-Verlag. Berlin. 2000. [Fer01] Fernández-López, M. Método bi-fase para la conceptualización de ontologías basado en meta-modelos. Ph. Thesis. Facultad de Informática. Universidad Politécnica de Madrid. Spain. 2001.