Overview

The term ontology has its origin in philosophy, and has been applied in many different

ways. The core meaning within computer science is a model for describing the world that

consists of a set of types, properties, and relationship types. Exactly what is provided

around these varies, but they are the essentials of an ontology. There is also generally an

expectation that there be a close resemblance between the real world and the features of

the model in an ontology.[3]

What ontology has in common in both computer science and in philosophy is the

representation of entities, ideas, and events, along with their properties and relations,

according to a system of categories. In both fields, one finds considerable work on

problems of ontological relativity (e.g., Quine and Kripke in philosophy, Sowa and

Guarino in computer science),[4] and debates concerning whether a normative ontology is

viable (e.g., debates over foundationalism in philosophy, debates over the Cyc project in

AI). Differences between the two are largely matters of focus. Philosophers are less

concerned with establishing fixed, controlled vocabularies than are researchers in

computer science, while computer scientists are less involved in discussions of first

principles (such as debating whether there are such things as fixed essences, or whether

entities must be ontologically more primary than processes).

Definition

The subject of ontology is the study of the categories of things that exist or may exist in

some domain. The product of such a study, called an ontology, is a catalog of the types of

things that are assumed to exist in a domain of interest D from the perspective of a person
who uses a language L for the purpose of talking about D. The types in the ontology

represent the predicates, word senses, or concept and relation types of the language L

when used to discuss topics in the domain D. An uninterpreted logic, such as predicate

calculus, conceptual graphs, or KIF, is ontologically neutral. It imposes no constraints on

the subject matter or the way the subject may be characterized. By itself, logic says

nothing about anything, but the combination of logic with an ontology provides a

language that can express relationships about the entities in the domain of interest.

Scope

An informal ontology may be specified by a catalog of types that are either undefined or

defined only by statements in a natural language. A formal ontology is specified by a

collection of names for concept and relation types organized in a partial ordering by the

type-subtype relation. Formal ontologies are further distinguished by the way the

subtypes are distinguished from their supertypes: an axiomatized ontology distinguishes

subtypes by axioms and definitions stated in a formal language, such as logic or some

computer-oriented notation that can be translated to logic; a prototype-based ontology

distinguishes subtypes by a comparison with a typical member or prototype for each

subtype. Large ontologies often use a mixture of definitional methods: formal axioms and

definitions are used for the terms in mathematics, physics, and engineering; and

prototypes are used for plants, animals, and common household items.
History

Historically, ontologies arise out of the branch of philosophy known as metaphysics,

which deals with the nature of reality – of what exists. This fundamental branch is

concerned with analyzing various types or modes of existence, often with special

attention to the relations between particulars and universals, between intrinsic and

extrinsic properties, and between essence and existence. The traditional goal of

ontological inquiry in particular is to divide the world "at its joints", to discover those

fundamental categories, or kinds, into which the world’s objects naturally fall.[5]

During the second half of the 20th century, philosophers extensively debated the possible

methods or approaches to building ontologies, without actually building any very

elaborate ontologies themselves. By contrast, computer scientists were building some

large and robust ontologies (such as WordNet and Cyc) with comparatively little debate

over how they were built.

Since the mid-1970s, researchers in the field of artificial intelligence (AI) have

recognized that capturing knowledge is the key to building large and powerful AI

systems. AI researchers argued that they could create new ontologies as computational

models that enable certain kinds of automated reasoning. In the 1980s, the AI community

began to use the term ontology to refer to both a theory of a modeled world and a

component of knowledge systems. Some researchers, drawing inspiration from

philosophical ontologies, viewed computational ontology as a kind of applied philosophy.

[6]
In the early 1990s, the widely cited Web page and paper "Toward Principles for the

Design of Ontologies Used for Knowledge Sharing" by Tom Gruber[7] is credited with a

deliberate definition of ontology as a technical term in computer science. Gruber

"introduced the term to mean a specification of a conceptualization. That is "an ontology

is a description (like a formal specification of a program) of the concepts and

relationships that can exist for an agent or a community of agents. This definition is

consistent with the usage of ontology as set of concept definitions, but more general. And

it is a different sense of the word than its use in philosophy".[8]

According to Gruber (1993) "ontologies are often equated with taxonomic hierarchies of

classes, class definitions, and the subsumption relation, but ontologies need not be limited

