LinKFactory : an advanced formal terminology management ...



LinKFactory® : an Advanced Formal Ontology Management System

Werner Ceusters

Language and Computing (L&C)

Het Moorhof, Hazenakkerstraat 20 A

9520 Zonnegem, Belgium

werner@landc.be

Peter Martens

Language and Computing (L&C)

Het Moorhof, Hazenakkerstraat 20 A

9520 Zonnegem, Belgium

peter@landc.be

Abstract

As the web becomes more and more a worldwide platform for e-commerce, the creation of formal ontologies in all business sectors becomes crucial. It will become increasingly important to have computers understood what the real meaning is of the content of web pages, and of the data in the databases lying behind them. The real challenge will be to create formal ontologies that are processable and exchangeable by machines.

This paper describes LinKFactory®, a formal terminology and ontology management system that makes the creation and management of large scale, complex, multilingual and formal ontologies possible. We will explain the possibilities of LinKFactory® based on our experiences in creating a formal representation of the medical world, named LinKBase®, and linking it to several third party ontologies.

Keywords

Formal ontologies, semantic/linguistic knowledge base, ontology management system, terminology management system

INTRODUCTION

For many years, numerous teams, mainly of academic origin, have been working on systems that can handle terminology and the complex relations between individual terms. All those systems suffer from at least one of the major setbacks :

• Insufficiently formalised (designed for human use, not machine use)

• Not capable of handling the required large numbers of knowledge objects that form an adequate ontology

• Not designed to handle linguistic aspects, sometimes not even multiple language entries

To make the semantic web a success, these three setbacks will have to be overcome. Knowledge will have to be formalized so that machines worldwide have a shared and common understanding of the information provided. The systems developed will have to be able to handle enormous amounts of information very fast. As the web is a universal system, different languages will have to be supported, i.e. the system and the ontology’s developed will have to be language-independent, but however linkable to all languages.

The existing problem that researchers and industries have is to build and maintain an environment that makes it possible to create the needed large formal ontology’s while keeping processing time at a minimum. Formal ontology has been recently defined as the systematic, formal, axiomatic development of the logic of all forms and modes of being [3]. Management systems for smaller ontology’s have been developed (ODE [1], WebOnto [4], Ontolingua [5], HoZo [6], JOE [7], Protégé [8], OntoSaurus [9], …), but none of these are capable to deal with the enormous and complex ontology’s that will be needed to support the semantic web.

To resolve these problems (initially for the medical environment) L&C worked on creating a formal Ontology Management System, called LinKFactory®. The intent of the project was to implement a knowledge representation and compatible reasoning mechanism in a database structure. Among the objectives set for developing the data-model were:

• The ability to fully model a classification (ontology) of concepts with all their relevant relationships and definitions.

• The ability to connect languages with this conceptual model and use it for natural language understanding.

• The ability to connect the resulting association of terms and concepts with third party terminology systems such as SNOMED or ICD-9.

• All entities in the database should be versioned so that references can be made to older versions of objects without losing that information.

During the course of the project several extra capabilities were added to these base requirements that served to enrich the structure and allow for even more sophisticated features.

All this had to be modelled as efficiently as possible, and in such a way that it would allow easy manipulation from an application layer.

THE TOOL : LinKFactory®

General Description

LinKFactory® is the formal ontology management system, developed by L&C, used to build en manage the medical linguistic knowledge base LinKBase®. LinKFactory® is a tool that can be used to build large and complex language-independent formal ontology’s. “Language-independent” has to be understood in terms of independency from any specific language (such as English, French, Dutch, …), but not from language as a medium of communication. It is also not limited to small ontology’s, as most of the existing ontology editors are.

The fact that the ontology’s are language-independent has some major consequences on the type of applications that can run on top of them. It will, for example, be much easier to search for relevant information on the web (or a thesaurus): the search can be done in one language in free text. This free text search will be linked to language-independent concepts (based on the semantics) that will be the basis for the information retrieval. Since terms in several languages are attached to the concepts using a linguistic ontology [2], also relevant info in other languages can be retrieved, while semantically irrelevant information will not appear in the list of results.

System Architecture of LinKFactory®

LinKFactory® stores the data in a relational database (we currently use Oracle). Access to the database is abstracted away by a set of functions that are “natural” when dealing with ontology’s: get-children, find-path, join concepts, get terms for concept X, …

One of the main requirements of the project was that a server-side component should be developed that would allow developers to use a standardized API to program applications on top of the semantic database without requiring intimate knowledge of the internal structure of the database.

