=Paper=
{{Paper
|id=Vol-64/paper-1
|storemode=property
|title=Meta-modelling for ontology development and knowledge exchange
|pdfUrl=https://ceur-ws.org/Vol-64/fernandez.pdf
|volume=Vol-64
|authors=Mariano Fernandez-Lopez
}}
==Meta-modelling for ontology development and knowledge exchange==
Meta-modelling for ontology development and knowledge
exchange
Mariano Fernández-López
Laboratorio de Inteligencia Artificial
Facultad de Informática
Universidad Politécnica de Madrid
Campus de Montegancedo sn.
Boadilla del Monte, 28660. Madrid, Spain.
Tel: (34-91) {336-66-05, 336-74-39}
Fax: (34-91) 3-52-48-19
Email: mfernandez@fi.upm.es
ABSTRACT Presently, methodologies do not propose to adapt
One of the sources of heterogeneity of ontologies the mechanism of modelling to the different
is that different ontologies have different ontologies to be built. However, our experience in
necessities of modelling. This paper presents a bi- different projects (the (KA)2 initiative [Ben98],
phase method to deal with these different the multidisciplinary project AM9819 about
necessities. Phase I of the method models how to environmental pollutants, etc.) show that different
model the ontology, obtaining a meta-model. Such domains should be modelled in different ways.
meta-model can be expressed in LBIR, a formal Table 1 shows the components that have been
and declarative language that has been specifically used in different ontologies. We can see that there
designed for this task. To save resources, a are variations from some ontologies to others.
reference meta-model that can be modified and Some ontologies have been built using a lot of
reused is provided. During phase II of the method, attributes and no relations, others have been built
the ontology is modelled following the meta- using constants, some of them have first order
model obtained in the first phase. Furthermore, a logic formulas, but others do not, etc.
tool (called ODE) provides software support to
Apparently, one solution to this problem would be
the method. Such tool generates SQL schemas
to consider all the “necessary” components
from LBIR, and allows the modelling of the
(concepts, attributes, first order logic formulas,
ontology following the selected meta-model. This
constants, etc.) when an ontology had to be built.
approach eases the interoperability between
Nevertheless, such solution has the following
groups located in different geographical locations
drawbacks: (1) Our experience has shown it is
that have to build the same ontology, since the
possible that need for a component is not
meta-model to be used can be exchanged through
perceived a priori, that is, it is possible the
LBIR.
necessity of a component is only detected when it
KEYWORDS is needed in an ontology. (2) New research about
modelling can provide new components and new
Ontology, meta-model, modelling, method, LBIR, ideas about how to use old components. (3)
ODE. Considering non-useful components when an
ontology is built can cause confusion in
1. EXPOSITION OF THE PROBLEM modellers, and especially when they are not very
Even though Ontological Engineering is a very experienced.
young area in Artificial Intelligence, there exist
Besides flexibility in the components to be used
some methodological proposals for building during the modelling, the knowledge should be
ontologies: Uschold and King’s methodology
presented in diffe rent ways to different experts.
[Usc95], Grüninger and Fox’s methodology
[Grü95], METHONTOLOGY [FeG99], etc. A Summarising, a rigid way to model brings us
study and analysis of methodologies for building back to the classic knowledge-acquisition
ontologies can be found at [Fer99]. This study bottleneck [Eri99].
shows that METHONTOLOGY is currently the
most mature methodology.
1
Instance First order logic Arithmetic TOTAL
Ontology Domain Concepts Relations Constants Instances
attributes formulas formulas TERMS
CHEMICALS.1 Chemical 10 6 0 0 0 1 20 37
CHEMICALS.2 Chemical 16 22 0 0 27 3 103 173
CHEMICALS.3 Chemical 16 20 0 2 27 1 103 169
Knowledge acquisition
(KA) 2 restructured 78 12 47 0 0 0 102 239
community
Reference Ontology Ontologies 23 70 9 0 0 0 8 110
Standard Units restructured Measure units 22 3 0 2 0 1 65 93
Monatomic ions Environmental ions 62 11 3 0 6 0 0 82
Silicates Silicates 84 17 8 0 0 0 0 109
Laboratory of Artificial
Hardware 49 56 0 0 0 0 56 190
Intelligence's hardware
ELLOS Ontology Catalogue of clothes 8 16 6 0 0 0 20 48
Catalogue of products in
Tradezone Ontology 9 3 3 0 4 0 0 22
general
SNCF Ontology Travels and hotels 13 37 4 4 2 2 1 69
FIDAL Ontology Contracts 6 15 8 0 1 0 7 37
Table 1. Components used in the ontologies developed with the bi-phase method
2
Figure 1. Concept classification tree in the domain of flights
Table 2. Concept dictionary in the domain
of flights
concepts, attributes, first order logic formulas,
Focussing on the case of METHONTOLOGY, it
etc., and they are thought to be manipulated by
proposes to carry out the following steps to
experts in the domains to be modelled. Figure 1
develop an ontology: specification in natural
presents an example of a graph: a concept
language, conceptualisation using tables and
classification tree, and table 2 is an
graphs, formalisation (e.g. using frames), and
implementation (e.g. using the Ontolingua example of concept dictionary. Tables
language [Far97]). According to the and graphs in METHONTOLOGY are not fixed,
METHONTOLOGY viewpoint, conceptualisation since the engineer can use tables or graphs that
is the modelling at the knowledge level [New82], can be different to the proposed ones by the
hence, the knowledge is modelled independently methodology. However, METHONTOLOGY
of the implementation language to be used1 . The does not propose a precise way to specify how the
proposed tables and graphs allow modelling tables and the graphs to be used during the
conceptualisation are. Besides, this methodology
1
Such idea of conceptualisation is inspired in the Hayes-Roth and does not propose how to add a new type of table,
colleagues’ approach [Hay83]. how to add a new field to a type of table, how to
3
delete one of the types of the proposed graphs, or In the following sections, a solution to these
how to elaborate a completely new modelling way problems will be presented. Section 2.1 will
with completely new graphs and tables. Therefore, present the bi-phase method and, section 2.2, its
if several groups in different locations have to software support: ODE. The paper will finish with
build an ontology collaboratively, there are the conclusions and future trends.
problems to agree and exchange the
characteristics of the tables and graphs to be
used (see figure 2).
Figure 2. Problems in collaborative construction when the characteristics of tables and graphs are not
clearly specified
conceptualisation, meta-formalisation and
2. THE PROPOSED SOLUTION
meta-implementation. On the other hand, phase
2.1. THE METHODOLOGICAL LEVEL OF II carries out the specification, conceptualisation
THE BI-PHASE SOLUTION (following the meta-model obtained in phase I),
formalisation and implementation of the ontology.
To allow a more flexible modelling of ontologies As you can see, in this bi-phase method, there is a
and to ease the exchange of characteristics of modelling both at Newell’s knowledge level and
tables and graphs, the bi-phase method proposes symbolic level during phase I as well as phase II.
to model how to model the ontology. Until now,
the purpose of the ontology engineer was to model To facilitate the building of meta-models, a
some parts of the world, for example, flights, reference meta-model is proposed. It is possible
chemical elements, etc. (see figure 3), however, to modify this reference meta-model according to
with the bi-phase method, modelling the process the modelling needs of each ontology. Such meta-
of modelling is also recommended, that is, model is expressed by means of meta-tables and
building a meta-model is also proposed. meta-graphs, and it is also formally expressed.
Particularly, the part of the modelling process to The reference meta-model allows building
model is the conceptualisation, which is the base ontologies with: concepts, class and instance
of the remainder steps of the modelling. attributes, facets of such attributes, relations, first
order logic formulas, arithmetic formulas,
The bi-phase method follows the constants, and instances. These components
METHONTOLOGY approach, although in two appear in the reference meta-model because each
levels. On the one hand, during phase I, the one of them have been used in some of the
ontology conceptualisation process is specified in ontologies developed during the experimentation.
natural language, conceptualised using tables and Besides, we have checked that the reference meta-
graphs (called in this phase meta-tables and model contains the static components of the
meta-graphs), formalised using a formal classic languages for ontology development
language, and implemented in SQL (see figure 4). (Ontolingua, OKBC, OCML, FLogic and
Thus, the result of this first phase is a meta-model LOOM). We say static components because we do
presented in meta-tables and meta-graphs, in a not consider rules and procedures. This reminds as
formal language, and in SQL. The steps of this future work.
phase are called: meta-specification, meta-
4
Figure 3. General overview of the ontology development using meta-models
We have also developed a tool, called ODE, in However, it is not the only tool allowing flexible
order to provide software support to the bi-phase modelling, since Protégé-2000 [Fri00] permits the
method. Ode is especially designed to facilitate user to redefine its components (made by classes,
the application of the method. slots, etc.).
Figure 4. Bi-phase method to build ontologies
In [Fer01] a complete description of the method is
presented. Such description includes the tasks to
5
be performed, the inputs, the outputs and the in an exhaustive partition3 . Besides,
participants. This description includes a way to it can be also specified that a table to use during
manage the changes in meta-models, even when the conceptualisation of the ontology is the
an ontology is being developed with such meta- concept dictionary. The possible fields of
model and new necessities are detected. There is such table would be: concept name,
also a description of the architecture of ODE. The instances, instance attributes, etc.
method and the tool have been tested in the above Concerning the recommended order, it should be
mentioned projects (the (KA)2 initiative, the said that the elaboration of the concept
multidisciplinary project AM9819 about classification tree should begin before starting the
environmental pollutants, etc.). 10 different meta- concept dictionary. And with regard to the
models have been built with a total of 33 consistency verification rules between the concept
additions, removals and modifications with classification tree and the concept dictionary, all
regards the reference meta-model; such meta- the concepts of the tree should be in the concept
models have been used in 11 different domains: dictionary and vice versa.
chemical elements (169 terms with 27 first order
formulas), knowledge acquisition community (239 2.1.2. Meta-conceptualisation of the
terms with no first order formulas), hardware (190 conceptualisation process
terms with no first order formulas), ontologies
(110 terms with no first order formulas), measure For (meta-)conceptualising in phase I, the bi-
units (93 terms with no first order formulas), phase method proposes: (a) a set of meta-tables to
monatomic ions (82 terms with 6 first order describe the tables and graphs to be used during
formulas), silicates (109 terms with no first order the conceptualisation in phase II; (b) a meta-graph
formulas), catalogues of cloths (48 terms with no to describe the order in the conceptualisation in
first order formulas), travels (22 terms with no phase II; (c) and meta-tables and meta-graphs to
first order formulas), hotels (69 terms with 2 first describe the consistency verification rules. Thus,
order formulas) and contracts (37 terms with 1 for example, the meta-tables of node
first order formula). Other meta-models have been description, and the meta-tables of
built containing meta-graphs and meta-tables to edge description are proposed to define the
model databases, other meta-models contain meta- details of the graphs, and the meta-tables of
graphs to model tasks, and other meta-models field description are proposed to define
even contain schemas of bills, invoices, etc. as the details of the tables. For instance, meta-tables
meta-tables. 1, 2 and 3 show the description of the taxonomy
and of the concept dictionary, used both in the
In the following sub-sections, a brief description
examples of section 1.1.1. In all these meta-tables,
of the steps of phase I will be presented.
the meta-field symbol is filled in with
2.1.1. Meta-specification of the abbreviations. In the case of meta-table 2, which
conceptualisation process describes a graph, the meta-fields input and
output edges, input multiplicities
During phase I, the meta-specification describes, and output multiplicities are used to
in natural language: (a) what tables and graphs establish how many edges can go in and go out to
will be used during the conceptualisation of the and from a node. In the case of meta-table 3,
ontology; (b) the recommended order to fill in the which describes the concept dictionary, the meta-
tables and to build the graphs; and (c) the field format restricts the possibilities to fill in
consistency verification rules between tables, the cells (text, list, logic expression, etc). Is it
between graphs, and between tables and graphs. main is true when the described field is the
For example, it can be (meta-)specified that a identifier of the row. Repetition in the
graph to be used during the conceptualisation is
same table is true when the field can be filled
the concept classification tree, that
in with the same value in different rows. And
the nodes of this graph are concepts, and that
multiplicity is true when the same cell can
the edges are subclass of, subclass in
have several values.
a disjoint partition2 , and subclass
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
2
‘Subclass in a disjoint partition’. A disjoint partition of a class is a set instance of the father class that is not an instance of any of the
of subclasses of this class that do not have common instances. subclasses of the partition.
6
Edge Symbol Description
Subclass of S A class C is a subclass of the parent class
To carry out the meta-formalisation, a formal and
P if and only if every instance of C is declarative language, called LBIR (Language for
also an instance of P. Building Intermediate Representations), has been
Subclass in a SDP A disjoint partition of a class is a set of
disjoint its subclasses where the subclasses do elaborated. Such language has the same
partition not have common instances. expressiveness as the meta-tables and meta-graphs
Subclase in an SEP An exhaustive partition of a class is a set used during the meta-conceptualisation. The LBIR
exhaustive of subclasses that covers all the class,
partition that is, there is no instance of the father description uses a context free grammar for the
subclass that is not subclass of any class syntax, and matrices to establish the meaning of
of the subclasses of the partition
the language. The following code:
Meta-table 1. Meta-table of edge
description defining the possible edges of the
graph “concept classification tree” define table horizontal [Concept dictionary] as CD
Node Symbol Descrip- Input Input Output define field [Concept name] as CN
tion and multipli- multipli- begin
outpud cities cities type term;
edges repeated no ;
Subclass (0, n) (0, n) multiplicity (1,1);
of end field ;
Concept C ** Subclass (0, n) (0, n)
define field Instances as I
in a
disjoint
begin
partition type term;
Subclass (0, n) (0, n) repeated yes;
in an multiplicity (0,N);
exhaus- define field [Instance attributes] as IA
tive parti- begin
tion type term;
repeated yes;
Meta-table 2. Meta-table of node multiplicity (0,N);
description defining the possible nodes of the graph end field ;
define field Relations as R
“concept classification tree” begin
type term;
The meta-graph to model the order during the repeated yes;
multiplicity (0,N);
conceptualisation is not presented due to the space end field ;
constraints. Concerning the consistency begin
verification rules between tables, between graphs, placed in [Binary relation diagram];
and between tables and graphs, the way to write main field [Concept name];
end table ;
them is based on operations on matrices
representing the tables and the graphs. Such shows the definition in LBIR of the concept
operations are similar to the ones used in the dictionary, that is equivalent to the definition
relational model for databases (projection, appearing in meta-table 3. Placed in binary
selection, difference, etc.). relation diagram indicates that a graph
2.1.3. Meta-formalisation and meta- called binary relation diagram should be designed
before filling in he concept dictionary.
implementation of the conceptualisation
process
Field Symbol Description Format Is it main? Repetition in the same table Multiplicity
Concept name CN ** Term Yes No (1, 1)
Instances are particular
Instances I cases of the concept Term No Yes (0, n)
The ones that allow
Instance attributes IA describing the instances of Term No Yes (0, n)
the concept.
Relations R Relations link concepts Term No Yes (0, n)
Meta-table 3. Meta-table of field description defining the table “concept dictionary”
schema. This eases the use of databases to store
During the meta-implementation, the meta-model
ontologies, taking advantage of the independence
expressed in LBIR is transformed into a SQL
and integrity of the data, the minimisation of the
7
redundancy, etc., provided by the relational figure 6). The second option, LBIR, is mandatory
database systems. if the current version of ODE is utilised to build
the ontologies.
3.2. THE SOFTWARE LEVEL OF THE BI-
PHASE SOLUTION The method and the tool have proved useful in
several Spanish and international projects.
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 Meta-model in LBIR
Meta-model in LBIR
Meta-model in LBIR
SQL schema. Besides, it allows conceptualising
ontologies following a meta-model selected by the
user, and storing the result in a database following
LBIR PHASE I
the SQL schema associated to the meta-model. processing
Moreover, if you follow the reference meta-model
to conceptualise your ontology you can use a
SQL-schema
generator of Ontolingua code. The main feature of SQL-schema
SQL-schema
ODE is that a change in the meta-model does not
force a change in the program, since SQL schemas
SQL
are generated in run-time and not in design time schema Conceptualisation Ontolingua
(as usual). copying process translator
3. CONCLUSIONS AND FUTURE TRENDS Knowledge to be conceptualisation Ontolingua code
conceptualised result
Database
creation
Although each ontology has its modelling needs,
there is not any methodological proposal to use a conceptualisation
content
different kind of modelling for each ontology.
PHASE II
The bi-phase method presented in this paper Database to store the
conceptualisation
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 Figure 5. ODE processes
are: meta-specification, meta-conceptualisation, One of the most interesting future lines, above all
meta-formalisation and meta-implementation. for ODE, would be the fast development of
During the second phase the steps are the ones translators from different meta-models into
proposed by METHONTOLOGY: specification, different implementation languages. An interface
conceptualisation, formalisation and to manipulate meta-tables and meta-grpahs would
implementation. To carry out the meta- be also interesting. Another important future trend
formalisation, a formal and declarative language would be a structured characterisation of
(LBIR) has been elaborated. Moreover, to provide ontologies according to their modelling needs.
software support to both phases, a tool has been Now, the modelling necessities are determined by
developed: ODE. the experience of the ontology engineers, who
To agree in the meta-model to be used, the interacts with the experts in the domain to be
different groups can exchange this meta-model in modelled.
meta-tables and meta-graphs, or in LBIR (see
8
Figure 6. Use of meta-models for cooperative
construction of ontologies
[FeG99] Fernández-López, M.; Gómez-Pérez, A.;
4. REFERENCES
Pazos-Sierra, A.; Pazos-Sierra, J.
[Ben98] Benjamins, V.R.; Fensel, D.; Gómez- “Building a Chemical Ontology Using
Pérez, A.; Decker, S.; Erdmann, M.; METHONTOLOGY and the Ontology
Motta, E.; Musen, M. 1998. “The Design Environment”. IEEE Intelligent
Knowledge Annotation Initiative of the Systems & their applications.
Knowledge Acquisition Community January/February. Pages 37-46. 1999.
(KA)2 ”. In: Proceedings of the 11th Banff
Knowledge Acquisition for Knowledge- [Fer99] Fernández López, M. “Overview of
Based System Workshop (KAW 98), Methodologies for Building Ontologies”.
Banff, Canada. Workshop on Ontologies and Problem-
Solving Methods: Lessons Learned and
[Eri99] Eriksson, H.; Fergerson, R.W.; Shahar, Future Trends. (IJCAI99). August. 1999.
Y.; Musen, M.A. “Automatic generation
of ontology editors”. Knowledge [Fri00] Fridman Noy, N.; Fergeson, R.W.;
Acquisition Workshop (KAW). Banff Musen, M.A. “The knowledge model of
(Canada). 1999. Protégé-2000: combining interoperability
and flexibility”. Workshop on Knowledge
[Far97] Farquhar, A.; Fikes, R.; Rice, J. “The Acquisition, Modelling and Management
Ontolingua Server: Tool for (EKAW) . Editor Springer Verlag. Jean
Collaborative Ontology Construction”. Les Pins (Francia ). 2000.
IJHCS, 46(6) (1997) 707-728.
[Grü95] Grüninger, M.; Fox, M. S. “Methodology
[Fen00] Fensel, D. Ontologies: silver bullet for for the design and evaluation of
Knowledge Management and Electronic ontologies”. Workshop on Basic
Commerce. Springer-Verlag. Berlin. Ontological Issues in Knowledge
2000. Sharing. Montreal, Canada. 1995.
[Fer01] Fernández-López, M. Método bi-fase [Hay83] Hayes-Roth, F.; Waterman, D. A.; Lenat,
para la conceptualización de ontologías D. B. “Building Expert Systems”.
basado en meta-modelos. Ph. Thesis. Addison Wesley Publishing Company,
Facultad de Informática. Universidad Inc. Massachusets , USA. 1983.
Politécnica de Madrid. Spain. 2001.
[Nec91] Neches, N. ; Fikes, R. ; Finin, T. ;
Gruber, T. ; Patil, R. ; Senator, T. ;
9
Swartout, W.R. “Enabling technology for
knowledge sharing”. AI Magazine, Fall
1991. Pages 36-56. 1991.
[New82] Newell, A. “The Knowledge Level”.
Artificial Intelligence. Volume 18.
Number 1. Pp. 87-127. January 1982.
[Usc95] Uschold, M. King, M. “Towards a
methodology for building ontologies”.
Workshop on Basic Ontological Issues in
Knowledge Sharing. International Joint
Conference on Artificial Intelligence
(IJCAI). Montreal, Canada. 1995.
10