Applied ontology

Applied ontology (subfield of ontology) concerns itself with the application of such principles to build knowledge frameworks for specific domains such as medicine, biology, geography, etc. In recent years the development of ontologies has been moving from the realm of Artificial-Intelligence laboratories to the desktops of domain experts and has become common on the World-Wide Web.

Ontology

The main motivations for building ontologies are to make propositions with precise meaning and to enable computers to automate data processing. ICD, SNOMED, and MeSH often serve as examples, but the principles of building those terminologies are not often explored. This article will review the main themes in Applied Ontology, a book by Katherine Munn and Barry Smith, which provides an overview of the philosophies and principles involved in the tasks of knowledge development and curation.

Why would someone want to develop an ontology? Some of the reasons are:

     •	To share common understanding of the structure of information among people or software agents
     •	To enable reuse of domain knowledge
     •	To make domain assumptions explicit
     •	To separate domain knowledge from the operational knowledge
     •	To analyze domain knowledge3

Sharing common understanding of the structure of information among people or software agents is one of the more common goals in developing ontologies.4 For example, suppose several different Web sites contain medical information or provide medical e-commerce services. If these Web sites share and publish the same underlying ontology of the terms they all use, then computer agents can extract and aggregate information from these different sites. The agents can use this aggregated information to answer user queries or as input data to other applications.3

Enabling reuse of domain knowledge was one of the driving forces behind recent surge in ontology research. For example, models for many different domains need to represent the notion of time. This representation includes the notions of time intervals, points in time, relative measures of time, and so on. If one group of researchers develops such an ontology in detail, others can simply reuse it for their domains.3

Making explicit domain assumptions underlying an implementation makes it possible to change these assumptions easily if our knowledge about the domain changes. Hard-coding assumptions about the world in programming-language code make these assumptions not only hard to find and understand but also hard to change, in particular for someone without programming expertise. In addition, explicit specifications of domain knowledge are useful for new users who must learn what terms in the domain mean.3

Separating the domain knowledge from the operational knowledge is another common use of ontologies. We can describe a task of configuring a product from its components according to a required specification and implement a program that does this configuration independent of the products and components themselves.5

Analyzing domain knowledge is possible once a declarative specification of the terms is available. Formal analysis of terms is extremely valuable when both attempting to reuse existing ontologies and extending them.6

Developing the ontology

Some ontology-design ideas originated from the literature on object-oriented design. However, ontology development is different from designing classes and relations in object-oriented programming. Object-oriented programming centers primarily around methods on classes—a programmer makes design decisions based on the operational properties of a class, whereas an ontology designer makes these decisions based on the structural properties of a class.3

Pinto and Martin’s discuss generic ontology development stages: specification, conceptualization, formalization, implementation and maintenance. Kuziemsky expanded upon these concepts for ontology-based health information system design. He described using a participatory design (PD) method used not only to design a product but also to ensure the usability and utility of the product by engaging end users in the design process. Also described was grounded theory (GT) methodology which is a research method that uses a systematic set of procedures to develop an inductively derived theory about a phenomenon. Kuziemsky describes a hybrid Grounded Theory (GT) – Participatory Design (PD) that draws upon the strengths of both GT and PD. PD provides a means of user engagement to obtain a rich perspective on clinical practice and requires domain experts. GT codes data into concepts and categories based upon the understanding about the data. The methodological thoroughness of the GT-PD approach enables the ontology concepts and problem-solving approaches to be traced back to the source data. That traceability provides realistic validation to the ontology and also potentially promotes sharing of the ontology in different settings.7 8

Again, there is no one “correct” way or methodology for developing ontologies. In the ontology development methodology described here, we use an iterative approach. The best solution almost always depends on the application that you have in mind and the extensions that you anticipate. Concepts in the ontology should be close to objects (physical or logical) and relationships in your domain of interest.3

Step 1. Determine the domain and scope of the ontology We suggest starting the development of an ontology by defining its domain and scope. One of the ways to determine the scope of the ontology is to sketch a list of questions that a knowledge base based on the ontology should be able to answer competency questions. That is, answer several basic questions:

     •	What is the domain that the ontology will cover?
     •	For what we are going to use the ontology?
     •	For what types of questions the information in the ontology should provide answers?
     •	Who will use and maintain the ontology?9

Step 2. Consider reusing existing ontologies It is almost always worth considering what someone else has done and checking if we can refine and extend existing sources for our particular domain and task. Reusing existing ontologies may be a requirement if our system needs to interact with other applications that have already committed to particular ontologies or controlled vocabularies.

Step 3. Enumerate important terms in the ontology It is useful to write down a list of all terms we would like either to make statements about or to explain to a user. What are the terms we would like to talk about? What properties do those terms have? What would we like to say about those terms?3