to these forms. Ontologies are also not limited to conservative definitions – that is,

definitions in the traditional logic sense that only introduce terminology and do not add

any knowledge about the world.[9] To specify a conceptualization, one needs to state

axioms that do constrain the possible interpretations for the defined terms.[1]

In the early years of the 21st century, the interdisciplinary project of cognitive science

has been bringing the two circles of scholars closer together[citation needed]. For example, there

is talk of a "computational turn in philosophy" that includes philosophers analyzing the

formal ontologies of computer science (sometimes even working directly with the

software), while researchers in computer science have been making more references to

those philosophers who work on ontology (sometimes with direct consequences for their

methods). Still, many scholars in both fields are uninvolved in this trend of cognitive

science, and continue to work independently of one another, pursuing separately their

different concerns.
Why develop an ontology?

In recent years the development of ontologies—explicit formal specifications of the terms

in the domain and relations among them (Gruber 1993)—has been moving from the

realm of Artificial-Intelligence laboratories to the desktops of domain experts. Ontologies

have become common on the World-Wide Web. The ontologies on the Web range from

large taxonomies categorizing Web sites (such as on Yahoo!) to categorizations of

products for sale and their features (such as on Amazon.com). The WWW Consortium

(W3C) is developing the Resource Description Framework (Brickley and Guha 1999), a

language for encoding knowledge on Web pages to make it understandable to electronic

agents searching for information. The Defense Advanced Research Projects Agency

(DARPA), in conjunction with the W3C, is developing DARPA Agent Markup Language

(DAML) by extending RDF with more expressive constructs aimed at facilitating agent

interaction on the Web (Hendler and McGuinness 2000). Many disciplines now develop

standardized ontologies that domain experts can use to share and annotate information in

their fields. Medicine, for example, has produced large, standardized, structured

vocabularies such as SNOMED (Price and Spackman 2000) and the semantic network of

the Unified Medical Language System (Humphreys and Lindberg 1993). Broad general-

purpose ontologies are emerging as well. For example, the United Nations Development

Program and Dun & Bradstreet combined their efforts to develop the UNSPSC ontology

which provides terminology for products and services (www.unspsc.org).

An ontology defines a common vocabulary for researchers who need to share information

in a domain. It includes machine-interpretable definitions of basic concepts in the domain

and relations among them.

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 knowledge

Sharing common understanding of the structure of information among people or

software agents is one of the more common goals in developing ontologies (Musen

1992; Gruber 1993). 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.

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. Additionally, if we need

to build a large ontology, we can integrate several existing ontologies describing portions

of the large domain. We can also reuse a general ontology, such as the UNSPSC

ontology, and extend it to describe our domain of interest.

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 makes 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.

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 (McGuinness and

Wright 1998). We can then develop an ontology of PC-components and characteristics

and apply the algorithm to configure made-to-order PCs. We can also use the same

algorithm to configure elevators if we “feed” an elevator component ontology to it

(Rothenfluh et al. 1996).

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 (McGuinness et al. 2000).

Often an ontology of the domain is not a goal in itself. Developing an ontology is akin to

defining a set of data and their structure for other programs to use. Problem-solving

methods, domain-independent applications, and software agents use ontologies and

knowledge bases built from ontologies as data. For example, in this paper we develop an

ontology of wine and food and appropriate combinations of wine with meals. This

ontology can then be used as a basis for some applications in a suite of restaurant-

managing tools: One application could create wine suggestions for the menu of the day or

answer queries of waiters and customers. Another application could analyze an inventory
list of a wine cellar and suggest which wine categories to expand and which particular

wines to purchase for upcoming menus or cookbooks.

we are not trying to address all of them in this guide. Instead, we try to provide a starting

point; an initial guide that would help a new ontology designer to develop ontologies. At

the end, we suggest places to look for explanations of more complicated structures and

design mechanisms if the domain requires them.

Finally, there is no single correct ontology-design methodology and we did not attempt to

define one. The ideas that we present here are the ones that we found useful in our own

ontology-development experience. At the end of this guide we suggest a list of references

for alternative methodologies.

Ontology components

Main article: Ontology components

Contemporary ontologies share many structural similarities, regardless of the language in

which they are expressed. As mentioned above, most ontologies describe individuals

