We propose a general methodology to build up a domain ontology from one or more domain glossaries. The particular feature of this methodology is in the parallel construction of a domain ontology and a complete domain terminology. In this paper we fully describe the methodology phases and we apply them to a real-world example from the medical domain.
Nowadays, ontologies have become a relevant representation formalism and many
application domains are considering their adoption. This attention claims for
methods for reusing domain knowledge resources in the development of domain
ontologies. Accordingly, in this paper we discuss a general methodology to create
a domain ontology from one or more domain glossaries. Before explaining the
actual steps of the methodology, let us introduce some of the ideas that led to
its composition. Basically, the methodology is to be manually carried out by
the ontology developers with the help from domain experts. Some steps of the
methodology cannot be easily automatized because an explicit interpretation of
the semantics of terms is required as, e.g., in the initial phase of clustering. In
analogy to other proposals for the translation of thesauri [
Example: an ontology for orthodontic terminology In order to illustrate our methodology, we will employ a real-world motivating example, taken from an ongoing collaborative effort between our Department and the Department of Clinical and Biological Sciences. In fact, this project also constituted the motivation for the definition of our methodology. The objective of the project is in the definition and representation of a standard terminology for orthodontics: the motivation for this research can be found in the complexity of the orthodontic technical terminology and in the lack of a common reference standard for such terminology.
The complex relations among orthodontic terms suggested a structured
representation as an ontology : this representation allows to formally denfie semantic
relationships among domain concepts and explore implicit connections by
automated inference. As for the representation formalism, we have employed OWL
(Web Ontology Language) [
The basis for the development of the domain terminology has been identiefid
in the AAO Orthodontic Glossary [
In the next section, we will formulate a running example based on terms extracted from the original glossary that covers the rfist steps of development of the actual project ontology. 3
In this section we present the phases of our methodology using the following schema. For each phase we describe the required activities and the input and output documents, possibly enriched with an example of their structure. In some cases, we also provide some possible extensions or guidelines for the presented step. In the following examples, starting from a minimal (and incomplete) fragment of the initial glossary, we will concentrate on the development of the cluster for AnatomicPart and we show how to combine this with the cluster for AbnormalCondition in the conceptual schema.
Group terms of the original glossary in clusters. To define clusters, follow the is-a direction from terms to clusters: that is, every term should be seen as instance of a “type” defined by a cluster. Clusters do not have to be disjoint: however, terms must be classiefid in their most specific clusters. Some cluster inclusions can be suggested in this phase.
Input: original glossary (one or more).
Example: Gingiva The tissue that surrounds the teeth, consisting of a fibrous tissue that is continuous with the periodontal ligament and mucosal covering.
Ligament, periodontal See periodontal ligament.
Output: table of clusters. A grouping by cluster of the terms from the original glossary.
Example:
Cluster
Anatomic Part
Element that is part of the human Description anatomy.
Elements
Term
Source Gingiva O Ligament, periodontal O
Periodontal ligament O
An alternative way to define clusters of terms can be represented by a
specialization of a general superstructure: the structure could be either a foundational
ontology (as, for example, the well-known DOLCE ontology [
As for the structure of the documents, the table of clusters should contain a textual definition for each cluster, in order to clarify the intended meaning of the grouping. It is also desirable to maintain a column of information about the source glossary of each term. When suggesting inclusions between clusters, this should be specified in the table of clusters by indicating the superclusters of each cluster.
Find every term in the definitions that does not appear as a lemma in the glossary. Add the new terms to the glossary, providing them with a description: the description can also be a reference (e.g., see...) to present terms. Classify the new terms in the previously found clusters.
Input: original glossary, table of clusters. Output: updated table of clusters, updated glossary.
Example:
Cluster In the output document for this phase it is useful to keep track of the added terms: in the given example, in the Source column we specify with “A” that a term has been added, and with “O” if it belongs to the original terms. During this phase, it is possible to enrich the original glossary with other terms not contained in the original glossary.
Find relationships between terms, extracted from term definitions. Proceed a cluster at a time, searching for the distinctive relations of each cluster. Classify the relations under their respective cluster. An early informal description of the meaning and features (e.g., intended range and domain) of each relation should also be given.
Input: glossary, table of clusters.
Output: table of relations. Analogously to the table of clusters, it contains a grouping of the identified relations for each cluster and a description of their meaning.
Example: Relation hasContinuity isSupportOf
Anatomic Part Range
Domain
Description Anatomic Part Anatomic Part Continuity between two a
natomic parts.
Anatomic Part Anatomic Part Relates a part with its supporting parts.
Group terms with their synonyms (e.g., see...). Determine, among the synonyms, the preferred term to represent each concept.
Input: table of clusters.
Output: table of concepts. Refinement of the table of clusters in which terms are grouped to their synonyms.
Example:
Anatomic Part Concept
Synonym Gingiva Periodontal ligament Ligament, periodontal Tissue
Tooth
Find concepts that represent subclasses of the cluster they are in. Group concepts belonging to the new found classes. In general, try to create a partition of the cluster, possibly adding new classes at the same level of the found subclasses. Input: table of concepts.
Output: table of concepts, updated with class groupings.
Example:
Anatomic Part Class Tissue (Generic) Tooth
Concept
Synonym Gingiva
Periodontal ligament Ligament, periodontal
Using a graphical modelling formalism (such as E-R diagrams or UML models), proceed through the following steps: 1. Skeleton schema: group clusters in areas. Find abstract relationships between them, by generalization of the previously found relations. 2. Refinement : separately develop every area, starting from the subclasses found in the previous phase. Denfie inclusions between classes and relations and refine features and restrictions of the relations. 3. Integration: build the nfial model by combining area schemas and renfiing relationships among areas. Input: table of concepts, table of relations.
Output: ontology conceptual model. A graphical representation of the conceptual structure of the domain ontology.
Example: A skeleton schema for the clusters AnatomicPart and AbnormalCondition is shown in Figure 1. In Figure 2 we show the refinement for the class AnatomicPart and for its relation hasContinuity. By joining this with the refinement for AbnormalCondition (not shown), we obtain the final integration schema in Figure 3.
We do not put a constraint on the graphical language used to develop this phase,
as long as it is enough usable and expressive to develop the ontology conceptual
model: in our examples we have adopted an UML metamodel inspired to the
one of [
Represent class and property hierarchies in the nfial representation language (OWL, description logics).
Input: ontology conceptual model.
Output: ontology schema. Final representation of the class and property taxonomies.
Represent class instances as individuals; encode textual definitions for each concept by means of property values and restrictions.
Input: ontology conceptual model, ontology schema, glossary.
Output: domain ontology. Final representation of the domain ontology, complete with information about classes, relations and individuals.
The previous phase should be formalized to explain how to encode the textual definitions in terms of relations and logical connectives. This formalization clearly depends on the expressivity of the nfial representation language and its constructors.
Annotate each class and individual with information derived from glossary: the most relevant information is preferred term, synonyms, textual definition. Input: domain ontology, table of concepts, glossary.
Output: annotated domain ontology.
Example: An example of a domain ontology enriched with an external annotation is given in Figure 4. With the last example we have shown a possible way to annotate the final domain ontology: we propose to include the annotations in a separate ontology, in which the description of each concept appear as an individual. For every description, the information about the described concept (such as its preferred term and synonyms) is linked as datatype properties. In this way, it is easy to uniformly associate different descriptions for each concept (for example, distinct by language or target users), regardless of the representation of the concept as a class, individual or property. 4
As ontologies have been applied in the modeling of domains of ever increasing
complexity, a principled approach to their design is necessary. As such, the efild
of ontology engineering has become a rich and articulated research area (see, for
example, the effort in the development of a general methodology for ontology
networks in the EU funded project NeOn2). We give a brief outline of the efild
in this section: for more complete and detailed surveys, see [
Most of the proposals of general methodologies for ontology development are
inspired by a top-down approach: well-known examples are the DOLCE
methodology [
document (ORSD). Recent methodology proposals, like DILIGENT [
Such general approaches are very interesting in that they show the benefits
of a structured and domain independent approach when dealing with ontology
development. However, it is widely accepted that taking into account relevant
domain features from the beginning of the ontology development process yields
more effective results: as such, more specialized, domain dependent
methodologies have been proposed. Moreover, as emphasized in [
In this paper we have discussed a methodology for the construction of a domain ontology on the basis of one or more (possibly incomplete) glossaries: we have also discussed how this methodology allows to build a complete terminology for the domain of interest. As a motivating example, we have applied it to a medical domain case. In the following, we summarize some of the directions for future work, both for the original project and for the methodology renfiement. As for the orthodontic terminology development project, our next step is to complete the ontology with terms not yet considered, also by solving some current representation issues. Before proceeding to the publication and diffusion of the final ontology, the quality of the ontology has to be checked by domain experts. Also to help in this publication and valuation activity, we are currently developing a web application for the consultation of the ontology: the application will allow users to explore the ontology structure starting from terms in the final glossary. Our future work in the methodology refinement should include a formal definition for transformations from textual descriptions of concepts to their logic representation. Similarly, we need also to denfie formal definitions for methods for extracting relations from textual descriptions of concepts. Other interesting directions of work concern the analysis on the potential automatization of some phases and, on the ontology evaluation side, the study of the formal properties of the resulting ontologies. The rfist can involve the use of NLP techniques for clustering or saturation phases. Both automatization and evaluation can benetfi from the application of our methodology in different domains.