This component would also have to be database-independent (Oracle, Sybase, SqlServer have been tested), capable of dealing with multiple concurrent users and it would have to be stable. LinKFactory® is also platform independent (Windows, Solaris, Unix and Linux tested). Combining all these requirements made it clear that Java was to be the platform of choice seeing as it supports all of the above and has become a stable and mature technology in the last year.

We finally settled on RMI (Remote Method Invocation) as our technology of choice because of its simplicity and proven robustness. This means that our server-side component is a Java Application that extends java.rmi.Remote. The application requires an RMI registry (a sort of Domain Name Server for RMI servers) to be running in order for it to be able to register itself and for clients to be able to connect to the RMI server.

The LinKFactory® system consists of 2 major components (see figure 1), the LinKFactory® Server, and the LinKFactory® Workbench (client-side component). The LinkFactory® Workbench allows the user to browse and model the LinKBase® data.

[pic]

Figure 1 : LinKFactory® components

The workbench is a dynamic framework for the LinKFactory® Beans. Each bean has its own specific functionality and limited view to the underlying formal ontology, but combining a set of beans in the workbench can provide the user with a powerful tool to view an manage the data stored in the semantic database. The workbench provides the user with an optimal flexibility to create a customized tool to view and manage the data in the ontology.

Different views on the semantic network are implemented as Java beans. Examples are: Concept tree, Concept criteria and full definitions, Linktype tree, Criteria list, Term list, Search pane, Properties panel, Reverse relations, … The LinKFactory® framework is implemented in 100% pure Java code. The modular design is done using Java beans organized and linked in a freely configurable workspace.

Each user can create multiple views on the semantic network using the beans available. The beans are organized in several workspaces designed by the user. Each workspace can contain multiple frames upon which the beans are laid out. Once the layout work is finished, links can be established between the beans used.

Each of the layouts defined can be saved as Java code and stored in the database. Layouts can be defined on different levels: Organization, Group, User.

Each bean can have multiple incoming and outgoing links where appropriate. Beans can also be linked inter frame. Each bean has specific properties, which can be set at runtime. This approach allows for the different types of tasks to be performed using the optimal layout for the task at hand.

Several quality assurance mechanisms are build in: versioning, user tracking, user hierarchies, formal sanctioning with possibility to overrule, sibling-detection, linktype hierarchy, etc.

Specifications of the Available Beans :

General

The different beans provide information on and a view of different parts of the ontology’s build. All of these beans can be linked to each other, when an outgoing link from bean 1 matches an incoming link from bean 2. A bar on top of each bean shows the other beans the bean has been linked to and also the direction of the link. Other items in the bean bar are the bean label, the button to display/edit the bean properties and the possibility to refresh the bean contents. Optional items (dependent on the kind of bean) are a shortcut to the linktype filter property and a dragable item possibility.

Most important beans

The ConceptTree (see figure 2) bean provides the user with a view to the hierarchical relations in the semantic network of concepts. As concepts can have multiple parents (network structure) and the representation is a tree-view, the network structure is split up into the matching tree representation. Modifications to the structure can be made by means of drag and drop.

The functionalities of the ConceptTree bean include search by knowledge name, search by terms; modify hierarchy, history of searches. The bean properties provide a way to specify the number of siblings to display, the font, the child depth, the number of children to display, the preferred language, the parent depth and the leaf-node child depth.

[pic]

Figure 2 : the ConceptTree bean

A second important bean is the Full Definition bean (see figure 3). This bean shows the user the hierarchical and non-hierarchical relations a concept has with other concepts. These relations are sub classed in the relations explicitly specified for this concept (beneath the node labeled CRITERIA), and the implicit relations (beneath the node labeled INHERITED CRITERIA) (figure 2). It also shows the full definitions, i.e. the sufficient criteria to uniquely identify a concept, for this concept. Explicit relations and full definitions can be added, removed or modified (by drag and drop).

We introduced the notion of concept-definition and concept-criteria, which allows us to group a number of concept-criteria (essentially relationships) to form a full definition. In this way a concept could not only have multiple full definitions and loose concept-criteria, but also the definitions could overlap.

Concept-criteria are the equivalent of what used to be complex-concepts; they represent a relationship between two concepts by use of a linktype.

This diagram illustrates how full definitions could be constructed:

The hypothetical concept C has 5 relationships (CONCEPT_CRITERIA) and 2 full definitions (FD1 and FD2). FullDef1 consists of 3 concept-criteria: L1, L2 and L3 and FullDef2 consists of L3 and L4. L5 is simply a loose concept-criterium not belonging to any full definitions.