(instances), classes (concepts), attributes, and relations. In this section each of these

components is discussed in turn.

Common components of ontologies include:

• Individuals: instances or objects (the basic or "ground level" objects)

• Classes: sets, collections, concepts, classes in programming, types of objects, or

kinds of things.

• Attributes: aspects, properties, features, characteristics, or parameters that objects

(and classes) can have

 • Relations: ways in which classes and individuals can be related to one another

• Function terms: complex structures formed from certain relations that can be used

in place of an individual term in a statement

• Restrictions: formally stated descriptions of what must be true in order for some

assertion to be accepted as input

• Rules: statements in the form of an if-then (antecedent-consequent) sentence that

describe the logical inferences that can be drawn from an assertion in a particular

form

• Axioms: assertions (including rules) in a logical form that together comprise the

overall theory that the ontology describes in its domain of application. This

definition differs from that of "axioms" in generative grammar and formal logic.

In those disciplines, axioms include only statements asserted as a priori

knowledge. As used here, "axioms" also include the theory derived from

axiomatic statements.

• Events: the changing of attributes or relations

Ontologies are commonly encoded using ontology languages.

Domain ontologies and upper ontologies

A domain ontology (or domain-specific ontology) models a specific domain, or part of

the world. It represents the particular meanings of terms as they apply to that domain. For

example the word card has many different meanings. An ontology about the domain of

poker would model the "playing card" meaning of the word, while an ontology about the

domain of computer hardware would model the "punched card" and "video card"

meanings.
An upper ontology (or foundation ontology) is a model of the common objects that are

generally applicable across a wide range of domain ontologies. It employs a core glossary

that contains, the terms, and associated object descriptions, as they are used in various,

relevant domain sets. There are several standardized upper ontologies available for use,

including Dublin Core, GFO, OpenCyc/ResearchCyc, SUMO, and DOLCE. WordNet,

while considered an upper ontology by some, is not strictly an ontology. However, it has

been employed as a linguistic tool for learning domain ontologies.[10]

The Gellish ontology is an example of a combination of an upper and a domain ontology.

Since domain ontologies represent concepts in very specific and often eclectic ways, they

are often incompatible. As systems that rely on domain ontologies expand, they often

need to merge domain ontologies into a more general representation. This presents a

challenge to the ontology designer. Different ontologies in the same domain can also

arise due to different perceptions of the domain based on cultural background, education,

ideology, or because a different representation language was chosen.

At present, merging ontologies that are not developed from a common foundation

ontology is a largely manual process and therefore time-consuming and expensive.

Domain ontologies that use the same foundation ontology to provide a set of basic

elements with which to specify the meanings of the domain ontology elements can be

merged automatically. There are studies on generalized techniques for merging

ontologies[citation needed], but this area of research is still largely theoretical.

 Ontology languages

Main article: Ontology language

An ontology language is a formal language used to encode the ontology. There are a

number of such languages for ontologies, both proprietary and standards-based:

• Common Algebraic Specification Language is a general logic-based specification

language developed within the IFIP working group 1.3 "Foundations of System

Specifications" and functions as a de facto standard in the area of software

specifications. It is now being applied to ontology specifications in order to

provide modularity and structuring mechanisms.

• Common logic is ISO standard 24707, a specification for a family of ontology

languages that can be accurately translated into each other.

• The Cyc project has its own ontology language called CycL, based on first-order

predicate calculus with some higher-order extensions.

• DOGMA (Developing Ontology-Grounded Methods and Applications) adopts the

fact-oriented modeling approach to provide a higher level of semantic stability.

• The Gellish language includes rules for its own extension and thus integrates an

ontology with an ontology language.

• IDEF5 is a software engineering method to develop and maintain usable,

accurate, domain ontologies.

• KIF is a syntax for first-order logic that is based on S-expressions.

• Rule Interchange Format (RIF) and F-Logic combine ontologies and rules.

• OWL is a language for making ontological statements, developed as a follow-on

from RDF and RDFS, as well as earlier ontology language projects including
 OIL, DAML and DAML+OIL. OWL is intended to be used over the World Wide

Web, and all its elements (classes, properties and individuals) are defined as RDF

resources, and identified by URIs.

• SADL captures a subset of the expressiveness of OWL, using an English-like

