This paper is intended to approach one of the main problems in ontology engineering: the lack of a shared terminology. Nowadays there exists several biomedical ontologies describing overlapping domains, but there is not a clear correspondence between the concepts that are supposed to be equivalent or just similar. These resources are quite precious but their integration and further development are expensive. Terminological or lexical resources may support the ontological development in several stages of the lifecycle of the ontology including ontology integration and the labeling of concepts. In this paper we investigate the use of lexical resources during the ontology lifecycle using the example of the Health-e-Child (HeC) project. We claim that the proper creation and use of a shared lexicon is a cornerstone for the successful application of the Semantic Web technology within life sciences.
Large domain ontologies are emerging from collaborative efforts in the life sciences, being its main aim to achieve the interoperability among the different research resources by assuming a common conceptualization. These resources mainly consist of both domain ontologies and terminological resources (e.g. thesauri), which allow researchers to process, store and share the ever increasing knowledge derived from their experiments. So far, these two kinds of resources have usually lived apart, being its later integration a very hard task. However, some exceptions exist where the lexicon is integrated with a semantic network (e.g. the Unified Medical Language System3). In this paper, we show that both cases have serious drawbacks.
Instead, we propose a loose coupling between the domain ontologies and a unique lexicon. Along this paper we show that the use and maintenance of such a shared lexicon will enable both a better integration of domain ontologies with 3 http://www.nlm.nih.gov/research/umls/ existing lexical resources and the proper evolution of the lexicon according to these ontologies. We claim that the use of a shared lexicon will ease some of the problems present during the development of ontologies and the interoperability of the ontologies.
In this paper we assume that domain ontologies and lexicons have different
purposes, and therefore they cannot be treated with the same techniques nor
simply merged into a common resource. A lexicon consists of a compendium of
words enriched with information of its usage [
Regarding the semantically equivalent groups defined in a lexicon (e.g. thesaurus entries, synsets, etc.), they also present significant differences with respect to the concepts of domain ontologies. These semantic groups do not offer a clear cut on their meaning as in an ontology where the concepts present disjoint interpretations. Rather lexicons present fuzzy frontiers to allow the slightly different interpretations humans can express with them.
In Figure 1 we have ordered the existing formalisms (denoted by boxes)
according to their semantic expressiveness. Existing biomedical resources are
placed to their closer formalism. Genuine lexical resources are placed closer to
the left of the diagram like the Biolexicon[
The selected examples and use cases presented in this paper come from the
the application domain of the EC FP6 Health-e-Child (HeC) project [
The paper is organized as follows. Section 2 presents the ontology lifecycle steps and motivates the relevance of having and using a shared lexicon/thesaurus.
Terms & Linguistic Relationships
Concepts and Formal Ontology Terminology
Frames
Weak Semantics
Terms/ Glossary
Simple Taxonomy
HGNC UMLS Lex BioLexicon UniProtKB
Taxonomy UniProt
Thesauri
Terminologia UMLS Anatomica WordNet ICD
NCI
UMLS SN
OBO MesH
Semantic Network
GALEN (Grail - OWL) FMA SNOMED (Prot´eg´e) (KRSS) (Frames)
Description
Logics
Complex
Logics
Strong Semantics A discussion about current efforts, limitations and desired requirements for a shared lexicon are presented in Section 3, moreover the main lexicon engineering techniques are introduced. Section 4 comments the main experiences carried out within the HeC domain. Finally some conclusions are given in Section 5. 2
Lexical forms present in available resources can be used for labeling ontological concepts. The reuse of these labels in different ontologies in combination with a proper definition of the ontological concepts may enable better integration of ontologies. This section is intended to show the main problems that experts, knowledge engineers and ontology engineers find in the different stages of the lifecycle of the ontology development and how the use of a shared lexicon could ease these problems.
In this paper we adopt the METHONTOLOGY methodology [
Requirements Specification
Within the objectives of the HeC project, an ontology to describe a kind of
arthritis called JIA (Juvenile Idiopathic Arthritis) requires to be created. This
ontology is intended to represent the involved knowledge in JIA by means of
different levels of granularity: molecular (e.g. genomic and proteomic data),
cellular (e.g. results of blood tests), tissue (e.g. synovial fluid tests), organ (e.g.
affected joints), body (e.g. damage index, rheumatology examinations,
treatments), population (e.g. epidemiological studies). The purpose of this multilevel
representation is to give a complete characterization of the different JIA
subtypes in order to provide a rich ontological layer to the HeC System. This
semantic layer will be applied in Query Enhancement over the patient data, and
in the Decision Support Systems. JIA is a rare kind of Arthritis and there is
not yet a consensus about its classification nor even its name [
Knowledge Acquisition
The knowledge acquisition in HeC is based on a set of medical protocols (in
[
The reuse of knowledge represented in ontologies (see [
Additionally, Semantic Compatibility should be also taken into account. Once the lexical correspondence between concepts has been established, the ontologies (or ontology modules) can be merged. At this point new challenges about the semantic compatibility between the ontology axioms (e.g. unsatisfiability when merging) arise, but they are outside the scope of this paper.
Currently there exist several efforts in the creation of large biomedical ontologies. However, it seems they are evolving in a rather independent way. We can understand that the conceptualization and formalization evolve with respect to the specific requirements of a specific application, but the used nomenclature should be shared. For example, the use of the concept Chronic Childhood Arthritis9 could vary between different domain ontologies, but the used term (JIA, JCA or JRA) should refer to the same entity in the domain. The reuse of terms for labels from a shared lexicon (e.g. UMLS) will relax considerably the required 4 NCI thesaurus: ftp://ftp1.nci.nih.gov/pub/cacore/EVS/NCI_Thesaurus 5 GALEN Ontology: http://www.co-ode.org/galen 6 Open Biomedical Ontologies: http://www.obofoundry.org/ 7 Ontology Matching Initiative: http://www.ontologymatching.org/ 8 Disease Ontology is an example of ontology enriched with synonyms coming from shared thesauri like UMLS or ICD. However, we propose that ontologies should only maintain a link to the correspondent thesaurus, see Section 3.4 9 Chronic Childhood Arthritis is the preferred concept name in UMLS matching tasks between ontologies. Ontology concepts could use any preferred nomenclature (no spaces, use of hyphens, acronyms, short expressions, etc.) but they will be annotated with a unique concept interpretation, that is, they will point to an entry in the shared lexicon.
As commented earlier, knowledge acquisition can require merging different sources and ontologies. METHONTOLOGY already proposes the creation of a glossary to enrich ontologies with synonyms and definitions in order to facilitate the integration with other resources. Undoubtedly, this proposal should be kept, but we should go further by making such a glossary available to all community. 2.3
Conceptualization
As commented above, the granularity of the ontology will be connected to the
purposes of the application, in this sense, the same entry in a lexicon could
have different interpretations within different ontologies. This characteristic is
related to the localized semantics proposed in [
(1) (2) (3)
Such interpretations may belong to three different JIA ontologies used, probably, for different application purposes. If in some moment they are required to be integrated in only one ontology (perhaps a consensus is achieved and it is established a unique classification criteria) the matching between labels (terms) would be easier if a shared lexicon was used to annotate the concepts (i.e. Chronic Childhood Arthritis ≡ JIA ≡ JCA ≡ JRA). The semantic integration, as commented in Section 2.2, will depend on the compatibility of the used axioms within the conceptualization and formalization of the merged JIA ontologies.
It is worth mentioning that the design requirements of an ontology may involve concepts with labels that are not present in most of the available lexicons. For example, not all the subtypes of JIA are properly described in UMLS. As commented, lexicons will help ontologies to use a common nomenclature, but ontologies will also help lexicons to evolve. In general, ontologies will require a finer granularity than the initially expressed by lexicons and will demand the necessity of new concepts given the specific requirements of the domain. Obviously, a new challenge arises, that is, how to maintain consensual and shared lexicons up-to-date with respect to the new specific ontologies and their evolutions. Additionally, hypernym relationships within the lexicon may be useful in order to check the coherence of the ontology conceptualization, that is, it may be helpful to consider desired subsumptions (e.g. J IA v Systemic Disease) or even to avoid non desired ones (e.g. J IA v N on Systemic Disease). 2.4
Evolution and Maintenance The evolution and maintenance (addition of new concepts, the deletion of obsolete ones, the re-structuring of the already defined concepts, the addition of new facts, etc.) of an ontology may be produced due to different reasons: requirements changed, the domain has changed (e.g. new facts were discovered) or the point of view of the domain changed (e.g. use of a different classification criterion). The evolutions will imply to come back to previous steps in order to acquire new knowledge and to integrate this knowledge within the ontology. Again, the lexicon will play a key point providing the concepts necessities when possible or being updated with new ontology requirements in order to keep up-to-date for further ontology demands.
In biomedicine the change and extension of the domain evolves quickly.
Publications represent an important source of brand new facts of domain knowledge.
For example Medline10 indexes more than 800,000 new journal papers per year
containing the last research done in more than 700 topics. Text mining
techniques try to identify within the text concepts and facts relating them. These
techniques usually use domain lexicons in order to detect interesting entities
within text. However several studies (e.g. [
We have presented the relevance of the lexicon in the ontology lifecycle and how this lexicon could be updated accordingly. Basically, the lexicon will provide the necessary terminology required for the existing concepts. In case there is no entry (e.g. subtypes of JIA) for a concept, the current process may suggest the creation of this new entry.
The proper creation of new entries will require the selection of the appropriate
terms (i.e. preferred name and synonyms). These terms may be provided by a
10 Medline: http://medlineplus.gov/
community effort, where several domain experts study the appropriate set of
terms, and/or using natural language processing (NLP) and text mining [
As a consequence, the existence of a common thesaurus can help to link concepts from existing resources at the same time that it ensures no duplicate entries for the same concepts. This thesaurus will collect the different terms in a common repository allowing ontologies to be linked accordingly. Thus, the final scenario consists of one thesaurus and many specific ontologies. These ontologies may be designed according to different criteria, for they are usually applied in different contexts. We find the best example in the OBO ontologies where several ontologies can overlap in some of their concepts.
The generation of a common thesaurus requires the resolution of several issues like an agreement concerning the meaning of the entries in the lexicon. As we have seen, JIA already presents a difficult conceptualization even among domain experts. The outcome of the research in the field may require not only to create new concepts but also to split existing ones. This will imply the necessity of maintaining the ontology up-to-date, since some of the links have become obsolete (see Section 3.4). Additionally, another way of solving the problem would consist of the generation of several versions.
Although current approaches represent an important initiative for the construction of a shared lexicon they still lack some important requirements to allow a straight forward interoperability with ontologies and text resources. Next section presents the main limitations of current efforts and proposes some requirements to be followed in order to get the intended lexicon. 3.1
Limitations of current reference lexicons
The UMLS Metathesaurus (UMLS-Meta) represents the best effort for the
creation of a reference thesaurus. However it has several drawbacks, most of them
because of its complexity, since in some cases the UMLS-Meta is closer to an
ontology than to our intended thesaurus/lexicon. The UMLS-Meta contains
concepts from more than 100 terminologies, classifications, and thesauri, for
example: MesH, SNOMED CT or ICD. This makes UMLS-Meta a really rich source of
knowledge, but also a source of ambiguity, redundancy and meaningless entries.
In the literature we can find some efforts [
After filtering redundant cases and solving some of the trivial ambiguity problems the UMLS-Meta still contains a huge number of concept labels that surely will not have a correspondence neither in ontology labels nor texts. Next we present some representative cases (extracted from a portion of UMLS-Meta related to the JIA domain) that our intended thesaurus should avoid: Descriptive names Some synonyms are closer to a text definition than to a concept name. For example, Therapeutic or Preventive concepts C0199105: “Anaesthesia for open procedure on knee joint Procedure”, and C0580168: “Amputation of finger through distal interphalangeal joint”. Nevertheless, not all concepts can be described with a few words. Indeed, such complex concepts should be described in formal ontologies by combining somehow smaller units of meaning of the lexicon, e.g. concept C0580168 can be formally described as Amputationu∃involve.F ingeru∃through.InterphalangealJ oint, where the semantics for each of its elements is defined in a formal ontology. Additionally, each of the concept constituents can be linked to entries of the lexicon.
Parametrization in the label The Clinical Drug C1614077 has the preferred name “Etanercept 50 mg/mL subcutaneous solution”. This term indicates not only the drug name but also the dosage for this pharmaceutical product. Therefore the lexicon should contain only the generic name, and then the formal ontologies should represent “Etanercept 50 mg/mL subcutaneous solution” as either a subclass of “Etanercept” or just as an instance. Complex nomenclature Chemicals formulae as in concept C0255404: “Nmethyltropan-3-yl 2-(4-bromophenyl)propionate” are useful as a definition of the concept, but an ontology concept or a thesaurus term should not use this nomenclature. Moreover, entities detected in text rarely will match with this term.
Inappropriate syntax Concept C0366794 with Semantic Type Clinical Attribute has the preferred name string “Hemoglobin C/Hemoglobin.total:Mass Fraction:Point in time:Whole blood”. Obviously this string is encoding some data perhaps only understandable in the source vocabulary.
As commented above, UMLS-Meta is more complex than a simple thesaurus or a glossary of terms and it does not only contain synonymy relations but also 11 Filtering UMLS and solving Ambiguity: http://skr.nlm.nih.gov/papers/ inclusion relations like hyponymy and hypernymy (i.e. is-a or subsumption relations in ontologies) and part-whole relationships like meronymy and holonymy (i.e. has-part, part-of). This makes UMLS-Meta really hard to evolve and maintain properly, and the inclusion of new vocabularies may introduce unexpected classifications of the concepts (i.e. cycles). The desired thesauri should contain a clearer hierarchy with or only hypernymy or only meronymy. The granularity of the lexicon hierarchy could vary from a top level ontology classification (e.g. UMLS Semantic Network) to fine granularity hierarchies like the OBO classifications or the UMLS-Meta hypernymy hierarchy itself. More complex classification of the concepts should be delegated to the ontology conceptualization process. 3.2
Limitations of current reference ontologies The OBO ontologies present a huge community effort in the development of ontologies, but we still miss the use of a common lexicon/thesaurus to normalize the used nomenclature. Moreover, the OBO ontologies, like the UMLS-Meta , are in the middle of what we expect from an ontology and from a lexicon. The underlying logic of the OBO ontologies is not too complex, being in most cases limited to simple taxonomies (e.g. Disease Ontology ). The Gene Ontology has also assertions but in the most of cases they refer to concept metadata. The use of more complex logic would give more expressive power to express complex concepts that can not be described only by a name an a set of subsumptions. Moreover this kind of ontologies will provide a framework to classify facts or concepts of the world according to a concept definition without making an explicit specification of the subsumption. This would make easier the introduction of new concepts within the hierarchy by only giving the definition of the concept. For example, from the simple set of axioms 4 to 6 we would infer that J IA v Systemic Disease, but without defining explicitly this axiom.
(4) (5) (6)
Nevertheless, complex logics have also drawbacks in the sense of computability and therefore a good balance between efficiency and expressivity should be achieved. Apart from the expressivity issues, the OBO ontologies also present some lexical problems. On one hand some of the concepts names used in OBO ontologies, like some UMLS-Meta entries, are closer to definitions than to a concept name (e.g. GO:0007180 “transforming growth factor beta ligand binding to type II receptor” (biological process) or GO:0016456 “X chromosome located dosage compensation complex, transcription activating” (cellular component)). Like in UMLS, these concept names are of little help when performing for example text mining tasks. On the other hand, these ontologies are overloaded with too much metadata (i.e. synonyms, definitions, references) making hard their management. For example, the Human Disease Ontology contains 14772 classes (and 1 property), 18593 subsumption relationships and 442168 entity annotations (i.e. synonyms, references to entries of other thesaurus, mainly UMLS, ICD, SNOMED and MESH), therefore an average of almost 30 annotations per class. The case of the Gene Ontology is similar, containing more than 450000 entity annotation axioms for less than 30000 classes, and 150000 assertion axioms being used as a annotation values.
More formal ontologies like the Foundational Model of Anatomy (FMA is
available as Prot´eg´e Frames) and Galen (available in Grail and OWL) seem to
be projects being developed independently with respect to the UMLS-Meta and
OBO foundry efforts. Galen contains some information about synonymy but, as
far as we know, it does not provide an explicit connection with a public
lexicon, indeed they present the problem of label (i.e. term) selection12 to better
describe the concepts without ambiguity. As commented previously some
concepts are hard to describe and the selection of a proper label for them is not
a straightforward task. The lexicon should provide a consensual term for the
label and the corresponding definition. As known, natural language could be
rather ambiguous when describing complex and similar concepts, for this reason
the ontology should provide a logic based and non-ambiguous description of the
desired concept. On the other hand, the development of FMA13 represents a
quite interesting initiative since FMA uses Terminologia Anatomica (TA) [
Necessity of a Lexicon for properties
Finally, the use of the proper properties in the ontology lifecycle will have also
an essential role. On the one hand a lexicon of properties will be really helpful in
the correct connection between concepts, on the other hand the identification of
which properties are mainly used to relate concepts will help text mining
techniques to discover interesting knowledge from texts. In the literature we can find
some efforts in this line, mainly the ones proposing Ontology Design Patterns
(e.g. [
Thesauri-Ontology Linkage
As commented previously, we intend to have per each domain one shared
thesaurus and several ontologies using subsets of the thesaurus concepts for
different application purposes. Each ontology concept will be annotated (i.e. entity
annotation axioms in OWL[
The desired thesaurus will require a unique entry identifier, the link to the words representing the terms including the preferred term and the synonyms. The different words can be kept in a common table referenced by the entries in the thesaurus that allows ambiguity analysis, i.e. how many entries are related to the same word. Metadata added to the thesaurus entries will ease the search for existing entries and solve ambiguous cases. The link of each entry to a Semantic Category (e.g. disease, gene, drug, organ, etc.) has been shown helpful for disambiguation purposes in many fields. Additionally, Semantic Categories can belong a top ontology similar to the UMLS Semantic Network. In this case, the finer the granularity of this semantic network is, the more precise will be the searches. However, if such a network is too intricate, the resulting lexicon will be hard to maintain for coherence. Thus, lexicon entries and their relationships must be just focused on the definition, origin and purposes of their entries according to the community requirements. Table 1 shows an example of entry for the desired lexicon: The evolution of the ontology may imply changes over the thesaurus like the addition of new entries, the deprecation of obsolete entries or the split of entries in several ones. Obviously the evolution of the thesaurus will also affect the referencing ontologies. For this reason, the lexicon should release stable versions periodically if important changes were made. Moreover each entry of the thesaurus should also have metadata about the status of the entry, indicating if the entry is being reviewed (new entries), is obsolete (pointing to which entry or entries should be used instead), or just if the entry is up-to-date. Referencing ontologies should periodically check if the referenced version of thesaurus is the last one and if the used lexical entries suffered any change or become obsolete.
The ontology and the lexicon are going to be quite interconnected during all the ontology lifecycle stages, therefore the used ontology editor should allow the connection to the lexicon in order to search for lexicon terms and to annotate ontology concepts with the proper lexicon entry. The UMLS Tab15 for the ontology editor Prot´eg´e16 was a good initiative trying to integrate UMLS-Meta within the ontology lifecycle. On the other hand, the OBO ontology editor17 also allows the linking (i.e. cross references) of defined concepts to synonyms coming from other resources. 4
The Health-e-Child project has provide us an excellent real application domain for our experiments. The Biomedical Knowledge Representation Workpackage is intended to give an ontology-based representation of the HeC domains (e.g. JIA disease) and to link that knowledge with external resources (e.g. text resources, thesauri, biomedical databases, etc.) We have mainly focused our efforts on the linkage to external knowledge. For this end we have worked on three main issues: text mining, annotation of medical protocols and ontology reuse. Currently, the development of the HeC ontologies is still an ongoing task.
The work presented in [
Within this project, another interesting task is to extract information
contained in medical protocols (e.g. patient data forms) [
Finally, regarding our ontology reuse, our main experience stems from
building modules from Galen and NCI ontologies [
In this paper we have presented a still opened issue: the necessity of use and maintenance of a lexicon for ontology engineering, specially for the Life Sciences. We have also emphasized the main limitations and problems of current approaches, which should be better coordinated, integrated and reused. The gap between knowledge representation languages and domain expert skills is another important issue to be addressed. In this way, very expressive languages like OWL are being used for representing simple taxonomies. Instead, defining more complex biomedical concepts requires good skills in Description Logics, which are difficult to understand by domain experts.
Future work will be focused on applying the ideas of this paper to the development of the HeC domain ontologies. We also aim at creating a light-weight thesaurus following the guidelines of this paper so that it provides all the necessary lexical information required by the HeC ontologies and their applications. Moreover, we will study how to filter and enrich existing lexical resources in order to create this new thesaurus.
The authors wish to thank the EU project Health-e-Child (IST 2004-027749) for providing us the application domain. This work has been partially funded by the Spanish National Research Program (contract number TIN2005-09098-C05-04). Ernesto Jimenez-Ruiz was supported by the PhD Fellowship Program of the Generalitat Valenciana. Antonio Jimeno-Yepes was supported by funding from the EC STREP project BOOTStrep (FP6-028099, http://www.bootstrep.org).