[pic]

Figure 3 : the Full Definition bean

The ReverseConcept bean (see figure 4) shows the reverse concept bean shows the relations other concepts have with the selected concept. The node labeled Reverse ConceptCriteria shows the explicit relations other concepts have with the selected concept. The node labeled Inherited Reverse ConceptCriteria shows the implicit relations other concepts have with this concept, i.e.: the explicit relations other concepts have with a concept that is a explicit child of the selected concept, hence the concepts have an implicit relation with the featured concept. The inherited reverse relations are not shown by default.

[pic]

Figure 4 : the Reverse Concept bean

The LinkType bean (see figure 5) provides the user with a view to the hierarchical relations in the semantic network of linktypes.

As linktypes can have multiple parents (network structure) and the representation is a tree-view, the network structure is split up into the matching tree representation. Modifications to the structure can be made by means of drag and drop.

Linktypes were deemed to have a hierarchy just like concepts so we added the LINKTYPE_TREE to represent this; this simple construct suffices because there is only a hierarchical parent-child relationship between linktypes.

This hierarchy will have an effect on the constraints (see below) because when a linktype is used in a concept-criterium it automatically implies all the parent-linktypes are used.

e.g. : When there is a link HAS-BONAFIDE-BOUNDARY and it has HAS-BOUNDARY as parent then that parent is also implied when the child is used in a relationship.

The Translate bean (see figure 6) shows the list of terms related to the selected concept, the selected linktype or the selected criterium in a certain language. Terms can be added, modified or removed. Several Translate beans can be viewed simultaneously giving terms in different languages, all linked to the language-independent concept. This construction f.e. makes it possible to place an application on top of the ontology

[pic]

Figure 5 : LinkType Tree bean

[pic]

Figure 6 : Translate bean

Other available beans include Concept Properties bean, LinkType Properties bean, Criteria bean, Bookmark bean and others.

All of these beans can be selected by the user and linked to each other, as such creating a powerful environment for browsing and editing large ontology’s. An ontology that has been build with LinKFactory® is LinKBase®.

LinKBase® : A LARGE FORMAL ONTOLOGY BUILD WITH LinKFactory®

Since the initial focus of L&C was the medical world, we started to construct a formal representation of the medical world. We used LinKFactory® to do this. LinKBase® is a large multi-lingual medical formal terminology system covering most parts of healthcare. The fact that LinKBase® currently contains over 1,000,000 medical concepts and over 350 linktypes (with over 3,000,000 linktype instantiations), gives a good indication of the size of the ontology’s LinKFactory® can handle.

The medical concepts, themselves language independent, are linked to about 3,000,000 terms in various languages. Terms can be stored in different languages and can be linked to concepts, criteria and linktypes with an intersection table, allowing us to define both homonyms (1 term that has several different meanings or linked concepts/criteria/linktypes) and synonyms (multiple terms associated with 1 concept/criteria/linktype).

Closely related with the mentioned intersection table (TERM_CCL) is the SOURCE and SOURCE_OBJECT construction. SOURCE is a table that stores a number of medical classification systems such as SNOMED or ICD-9-CM that classify medical concepts according to their own hierarchy and are used throughout the medical world. By using SOURCE_OBJECT we can link TERM_CCL records with certain sources and assign a code to that combination. We now have the possibility to translate from existing formal medical hierarchies to our own conceptual structure and back. A very powerful feature.

LinKBase® is an IS_A hierarchy without loops. This is called a ‘directed acyclic graph’. It means that no concept can be a child (of a child of a child…) of itself. In this hierarchy, it is not presumed that the children of one parent are mutually exclusive. In some cases, they are, what can be made explicit by using the DISJOINT link. In most cases, they are not.

LinKBase® makes a distinction between the domain knowledge and the linguistic knowledge. The linguistic ontology is a subset of the global ontology. It contains elements (medical knowledge and other) of the ontology that influence the grammar of a language. Part of it is present in a specific sub-ontology. Another part is present in the global ontology in a scattered manner. In this way, every piece of linguistic knowledge has to get a (referred-to) place in the domain ontology.

 

The linguistic ontology is on the level of language, not on the level of formal domain knowledge. Whether something truly happens or not is not part of the linguistic configuration. The distinctions in linguistic configuration are made according to the kinds of roles that are needed in a sentence. E.g. the ‘HAS-THEME’ is used for things that are displaced in a movement predicate.

E.g. “The nurse removes a tumor.”

What is the relation between ‘nurse’, ‘removing’ and ‘driving’?

• Domain ontologically