language entered via an Eclipse Plug-in.

• OBO, a language used for biological and biomedical ontologies.

Ontology engineering

Main article: Ontology engineering

Ontology engineering (or ontology building) is a subfield of knowledge engineering that

studies the methods and methodologies for building ontologies. It studies the ontology

development process, the ontology life cycle, the methods and methodologies for

building ontologies, and the tool suites and languages that support them.[11][12]

Ontology engineering aims to make explicit the knowledge contained within software

applications, and within enterprises and business procedures for a particular domain.

Ontology engineering offers a direction towards solving the interoperability problems

brought about by semantic obstacles, such as the obstacles related to the definitions of

business terms and software classes. Ontology engineering is a set of tasks related to the

development of ontologies for a particular domain.[13]

 A Simple Knowledge-Engineering Methodology

As we said earlier, there is no one “correct” way or methodology for developing

ontologies. Here we discuss general issues to consider and offer one possible process for

developing an ontology. We describe an iterative approach to ontology development: we

start with a rough first pass at the ontology. We then revise and refine the evolving

ontology and fill in the details. Along the way, we discuss the modeling decisions that a

designer needs to make, as well as the pros, cons, and implications of different solutions.

First, we would like to emphasize some fundamental rules in ontology design to which

we will refer many times. These rules may seem rather dogmatic. They can help,

however, to make design decisions in many cases.

1) There is no one correct way to model a domain— there are always viable

alternatives. The best solution almost always depends on the application that

you have in mind and the extensions that you anticipate.

2) Ontology development is necessarily an iterative process.

3) Concepts in the ontology should be close to objects (physical or logical) and

relationships in your domain of interest. These are most likely to be nouns

(objects) or verbs (relationships) in sentences that describe your domain.

That is, deciding what we are going to use the ontology for, and how detailed or general

the ontology is going to be will guide many of the modeling decisions down the road.

Among several viable alternatives, we will need to determine which one would work

better for the projected task, be more intuitive, more extensible, and more maintainable.
We also need to remember that an ontology is a model of reality of the world and the

concepts in the ontology must reflect this reality. After we define an initial version of the

ontology, we can evaluate and debug it by using it in applications or problem-solving

methods or by discussing it with experts in the field, or both. As a result, we will almost

certainly need to revise the initial ontology. This process of iterative design will likely

continue through the entire lifecycle of the ontology.

Step 1. Determine the domain and scope of the ontology

We suggest starting the development of an ontology by defining its domain and scope.

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?

The answers to these questions may change during the ontology-design process, but at

any given time they help limit the scope of the model.

Consider the ontology of wine and food that we introduced earlier. Representation of

food and wines is the domain of the ontology. We plan to use this ontology for the

applications that suggest good combinations of wines and food.

Naturally, the concepts describing different types of wines, main food types, the notion of

a good combination of wine and food and a bad combination will figure into our

ontology. At the same time, it is unlikely that the ontology will include concepts for

managing inventory in a winery or employees in a restaurant even though these concepts

are somewhat related to the notions of wine and food.

If the ontology we are designing will be used to assist in natural-language processing of

articles in wine magazines, it may be important to include synonyms and part-of-speech

information for concepts in the ontology. If the ontology will be used to help restaurant

customers decide which wine to order, we need to include retail-pricing information. If it

is used for wine buyers in stocking a wine cellar, wholesale pricing and availability may

be necessary. If the people who will maintain the ontology describe the domain in a

language that is different from the language of the ontology users, we may need to

provide the mapping between the languages.

Competency questions.

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 (Gruninger and Fox 1995). These questions will serve as the litmus test later:

Does the ontology contain enough information to answer these types of questions? Do the

answers require a particular level of detail or representation of a particular area? These

competency questions are just a sketch and do not need to be exhaustive.

In the wine and food domain, the following are the possible competency questions:

 Which wine characteristics should I consider when choosing a wine?

 Is Bordeaux a red or white wine?

 Does Cabernet Sauvignon go well with seafood?

 What is the best choice of wine for grilled meat?

 Which characteristics of a wine affect its appropriateness for a dish?

 Does a bouquet or body of a specific wine change with vintage year?

 What were good vintages for Napa Zinfandel?

Judging from this list of questions, the ontology will include the information on various