Step 4. Define the classes and the class hierarchy There are several possible approaches in developing a class hierarchy. [10] A top-down development process starts with the definition of the most general concepts in the domain and subsequent specialization of the concepts. A bottom-up development process starts with the definition of the most specific classes, the leaves of the hierarchy, with subsequent grouping of these classes into more general concepts. A combination development process is a combination of the top-down and bottom-up approaches: We define the more salient concepts first and then generalize and specialize them appropriately.3

Step 5. Define the properties of classes—slots The classes alone will not provide enough information to answer the competency questions from Step 1. Once we have defined some of the classes, we must describe the internal structure of concepts.

Step 6. Define the facets of the slots Slots can have different facets describing the value type, allowed values, the number of the values (cardinality), and other features of the values the slot can take. Slot cardinality defines how many values a slot can have. Slot-value type is a value-type facet describes what types of values can fill in the slot. Here is a list of the more common value types:

     •	String is the simplest value type which is used for slots such as name: the value is a simple string
     •	Number (sometimes more specific value types of Float and Integer are used) describes slots with numeric values. 
     •	Boolean slots are simple yes–no flags. 
     •	Enumerated slots specify a list of specific allowed values for the slot.
     •	Instance-type slots allow definition of relationships between individuals.3

Step 7. Create instances The last step is creating individual instances of classes in the hierarchy. Defining an individual instance of a class requires (1) choosing a class, (2) creating an individual instance of that class, and (3) filling in the slot values.3

Use Case

The goal of specifying these relations is to establish the most general language possible with which to perform set operations or searches on the data, such as first order logic (FOL). FOL is composed of individual terms, predicates, logical connectives, and quantifiers. Using RxNorm as an example, RxNorm has a set of terms related to medications and the relationships between them. So, we can search for: SBDF has_tradename(SCDF has_ingredient (x)) to find the semantic branded drug form of the semantic clinicial dose forms containing the ingredient x. Their representation is useful, not only in finding ingredients of a given drug, but also of being able to seamlessly transition between the different forms and representations a drug or drug order might take on.

Conclusion

Ontologies are similar to the applications in natural language processing (NLP), in that we develop them to discover, structure, and automate the knowledge we've thus far accumulated. The only difference is perhaps in their approach. Ontologies specify knowledge whereas NLP discovers knowledge, usually through the statistical interplay of words in a corpus. While ontologies concern themselves with the broader task of representing entities in the real world, they still play a key role in enabling the development of rich semantically rich user interfaces in clinical information systems. SNOMED, ICD-9, RxNorm, etc represent the initial steps in ultimately processing large volumes of clinical data feasible.

A well-designed ontology can address the lack of a unifying reference terminology by providing an adequate link between the data models and the terminology models. A well-designed ontology is easily extensible, localizable and maintainable. After defining an initial version of the ontology, it can be evaluated and debugged by using it in applications or problem-solving methods or by discussing it with experts in the field, or both. Design, and therefore evaluation, is an iterative process throughout the ontology lifecycle in both the management and the support activities to illustrate its importance. The purpose of ontology evaluation should be to assess a given ontology using a particular criterion of application to determine the best one for a given purpose.

References

1. Munn K, Smith B. Applied ontology: an introduction. ontos verlag; 2008.
2. Cimino JJ, others. Desiderata for controlled medical vocabularies in the twenty-first century. Methods of Information in Medicine-Methodik der Information in der Medizin. 1998;37(4):394–403.
3. Noy, N, McGuinness, L. Ontology Development 101: A Guide to Creating Your First Ontology. Stanford Knowledge Systems Laboratory Technical Report KSL-01-05 and Stanford Medical Informatics Technical Report, 2001; SMI-2001-0880.
4. Gruber, T. R. A translation approach to portable ontology specifications. Stanford University. Computer Science Dept. Knowledge Systems Laboratory. 1993.
5. McGuinness DL, Wright J. Conceptual Modeling for Configuration: A Description Logic-based Approach. Artificial Intelligence for Engineering Design, Analysis, and Manufacturing - special issue on Configuration. 1998.
6. McGuinness DL, Fikes R, Rice J, Wilder S. An Environment for Merging and Testing Large Ontologies. Principles of Knowledge Representation and Reasoning: Proceedings of the Seventh International Conference (KR2000). A. G. Cohn, F. Giunchiglia and B. Selman, editors. San Francisco, CA, Morgan Kaufmann Publishers. 2000.
7. Pinto SF, Martins JP. Ontologies: how can they be built? Knowledge Inform Syst 2004;6:441–64
8. Kuziemsky CE, Lau F. A four stage approach for ontology-based health information system design. Artificial Intelligence in Medicine, 2010;50(3):133-148.
9. Gruninger M, Fox, M.. Methodology for the Design and Evaluation of Ontologies. In: Proceedings of the Workshop on Basic Ontological Issues in Knowledge Sharing, IJCAI-95, Montreal. 1995.
10. Uschold, M. and Gruninger, M. Ontologies: Principles, Methods and Applications. Knowledge Engineering Review 1996;11(2).

Submitted by Nathan Bahr

Submitted by Travis Gamble