How can I think, abstractly, about removing? What are relevant questions? What are fixed elements, such as : There is movement ( What kind of movement?); Something/someone moves ( Who or what?); Something/someone provokes movement (Who or what?); The movement has a goal (Which goal?)

• Linguistically

That something/someone removes is necessary within this sentence. It does not matter who removes. It does not matter whether the surgeon really can remove things at all.

This medical ontology has been the basis for a lot of related products that each deal with a specific problem in medical environments.

DERIVED APPLICATIONS

Vertel hier wat over FastCode en TeSSIFastcode® is a state of the art coding tool to transform narrative expressions (diagnosis, clinical findings, etc.) in natural language into a classification system. Medical code tables and international classification systems can contain several thousand codes. Searching for a code is unpleasant and time-consuming. Fastcode® offers a very fast and accurate solution using semantic technology. The semantic database (LinKBase®) contains the medical terms (cfr. supra) linked to the different classification systems (Snomed-RT, ICD-9-CM, ICD10, MedDRA, ICPC, UMLS, MesH, …) on the basis of their conceptual meaning. Fastcode® analyses the meaning of the input words and performs a search based on the related concepts as stored in the LinKBase® medical ontology. Using this approach increases speed and accuracy while solving problems related to synonyms, homonyms, compound words, orthography and multiple spelling possibilities.

TeSSI® is a fast indexer to index documents on the basis of their content (deep meaning) rather than on the actual words contained in the text. This makes it possible to search a textual database using semantics rather than string matching. It will be clear that the results of semantic searches will be superior to those of string matches.

FUTURE DIRECTIONS OF LinKFactory

LinKfactory is currently used in house by ten medical knowledge engineers simultaneously. There are over 7,000,000 knowledge elements, and around 2000 modifications are made on a daily basis. A number of issues still have to be dealt with.

First, developments have started to make the system DAML+OIL compatible. This is not easy a task mainly because the DAML+OIL conventions themselves are not mature enough to be unambiguously understood. The fact that the reasoning mechanism behind LinkFactory® is description logic based, makes it however feasible, and today, we can claim to be 90% DAML+OIL compatible.

Another future goal is to integrate unsupervised learning capacities into the LinkFactory®. Using maximum-entropy models on large amounts of free texts, we are currently able to infer head-modifier relationships automatically from huge text corpora. The goal is now to find out how the head-modifier relationships can be “named” by using information from the LinkBase®. This possibly will lead to an optimal collaboration amongst statistical and symbolic methods.

REFERENCES

[1] Blázquez, M., Fernández, M, García-Pinar, J.M., Gómez, A.-. Building Ontologies at the Knowledge Levelusing the Ontology Design Environment. KAW98,

[2] Ceusters W. et al. The distinction between linguistic and conceptual semantics in medical terminology and its implication for NLP-based knowledge acquisition. In C Chute (ed): Proceedings of IMIAWG6 Conference on Natural Language and Medical Concept Representation (IMIA WG6, Jacksonville,1997) 71-80.

[3] Cocchiarella, N. B. 1991. Formal Ontology. In H. Burkhardt and B. Smith (eds.), Handbook of Metaphysics and Ontology. Philosophia Verlag, Munich: 640-647.

[4] Dominguez, J., Tadzebao and WebOnto : Discussing, browsing, and editing ontologies on the Web, Proceedings of the 11th Banff Knowledge Acquisition Workshop., (1998)

[5] Farquhar, A., and Rice, J., The Ontolingua Server : a tool for collaborative ontology construction, Proceedings of the 10th Banff Knowledge Acquisition Workshop, (1996).

[6] Kozaki, K. et al. “Development of an Environment for Building Ontologies which is based on a Fundamental Consideration of Relationship and Role", Proceedings of The Sixth Pacific Knowledge Acquisition Workshop (PKAW2000), pp.205-221 ,Sydney, Australia, December 11-13, 2000.

[7] Mahalingam, K., Huhns, M., An ontology tool for query formulation in an agent-based context, Proceedings of the 2nd IFCIS International Conference on Cooperative Information Systems (CoopIS '97)

[8] Musen, M.A., The Knowledge Model of Protégé-2000: Combining Interoperability and Flexibility, Proceedings of EKAW 2000 International Conference on Knowledge Engineering and Knowledge Management. Methods, Models and Tools., Juan-les-Pins, France, (October 2000).

[9] Preece, A. et al. Better Knowledge Management through Knowledge Engineering,. In IEEE Intelligent Systems 16:1, Jan-Feb, 2001.

-----------------------

[pic]

................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download