wine characteristics and wine types, vintage years—good and bad ones—classifications

of foods that matter for choosing an appropriate wine, recommended combinations of

wine and food.

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. Many ontologies are already available in electronic form and can be

imported into an ontology-development environment that you are using. The formalism

in which an ontology is expressed often does not matter, since many knowledge-

representation systems can import and export ontologies. Even if a knowledge-

representation system cannot work directly with a particular formalism, the task of

translating an ontology from one formalism to another is usually not a difficult one.

There are libraries of reusable ontologies on the Web and in the literature. For example,

we can use the Ontolingua ontology library

(http://www.ksl.stanford.edu/software/ontolingua/) or the DAML ontology library

(http://www.daml.org/ontologies/). There are also a number of publicly available

commercial ontologies (e.g., UNSPSC (www.unspsc.org), RosettaNet

(www.rosettanet.org), DMOZ (www.dmoz.org)).

For example, a knowledge base of French wines may already exist. If we can import this

knowledge base and the ontology on which it is based, we will have not only the

classification of French wines but also the first pass at the classification of wine

characteristics used to distinguish and describe the wines. Lists of wine properties may

already be available from commercial Web sites such as www.wines.com that customers

consider use to buy wines.

For this guide however we will assume that no relevant ontologies already exist and start

developing the ontology from scratch.

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? For example,

important wine-related terms will include wine, grape, winery, location, a wine’s color,

body, flavor and sugar content; different types of food, such as fish and red meat;
subtypes of wine such as white wine, and so on. Initially, it is important to get a

comprehensive list of terms without worrying about overlap between concepts they

represent, relations among the terms, or any properties that the concepts may have, or

whether the concepts are classes or slots..

The next two steps—developing the class hierarchy and defining properties of concepts

(slots)—are closely intertwined. It is hard to do one of them first and then do the other.

Typically, we create a few definitions of the concepts in the hierarchy and then continue

by describing properties of these concepts and so on. These two steps are also the most

important steps in the ontology-design process. We will describe them here briefly and

then spend the next two sections discussing the more complicated issues that need to be

considered, common pitfalls, decisions to make, and so on.

Step 4. Define the classes and the class hierarchy

There are several possible approaches in developing a class hierarchy (Uschold and

Gruninger 1996):

 A top-down development process starts with the definition of the most general

concepts in the domain and subsequent specialization of the concepts. For example, we

can start with creating classes for the general concepts of Wine and Food. Then we

specialize the Wine class by creating some of its subclasses: White wine, Red wine, Rosé

wine. We can further categorize the Red wine class, for example, into Syrah, Red

Burgundy, Cabernet Sauvignon, and so on.

 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. For example, we start by defining classes for Pauillac and Margaux

wines. We then create a common superclass for these two classes—Medoc—which in

turn is a subclass of Bordeaux.

 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. We might start with a few top-level concepts such as

Wine, and a few specific concepts, such as Margaux . We can then relate them to a

middle-level concept, such as Medoc. Then we may want to generate all of the regional

wine classes from France, thereby generating a number of middle-level concepts.

Figure 2 shows a possible breakdown among the different levels of generality.

Figure 2. The different levels of the Wine taxonomy: Wine, Red wine, White wine, Rosé

wine are more general concepts, the top level. Pauillac and Margaux are the most specific

classes in the hierarchy, the bottom level.

None of these three methods is inherently better than any of the others. The approach to

take depends strongly on the personal view of the domain. If a developer has a systematic

top-down view of the domain, then it may be easier to use the top-down approach. The

combination approach is often the easiest for many ontology developers, since the

concepts “in the middle” tend to be the more descriptive concepts in the domain (Rosch

1978).

If you tend to think of wines by distinguishing the most general classification first, then

the top-down approach may work better for you. If you’d rather start by getting grounded

with specific examples, the bottom-up approach may be more appropriate.

Whichever approach we choose, we usually start by defining classes. From the list

created in Step 3, we select the terms that describe objects having independent existence

rather than terms that describe these objects. These terms will be classes in the ontology

and will become anchors in the class hierarchy.[2] We organize the classes into a

hierarchical taxonomy by asking if by being an instance of one class, the object will

necessarily (i.e., by definition) be an instance of some other class.

If a class A is a superclass of class B, then every instance of B is also an instance of A

In other words, the class B represents a concept that is a “kind of” A.

For example, every Pinot Noir wine is necessarily a red wine. Therefore the Pinot Noir

class is a subclass of the Red Wine class.

Figure 2 shows a part of the class hierarchy for the Wine ontology. Section 4 contains a

detailed discussion of things to look for when defining a class hierarchy.

Figure 3. The slots for the class Wine and the facets for these slots. The “I” icon next to

the maker slot indicates that the slot has an inverse (Section 5.1)

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.

We have already selected classes from the list of terms we created in Step 3. Most of the

remaining terms are likely to be properties of these classes. These terms include, for

example, a wine’s color, body, flavor and sugar content and location of a winery.

For each property in the list, we must determine which class it describes. These properties

become slots attached to classes. Thus, the Wine class will have the following slots:

color, body, flavor, and sugar. And the class Winery will have a location slot.
In general, there are several types of object properties that can become slots in an

ontology:

 “intrinsic” properties such as the flavor of a wine;

 “extrinsic” properties such as a wine’s name, and area it comes from;

 parts, if the object is structured; these can be both physical and abstract “parts”

(e.g., the courses of a meal)

 relationships to other individuals; these are the relationships between individual

members of the class and other items (e.g., the maker of a wine, representing a

relationship between a wine and a winery, and the grape the wine is made from.)

Thus, in addition to the properties we have identified earlier, we need to add the

following slots to the Wine class: name, area, maker, grape. Figure 3 shows the slots for

the class Wine.

All subclasses of a class inherit the slot of that class. For example, all the slots of the

class Wine will be inherited to all subclasses of Wine, including Red Wine and White

Wine. We will add an additional slot, tannin level (low, moderate, or high), to the Red

Wine class. The tannin level slot will be inherited by all the classes representing red

wines (such as Bordeaux and Beaujolais).

A slot should be attached at the most general class that can have that property. For

instance, body and color of a wine should be attached at the class Wine, since it is the

most general class whose instances will have body and color.
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. For example,

the value of a name slot (as in “the name of a wine”) is one string. That is, name is a slot

with value type String. A slot produces (as in “a winery produces these wines”) can have

multiple values and the values are instances of the class Wine. That is, produces is a slot

with value type Instance with Wine as allowed class.

We will now describe several common facets.

Examples of published ontologies

• Basic Formal Ontology,[14] a formal upper ontology designed to support scientific

research

• BioPAX,[15] an ontology for the exchange and interoperability of biological

pathway (cellular processes) data

• BMO,[16] an e-Business Model Ontology based on a review of enterprise

ontologies and business model literature

• CCO (Cell-Cycle Ontology),[17] an application ontology that represents the cell

cycle

• CContology,[18] an e-business ontology to support online customer complaint

management

• CIDOC Conceptual Reference Model, an ontology for cultural heritage[19]

• COSMO,[20] a Foundation Ontology (current version in OWL) that is designed to

contain representations of all of the primitive concepts needed to logically specify

 the meanings of any domain entity. It is intended to serve as a basic ontology that

can be used to translate among the representations in other ontologies or

databases. It started as a merger of the basic elements of the OpenCyc and SUMO

ontologies, and has been supplemented with other ontology elements (types,

relations) so as to include representations of all of the words in the Longman

dictionary defining vocabulary.

• Cyc, a large Foundation Ontology for formal representation of the universe of

discourse.

• Disease Ontology,[21] designed to facilitate the mapping of diseases and associated

conditions to particular medical codes

• DOLCE, a Descriptive Ontology for Linguistic and Cognitive Engineering[22]

• Dublin Core, a simple ontology for documents and publishing

• Foundational, Core and Linguistic Ontologies[23]

• Foundational Model of Anatomy,[24] an ontology for human anatomy

• Friend of a Friend, an ontology for describing persons, their activities and their

relations to other people and objects

• Gene Ontology for genomics

• GUM (Generalized Upper Model),[25] a linguistically-motivated ontology for

mediating between clients systems and natural language technology

• Gellish English dictionary, an ontology that includes a dictionary and taxonomy

that includes an upper ontology and a lower ontology that focusses on industrial

and business applications in engineering, technology and procurement. See also

Gellish as Open Source project on SourceForge.

• Geopolitical ontology, an ontology describing geopolitical information created by

Food_and_Agriculture_Organization(FAO). The geopolitical ontology includes

names in multiple languages (English, French, Spanish, Arabic, Chinese, Russian

and Italian); maps standard coding systems (UN, ISO, FAOSTAT, AGROVOC,

etc); provides relations among territories (land borders, group membership, etc);

and tracks historical changes. In addition, FAO provides web services

(http://www.fao.org/countryprofiles/webservices.asp?lang=en) of geopolitical

ontology and a module maker

(http://www.fao.org/countryprofiles/geoinfo/modulemaker/index.html) to

download modules of the geopolitical ontology into different formats (RDF,

XML, and EXCEL). See more information on the FAO Country Profiles

geopolitical ontology web page(http://www.fao.org/countryprofiles/geoinfo.asp?

lang=en).

• GOLD,[26] General Ontology for Linguistic Description

• IDEAS Group,[27] a formal ontology for enterprise architecture being developed

by the Australian, Canadian, UK and U.S. Defence Depts.

• Linkbase,[28] a formal representation of the biomedical domain, founded upon

Basic Formal Ontology.

• LPL, Lawson Pattern Language

• NIFSTD Ontologies from the Neuroscience Information Framework: a modular

set of ontologies for the neuroscience domain. See http://neuinfo.org

• OBO Foundry, a suite of interoperable reference ontologies in biomedicine

• Ontology for Biomedical Investigations, an open access, integrated ontology for

the description of biological and clinical investigations

 • OMNIBUS Ontology,[29] an ontology of learning, instruction, and instructional

design

• Plant Ontology[30] for plant structures and growth/development stages, etc.

• POPE, Purdue Ontology for Pharmaceutical Engineering

• PRO,[31] the Protein Ontology of the Protein Information Resource, Georgetown

University.

• Program abstraction taxonomy program abstraction taxonomy

• Protein Ontology[32] for proteomics

• Systems Biology Ontology (SBO), for computational models in biology

• Suggested Upper Merged Ontology, a formal upper ontology

• SWEET,[33] Semantic Web for Earth and Environmental Terminology

• ThoughtTreasure ontology

• TIME-ITEM, Topics for Indexing Medical Education

• UMBEL, a lightweight reference structure of 20,000 subject concept classes and

their relationships derived from OpenCyc

• YATO,[34] Yet Another Top-level Ontology

• WordNet, a lexical reference system

Ontology libraries

The development of ontologies for the Web has led to the emergence of services

providing lists or directories of ontologies with search facility. Such directories have been

called ontology libraries.

The following are static libraries of human-selected ontologies.

 • DAML Ontology Library[35] maintains a legacy of ontologies in DAML.

• Protege Ontology Library[36] contains a set of owl, Frame-based and other format

ontologies.

• SchemaWeb[37] is a directory of RDF schemata expressed in RDFS, OWL and

DAML+OIL.

The following are both directories and search engines. They include crawlers searching

the Web for well-formed ontologies.

• OBO Foundry / Bioportal[38] is a suite of interoperable reference ontologies in

biology and biomedicine.

• OntoSelect[39] Ontology Library offers similar services for RDF/S, DAML and

OWL ontologies.

• Ontaria[40] is a "searchable and browsable directory of semantic web data", with a

focus on RDF vocabularies with OWL ontologies.

• Swoogle is a directory and search engine for all RDF resources available on the

Web, including ontologies.

Examples of applications using ontology engines

SAPPHIRE (Health care) or Situational Awareness and Preparedness for Public

Health Incidences and Reasoning Engines is a semantics-based health information

system capable of tracking and evaluating situations and occurrences that may affect

public health.
 Conclusions

In this guide, we have described an ontology-development methodology for declarative

frame-based systems. We listed the steps in the ontology-development process and

addressed the complex issues of defining class hierarchies and properties of classes and

instances. However, after following all the rules and suggestions, one of the most

important things to remember is the following: there is no single correct ontology for any

domain. Ontology design is a creative process and no two ontologies designed by

different people would be the same. The potential applications of the ontology and the

designer’s understanding and view of the domain will undoubtedly affect ontology design

choices. “The proof is in the pudding”—we can assess the quality of our ontology only

by using it in applications for which we designed it.

REFERENCE